Add @import and url() resource location fixes when bundling.

Fix on-the-fly PhantomJS test execution - XHRs for LESS files had status 0 but responseText were there.
I follow closely SystemJS CSS plugin with exception for how LESS compiler works.
So I include a number of changes:

less-builder.js

require path & fs
copy isWin and fromFileURL from CSS plugin
fix invocation is stubDefines - another pull request also fixes it
define rootURL - as in CSS plugin
define outFile - as in CSS plugin but change file suffix because of possible name collision with output of CSS plugin
LESS import and url resource regular expressions to do necessary source modifications:

when import statement is encountered LESS compiler works correctly when it is absolute path
on the other hand, browser knows how to fetch url resource when it is relative to the stylesheet that needs it. But having merged and output CSS file url resource paths need to be relative to the rootURL of the app - full jspm_packages paths are placed there

LESS compiler's render method already returns a Promise so no need for wrapping thing up in another Promise
writing file to the disk if separateCSS flag is true

less.js

request.onload checks if status is >= 200 & < 400 but it fails in PhantomJS because it is 0. Instead I put a check for responseText only. Feel free to improve it.

I did not remove logs as it may be helpful while reviewing changes.

Just good to mention that this PR has changes form https://github.com/HuasoFoundries/systemjs-less-plugin/pull/2 , so also closes #1
So if merged, mine PR can be closed without merge.

Released as  v1.4.4


Avoid creating a FilterEvalContext for non-matching subscriptions

A small perf improvement.
jira: https://issues.jboss.org/browse/ISPN-5905
https://issues.jboss.org/browse/ISPN-5906

wrong branch. closing..


update logOut docs to reflect that Realms are deleted on next app launch

Addresses #4855.

Looks good.
You may or may not want to note that, if the user is logged back in, their files will not be removed upon next launch. This might be too obvious to be worth mentioning, though.

I think that's obvious enough.


Add more themes to the whiteList

YourFolio is a portfolio theme with lots of parameters in its _index.md the content is neutral.
Closes #556

Also Hugo Resume needs its own content for the demo to be generated.


OAuth2 token processor

Hi!
I've created a processor to retrieve an OAuth2 token using the client credentials token flow.
We can use it within a branch processor, for example:
pipeline:
  processors:
  - branch:
      processors:
      - oauth2_token:
          endpoint: https://my-identiy-server.foo.com
          client_id: ${!json("client_id")}
          client_secret: ${CLIENT_SECRET}
          scopes:
          - my-scope
      result_map: |-
        token = this
  - bloblang: |
      root = this
      access_token = token.access_token
      token_type = token.token_type
      expiry = token.expiry
      ttl = token.expiry.parse_timestamp_unix()-timestamp_unix()

or getting the token marshalled in a metadata key:
pipeline:
  processors:
  - oauth2_token:
      endpoint: https://my-identiy-server.foo.com
      client_id: ${!json("client_id")}
      client_secret: ${CLIENT_SECRET}
      scopes:
      - my-scope
      metadata_key: token
  - bloblang: |
      root = this
      marshalled_token = meta("token")

Hey @mfamador, looks interesting, what would be the typical use for this? Wondering if it could be something we bake into the https://www.benthos.dev/docs/components/processors/http#oauth2 functionality.

In our case, we're going to use this processor to retrieve the OAuth token that we need to use afterwards for authorization on a few other custom plugins calling gRPC services. We're going to combine it with the cache processor to store the token.

Regarding the http processor I'm not sure if we could use it in our use case, we just need to retrieve the OAuth2 token, we don't really want to perform an HTTP request.

I guess this one got stale :) Closing it.


Doc: how to use change-point detection algorithm

Description
Brief code example for running change-point detection (CPD) algorithm, using rupture package.
Example
Partial result from long (8.5hours) recording, analyzing any change in statistical distribution throughout the experiment.

Type of change
Please delete options that are not relevant.

[x] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[x] make test

Checklist:

[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings/errors
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been addressed and published in downstream modules
[x] There are no other PR/Issues that is blocking this PR.

LGTM

Codecov Report

:exclamation: No coverage uploaded for pull request base (update-0.2.4@bd4129a). Click here to learn what that means.
 Consider uploading reports for the commit eb9ea2e to get more accurate results

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@               Coverage Diff               @@
##             update-0.2.4     #193   +/-   ##
===============================================
  Coverage                ?   74.53%
===============================================
  Files                   ?       55
  Lines                   ?     1920
  Branches                ?      280
===============================================
  Hits                    ?     1431
  Misses                  ?      399
  Partials                ?       90

Flag
Coverage Δ

unittests
74.53% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.
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.


Fixed memory leaks that arise while generating solr index entries

This patch is for solving the memory leak issue that arises while generating solr indexes from go-cam model files.

Problem: Loading each model file involves (i) retrieving some literal values from ontology objects and (ii) materializing implicit axioms. These literals and axioms are later directly referenced and fed into the object used for solr document objects. The problem is that, even if we put codes that remove ontology objects, garbage collectors in Java skipped releasing the literals and the axioms because they are still in use,  therefore all connected objects still stay in memory.

Solution: I cloned new objects from reasoning and reasoner objects (and then dispose them once they are converted them as solr index entries).

I believe similar issues would arise for many other parts of owltools but I minimally fixed the codes to avoid any other potential bugs for now.

Great! What I'm going to do is fix up the dev machine (tomodachi) with the node updates and switch owltools over to this branch for testing.

Okay, so we have a chain of issues going back to how stale tomodachi is. I'll try and clean this up on Monday up the hill.

Updated on server for testing.
@yy20716 Could you look into the conflicts with master?

FYI. I just wanted to note that it's not safe to merge this patch yet into the main branch, i.e. this one still uses the codes before this pull request. Once we confirm that the codes in that pull request work as expected, I will then incorporate the codes from that request and make an additional commit into this branch. Thank you for your patience.

I've merged #249 into master.

@yy20716 How is the status now?
Tagging #212

Seth (@kltm), I think it's now good to go but please let me know if you encounter any issues. I only tested this with dummy solr loader, so maybe there are something I couldn't consider before. Thank you for your time.

@yy20716 @cmungall
As per our discussion, let's go ahead with this code and test in amigo 2.5.x/master to optimize the time we have with @yy20716 .


networkservicemesh Installation failure (in minikube)

My setup:
OS:  Ubuntu 18.04.03 (Server)/ 8GB/2vCPU
k8s cluster(1 node) : v1.19.1   (Installed using minikube)
My cluster is operational, no issues in that.
I am trying to install networkservicemesh with below procedure
helm install nsm nsm/nsm -n nsm

This install v0.2.0 in nsm namespace
root@suresh:~# k get pods -A
NAMESPACE     NAME                                     READY   STATUS    RESTARTS   AGE
kube-system   coredns-f9fd979d6-jcx9h                  1/1     Running   1          13h
kube-system   etcd-suresh                              1/1     Running   1          13h
kube-system   kube-apiserver-suresh                    1/1     Running   1          13h
kube-system   kube-controller-manager-suresh           1/1     Running   1          13h
kube-system   kube-proxy-rq24k                         1/1     Running   1          13h
kube-system   kube-scheduler-suresh                    1/1     Running   1          13h
kube-system   storage-provisioner                      1/1     Running   2          13h
nsm           nsm-admission-webhook-6d96b4945c-9xkpv   1/1     Running   0          64s
nsm           nsm-vpp-forwarder-j4trp                  0/1     Running   0          63s
nsm           nsmgr-sd9rd                              2/3     Running   0          64s
spire         spire-agent-v56zf                        1/1     Running   0          64s
spire         spire-server-0                           1/1     Running   0          63s

nsm-vpp-forwarder pod is not running and nsmd container is not running.
  Normal   Created    2m12s                kubelet            Created container nsmd-k8s
  Normal   Killing    94s                  kubelet            Container nsmd failed liveness probe, will be restarted
  Normal   Created    64s (x2 over 2m13s)  kubelet            Created container nsmd
  Normal   Pulled     64s (x2 over 2m13s)  kubelet            Container image "docker.io/networkservicemesh/nsmd:v0.2.0" already present on machine
  Normal   Started    64s (x2 over 2m13s)  kubelet            Started container nsmd
  Warning  Unhealthy  46s (x7 over 116s)   kubelet            Readiness probe failed: Get "http://<IP_ADDRESS>:5555/readiness": dial tcp <IP_ADDRESS>:5555: connect: connection refused
  Warning  Unhealthy  44s (x5 over 114s)   kubelet            Liveness probe failed: Get "http://<IP_ADDRESS>:5555/liveness": dial tcp <IP_ADDRESS>:5555: connect: connection refused
root@suresh:~#

The nsmd log shows
2020/10/16 03:06:25 Initializing logging reporter
time="2020-10-16T03:06:25Z" level=info msg="==--> nsmd.server() span:48e90280998da5b1:48e90280998da5b1:0:1"
time="2020-10-16T03:06:25Z" level=info msg=">><<-- tracing.init-complete=1.423355715s span=48e90280998da5b1:48e90280998da5b1:0:1"
time="2020-10-16T03:06:25Z" level=info msg="==----> StartPluginRegistry() span:48e90280998da5b1:75681aefe5d23a05:48e90280998da5b1:1"
time="2020-10-16T03:06:25Z" level=info msg="==------> NewServer() span:48e90280998da5b1:620e947847a6d99e:75681aefe5d23a05:1"
time="2020-10-16T03:06:25Z" level=info msg="==--------> GetCertificate() span:48e90280998da5b1:5b9f48288919714c:620e947847a6d99e:1"
time="2020-10-16T03:06:25Z" level=info msg="FetchX509SVID.Recv failed with rpc error: code = PermissionDenied desc = no identity issued; retrying in 1s"
time="2020-10-16T03:06:26Z" level=info msg="FetchX509SVID.Recv failed with rpc error: code = PermissionDenied desc = no identity issued; retrying in 1.5s"
time="2020-10-16T03:06:27Z" level=info msg="FetchX509SVID.Recv failed with rpc error: code = PermissionDenied desc = no identity issued; retrying in 2.25s"
time="2020-10-16T03:06:30Z" level=info msg="FetchX509SVID.Recv failed with rpc error: code = PermissionDenied desc = no identity issued; retrying in 3.375s"
time="2020-10-16T03:06:33Z" level=info msg="FetchX509SVID.Recv failed with rpc error: code = PermissionDenied desc = no identity issued; retrying in 5.0625s"
time="2020-10-16T03:06:38Z" level=info msg="FetchX509SVID.Recv failed with rpc error: code = PermissionDenied desc = no identity issued; retrying in 7.59375s"
time="2020-10-16T03:06:46Z" level=info msg="FetchX509SVID.Recv failed with rpc error: code = PermissionDenied desc = no identity issued; retrying in 11.390625s"
time="2020-10-16T03:06:57Z" level=info msg="FetchX509SVID.Recv failed with rpc error: code = PermissionDenied desc = no identity issued; retrying in 17.0859375s"
^C

vppagent events also
Events:
  Type     Reason     Age                   From               Message
  ----     ------     ----                  ----               -------
  Normal   Scheduled  4m59s                 default-scheduler  Successfully assigned nsm/nsm-vpp-forwarder-j4trp to suresh
  Normal   Pulled     4m58s                 kubelet            Container image "docker.io/networkservicemesh/vppagent-forwarder:v0.2.0" already present on machine
  Normal   Created    4m57s                 kubelet            Created container vppagent-forwarder
  Normal   Started    4m57s                 kubelet            Started container vppagent-forwarder
  Warning  Unhealthy  68s (x22 over 4m38s)  kubelet            Readiness probe failed: HTTP probe failed with statuscode: 503
root@suresh:~#

Not sure, what is the issue.
I tried with "master" tag also.
With master tag ,    I observe the same behavior ( nsm-vpp-forwarder pod is not running and nsmd container is not running.) and READINESS PROBE failed events in the pods.
But in the logs,   PermissionDenied messages are not showing..
Could some one help to resolve this issue.
Thanks
suresh

Is there a reason you can't use kind?

Is there a reason you can't use kind?
By the way it works in "minikube". & helm 3.

The document present in the website(below one) is  outdated, and its not working. This issue is raised based on this doc
https://networkservicemesh.io/docs/setup/run/
I followed the doc present in the github
https://github.com/networkservicemesh/networkservicemesh/blob/master/docs/guide-helm.md
This perfectly works fine :+1:

@sureshkvl Thank you for the pointers to the out of date docs!  Would you be interested in contributing a PR to fix them?


extension proposal

:dancers:
The goal of this PR is to enable API extensions to the distribution-spec (registry API), so that implementations may experiment, and then once ironed out can propose the API paths be documented canonically here in the OCI distribution-spec.
There will be a place in this spec repo for official extensions to live once ratified. But importantly, it should provide a method for registry/client implementors to iterate on extensions before surfacing them to be solidified in the specification.
The challenges faced are:

how to span registry-wide vs specific repo/app contexts
honor ACL handling
not pollute every existing endpoint

Fixes #74
Signed-off-by: Vincent Batts<EMAIL_ADDRESS>

@opencontainers/distribution-spec-maintainers PTAL
@josephschorr I would imagine the pub-sub to be under extensions here
@justincormack @jonjohnsonjr  I would imagine a signature extension here, so that a signature payload on a digest could be pushed to a registry, then the signature extension allows discovering the digests of signatures associated

from a discussion that @dmcgowan and I had today.
While I thought that all the endpoints of any given extension would be sandboxed in its prefix, Derek points out how that could make the ACLs a bit too tricky, without wholly expecting an extension to copy API patterns.
So we walked through both.
We used the notary v2 use-case as our first concrete example.
Notes below (copied from https://hackmd.io/Ljkrt0LORmeVznREeGOWuQ):
GET /v2/_ext/

{
  "0" : {},
  "sigs": {"doc":"http://github.com/opencontainers/distribution-spec/trees/master/ext/ext-sigs.md"}
}

/v2/_ext/sigs/   (reserved for sigs extension)

GET /v2/_ext/sigs/<hash>/<digest>/<name>
POST /v2/_ext/sigs/<hash>/<digest>/<name>
DELETE /v2/_ext/sigs/<hash>/<digest>/<id>

GET /v2/<repo name>/sigs/<hash>/<digest>
POST /v2/<repo name>/sigs/<hash>/<digest>
PUT /v2/<repo name>/sigs/<hash>/<digest>/<hash>/<digest>
DELETE /v2/<repo name>/sigs/<hash>/<digest>/<hash>/<digest>
                            |<--signed---->|<--signature-->|

{
  "0": {
    "mediaType":"...signature...blob",
    "size": 100,
    "digest": "sha256:deadbeef"
  }
}

What ever mediaType of the signature object itself should be parseable to reference the digest of the blob that it is a signature for. (for garbage collection)

@vbatts The concern I have there is overlap: if I currently have a registry that supports multiple levels of nesting, and I have a repository named mynamespace/arepo/sigs (for whatever reason), now I have a conflict on the paths. Does that means I get the repository responses back, or do I get the sigs for mynamespace/arepo (it might exist on its own, afterall). A similar problem does exist today, but its currently limited in the API, where moving forward this wouldn't be the case.
Perhaps all extensions under the existing API should be prefixed with a character not supported by the current repo names? Like... GET /v2/<repo name>/_/sigs/<hash>/<digest>?

@josephschorr when the API was originally being designed a similar issue also came up with tags, hence the odd tags/list endpoint for listing tags. It may have been a limitation of the handlers we were using at the time, but there was always two parts matched at the end to get around the ambiguity (@stevvooe for more context). I kind of like the idea of differentiating with a "_", maybe "_sigs" is enough. As long as we apply the rule consistently for new endpoints.

Why not just adopt something like the .well_known and let the servers define their own URL prefixes and try and stay as much out of their way as possible? Imposing versioning and all of this other stuff in the URL seems pretty non-ideal.

@jzelinskie I'm highly concerned of overlap: its guaranteed that registries, today, have /v2/... reserved for registry use. If we allow extensions to place themselves wherever they please at the top level, we will likely quickly run into conflicts with existing per-implementation endpoints. .well-known is a good idea, but it should ideally be discoverable as part of the existing OCI endpoints.

For new extensions that are being proposed, but have not yet been accepted into the spec, do we want to set a standard for naming that distinguishes a proposed-extension from a standard-extension?  I'm thinking along the lines of vendor prefixes for CSS; this could allow a registry operator to experiment and provide an endpoint for a feature where there isn't yet consensus in the community.

What will this extension covers? Everything in the brainstorm?

scope of the extensions:
 extensions are meant as a way to extend on the generic basic workflows available in the distribution-spec

A way to have a handshake between client-server for additional features capable. e.g. search, signatures, discoverability. etc
The hope of having a server expose which features it implements vs. a newer version (i.e. /v2/) that implements new features, in synchrony.
It's okay to add a batch of OPTIONAL features to the spec, with language around "if you use this OPTIONAL http endpoint then you MUST use the corresponding ones".
I'm really wondering whether this is even the correct approach.
If these features are the right and good for distribution-spec (the API), then just put them in the spec and rev the version.
(Having a call with @dmcgowan @jzelinskie @mikebrow @jdolitsky @vbatts)

This basically needs community discussion around "how can i experiment with bringing in new features, or have my own bespoke feature"

What was the consensus here?
At the root:
/v2/_ext/oci-artifacts/v1/{namespace}/repo/manifests/{digest}/links
or, at the repo
/v2/{namespace}/repo/manifests/{digest}/_ext/oci-artifacts/v1/links
Basically, should _ext/ be a reserved extension anywhere in the uri?

@vbatts, @dmcgowan, @justincormack, in today's OCI weekly call, we discussed moving forward with https://github.com/opencontainers/distribution-spec/pull/111/ where we document v2/_ext/ as a reserved namespace for extensions. The question was then: should we use numbered items, and let people fight for reserving a number while they develop and hopefully ship their extension. Or, named elements that have no order. Just uniqueness.

now that 1.0 is tagged, and a number of conversations that touched on this proposal have progressed, I intend to dust this off and find the path forward.

Thanks @vbatts, here's a prototypical example for the reference types: https://github.com/opencontainers/artifacts/pull/29
A direct link to the referrers API

I like the idea here but getting the paths right can be difficult. The problem we solved with tags/list was that you needed something to anchor the path grammar. Something like /tags/ was just as effective, since we have a terminating slash (there was a proposal for this at one time) but it is subtle. This is probably overly conservative but prevents future incompatibilities while still namespacing operations beneath a repository. Without getting into the finer points of why putting user input into a path is a bad idea, it works well enough. 👏
In general, I always saw /v2/_<thing>, such as /v2/_catalog as extensions to the API. Early notary proposals had something like /v2/_notary. In reality, there are two main things we need to cover:

Registry-level extensions.
Repository-level extensions.

That underscore is ugly, indeed, but isn't supported in the repository name grammar so works well as an escape. We can safely introduce the following two path components to the specification and get away with it:

/v2/_<ns>/<ext>/<component>[?<key>=<value>&...] would provide access to a registry-level extension.
/v2/<name>/_<ns>/<ext>/<component>[?<key>=<value>&...] would provide access to repository-level extensions.

This satisfy requirements for namespacing, for the most part. The path syntax for the namespace is limited to keep things simple. We restrict extensions to query parameters. Paths are a nightmare for user input and query parameters reduce these ambiguities. I'd favor the simple approach of keeping it to the above anchor points, meaning that we have registry and repo level extensions.
Let's roll through that exercise a bit. From the proposed artifacts extension:
/oci-artifacts/v1-rc1/{repository}/manifests/{digest}/referrers?n=10
This would become something like this:
/v2/<name>/_oci/artifacts/referrers?digest={digest}&n=10
Notice we can elide the version number because we use the mediatypes to version content in oci. We might want to define some conventions for pagination and assumed object references to keep things consistent.
I think one thing that needs to be worked out is whether extensions will be a free for all or more like an a la carte set of APIs that registries can choose to implement or not. I really favor the a la carte model, as it ensures that registries can choose which features make sense for their use case, but will ensure compatibility between extensions. I do understand the desire to have an open extension model, however.
It might a good idea to take these examples through a few more use cases to see how they work out. I want to make sure we have some strong conventions for additions, follow the model of versioned data types but still allow for objects that exist outside the artifact/image's CAS lineage.

+1
The referrers API is currently rooted under  {host}/oras/artifacts/v1/. Implementers including our own internal deployments run distribution and expect their path to be {host}/v2/ for different ACLS or ingress rules.
Providing an ability for extension /v2/<name>/_oci/artifacts/referrers?digest={digest}&n=10 will enable extension to be added without needing to open up new paths on the ingress controllers.
My hope here is that if we get agreement on this issue then there is a possibility of queuing up support into the reference implementation like CNCF/distribution.
I would image that /v2/<name>/_oci/ would be reserved for OCI specific extensions and extension authors can follow the same pattern. like `/v2//_oras/.

I've updated the OP comment to outline the goals of this PR.
My very original thought was to have a framework that is as flexible as the concept of HTTP Headers: there are some expected, arbitrary optional ones, but some have grown to be established norms.
After staring at maintaining the goals here, it's not clear that the addition/experimentation of any given extension is on the whole any different than folks just adding OPTIONAL routes to their registry, and then proposing them to the core of OCI distribution-spec once they're tested and refined.

Thanks @vbatts for the update. Capturing the permissions challenges with registry wide, a namespace, or specific to a repo helps define the requirements for the extensions.
For example:

docker hub, github and gcr use a single domain, with a root namespace to delineate "registry ownership" docker.io/org, gcr.io/project/repo
acr, ecr and others use a domain to differentiate a registry [myregistry].azurecr.io, [aws_account_id].dkr.ecr.us-west-2.amazonaws.com/
An auth-token may only have access to a specific repo, registry.io/org/team/repo, so making calls to registry.io/_foo raises security challenges.

from @stevvooe on slack

there is an extension endpoint hanging off of /v2 , a registry extension, and an extension endpoint hanging off of /v2/ , a repository extension. They each have discovery extensions. If the endpoint for the registry is called, no repository name is included. if the endpoint for the repository is called, then the repository name is included. This allows one to calculate the full extension url from the json.

https://github.com/opencontainers/distribution-spec/blob/main/spec.md#endpoints

@stevvooe right on. That covers ACLs.
This implies that if any extension that deals in the /v2/<name>/_... space, but may work with blobs, digests and/or manifests, then the extension may recreate/emulate existing endpoints in the core API. Which is a bit sloppy to me, but is "flexible" for folks.

I wanted to summarize more the discussion we had on slack regarding extensions:

Paths: Extension paths are a slash-separated triple, consisting of a namespace, component and operation, in the format of _<namespace>/<component>/<operation>.
a. Namespace: A namespace corresponds to a single extension or set of extensions.
b. Format: Path components must follow the same restrictions as repository name components.
c. Definition: We don't define the meaning of component and operation. Extension providers may organize them as they see fit but are recommend to organize these in a way that allows their extension to change over time.
d. Example: For the proposed discovery endpoint, the triple would be _oci/ext/discover. We can say that "the OCI extension provides a discover endpoint for extensions."
Path Mounting in API: There are two places that an extension may appear in the path hierarchy:
a. Registry-level Extension: A registry-level extension is mounted at the root of the /v2/ path. The full path format would be /v2/_<namespace>/<component>/<operation>
b. Repository-level Extension: A repository-level extension is mount at <name>, as a sibling of blobs and manifests of the /v2/<name> path. The full path format would be /v2/<name>/_<namespace>/<component>/<operation>
Discovery: The discovery extension provides discovery of extension endpoints, identified by the triple _oci/ext/discover. It will also act as an example of how to implement an extension in an idiomatic way.
a. Registry-level: The /v2/_oci/ext/discover will provide a list of extensions available at the registry level. It will respond to GET requests with the following format:
{      "extensions": [        {          "path": "_<namespace>/<component>/<operation>"        }, ...      ]    }
b. Paths for the extension can be assembled by joining /v2/ with the extension path, such that the complete path would be in the format /v2/_<namespace>/<component>/<operation> for each extension entry.
c. Registry-level: The /v2/<name>/_oci/ext/discover will provide a list of extensions available at the repository level. It will respond to GET requests with the following format:
{      "repository": "alpine",      "extensions": [        {          "path": "_<namespace>/<component>/<operation>"        }, ...      ]    }
d. Paths for the extension can be assembled by joining /v2/<name> with the path, where name is specified in the repository field, such that the complete path would be in the format /v2/<name>/_<namespace>/<component>/<operation> for each extension entry.

I know this is a bit dense but hopefully I've covered all of the points.

For the above, I prefer the word <module> over <operation>. Please vote on this comment if we prefer that change.

Summarizing requirements on registering extensions:

Add language to have folks register their namespaces to ensure they don't overlap:
"_notice_: All new `./ext/ext-$ns-$name.md` docs MUST/SHOULD be added to this table."
Must include link to documentation, source repository, tests, sensible naming
Reservation for _oci and former extensions (ie _catalog)

updated PTAL

@opencontainers/distribution-spec-maintainers PTAL

:clap:


Only flag html method if jQuery (#425)

Add unit tests for isJQuery method
Add new method, isJQueryExpression, which returns true if the
expression is a result of a jQuery function call or a function
expression on a variable whose name starts with $, which is a common
convention for identifying variables which are the result of a jQuery
expression; add tests for it
Modify no-inner-html to only flag method calls if the method
invocant appears to be a jQuery expression

Resolves #425

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

@HamletDRC, ping? :)

Thanks for the PR @amacleay! I posted some feedback on the linked issue.

New commit makes the matcher configurable via an option named jquery-matcher

html-lib-matcher and htmlLibExpressionRegex seem alright? html-matcher to me suggests it's a regex for matching an expression which is HTML.

For example, if a project only uses Cheerio, they might not know or feel comfortable using a config option that only references jQuery.

I personally don't have a preference on naming, but note that even Cheerio mentions it's an implementation of core jQuery, so that would probably not sound unfamiliar to Cheerio users.

@JoshuaKGoldberg, do you need anything else to be able to merge this?
Also, any chance you could make a release? We'd love to consume a published version of this :)

Ah my apologies, the only blocker was me forgetting to hit a button.
For a release, sure - I've only recently become a maintainer of the repository so I'll schedule some time with @HamletDRC soon™ to get that going!


Fixing pmd:InsufficientStringBufferDeclaration - Insufficient String Buffer Declaration

This pull request is focused on resolving occurrences of Sonar rule
pmd:InsufficientStringBufferDeclaration - "Insufficient String Buffer Declaration".
You can find more information about the issue here:
https://sonar.spring.io/coding_rules#rule_key=pmd:InsufficientStringBufferDeclaration
Please let me know if you have any questions.
Artyom Melnikov

Thanks Artyom


Read/set favorite values from the desk provided from the Linak Desk Control app

I just got an Ikea Idasen and I also installed the Desk Control app from Linak that is also compatible. The app allows you to set 3 predefined profiles and after that, you can use the controls on the desk to "snap" to those profiles while also allowing you to move between them.
Would "setting" profiles be something you're interested in implementing? Maybe even getting those profiles from the desk itself (like you're reading the height) so they are always in sync.
Let's say the desk is at height 741. You have a set a profile from the app to height 758 and another at 1152.
You pull the button up so you start raising the desk. It will keep rising until it reaches 758, then wait a second. If the button is still pressed, it will start rising again until it reaches 1152, at which point it will wait for a second again.
It would be really cool to have 3 profiles from the config sync with the 3 profiles set from the app, as well as being able to set new values from the CLI which can then be used with the hardware controls as well. This way, I can either control the desk and the profiles via it's hardware buttons, my personal laptop, or my phone when I'm using the work laptop.

Found the code for an app that already seems to implement setting favorite values here
I will test the app and follow along the lines to see if I can figure it out. I did send a packet with nRF Connect Android app but it seemed to clear all my favorites instead, so I might have done something wrong with the data I sent.

Thanks to the DPG1C issue I think I understand enough to implement this. Do you have suggestions for how it would work?
One idea, we have some special favourite names "favourite-1", "favourite-2" etc. which correspond to the favourite slots in the desk/app.
If you do not set these in the idasen controller config then using them in the --move-to favourite-1 argument will check the value from the desk first, and then move to it.
If you do set these values in the idasen controller config then using them in the --move-to favourite-1 will move to that height and write the value to the desk favourite.

Honestly, this sounds like the best behavior.


fix docs

fixes docs
adds undodir
fixes cirlce-ci
fixes docs
updates packages
updates site
bugfix

Codecov Report

Merging #17 (21eda76) into master (55a2511) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master       #17   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            1         1
  Lines           11        11
  Branches         2         2
=========================================
  Hits            11        11

Impacted Files
Coverage Δ

fastapi_camelcase/__init__.py
100.00% <100.00%> (ø)


⚠ GitLab Server has degraded performance

In 08f9eec, GitLab Server (https://gitlab01.its-telekom.eu) experienced degraded performance:

HTTP code: 200
Response time: 6957 ms

Resolved: GitLab Server performance has improved in f9ade42.


Security issue: read-only canned queries leak CSRF token in URL

The HTML form for a read-only canned query includes the hidden CSRF token field added in #798 for writable canned queries (#698).
This means that submitting those read-only forms exposes the CSRF token in the URL - for example on https://latest.datasette.io/fixtures/neighborhood_search submitting the form took me to:
https://latest.datasette.io/fixtures/neighborhood_search?text=down&csrftoken=IlFubnoxVVpLU1NGT3NMVUoi.HbOPd2YH_epQmp8f_aAt0s-MxtU
This token could potentially leak to an attacker if the resulting page has a link to an external site on it and the user clicks the link, since the token would be exposed in the referral logs.

Fix has been released in Datasette 0.46: https://datasette.readthedocs.io/en/latest/changelog.html#v0-46

It's worth noting that in order to exploit this issue the following would all need to be true:

A user is running a copy of Datasette protected by a cookie-based authentication plugin AND configured with at least one writable canned query
An attacker is in control of a URL that could concievably be returned on a page that is displayed as the result of submitting a read-only canned query
An authenticated user of that Datasette instance, who is running a browser that doesn't support the SameSite=lax cookie parameter (which is widely supported by modern browsers), submits the read-only canned query form and then clicks a link to the attacker's off-site page, exposing their CSRFToken in the attacker's HTTP referer logs
The attacker then tricks that user into visiting their own malicious web page which includes a POST form that auto-submits against the writable canned query that the attacker wishes to exploit, including the CSRF token as a hidden field

The attacker would need full knowledge of the URL and form layout of the Datasette instance that they are exploiting.

Submitting the form on https://latest.datasette.io/fixtures/neighborhood_search demonstrates that this is fixed.

GitHub security advisory: https://github.com/simonw/datasette/security/advisories/GHSA-q6j3-c4wc-63vw


Why use 1024x1024 output instead of 512x512, up sampling doesn't increase the real resolution?

Hi @xuebinqin ,
I looked at the ISNET model code and saw that the model always takes 1024x1024 input and produces 1x512x512 (d1 before up sample) output which later on is up-sampled to 1x1024x1024 (in the model.forward code). This is also the same for the GT Encoder. So, it makes no sense to up sample 1x512x512 to 1x1024x1024 in my opinion because the real output resolution is always 512x512.

Could you explain the reasoning behind this?

not exactly. set the input as 1024x1024 will gain more details and at the
same time the receptive fields will be different from 512x512 input. More
importantly, upsample from 512x512 to 1024x1024 at the end seems just an
upsample operation. Please remember the supervision is conducted on
1024x1024. The model will be forced to produce more suitable 512x512 maps
for the upsampling operation to achieve details. Later on, if you don't
care about the memory costs, you can also switch the d0 line one and
retrain the model to enable one more convolution on high resolution maps
for achieving more details.
On Sat, Dec 3, 2022 at 11:54 AM Akif Faruk Nane @.***>
wrote:

Hi @xuebinqin https://github.com/xuebinqin ,
I looked at the ISNET model code and saw that the model always takes
1024x1024 input and produces 1x512x512 (d1 before up sample) output which
later on is up-sampled to 1x1024x1024 (in the model.forward code). This is
also the same for the GT Encoder. So, it makes no sense to up sample
1x512x512 to 1x1024x1024 in my opinion because the real output resolution
is always 512x512.
[image: image]
https://user-images.githubusercontent.com/37745467/205459314-77bdc3ce-f7c4-41e6-92bf-b018e98c7a3a.png
Could you explain the reasoning behind this?
—
Reply to this email directly, view it on GitHub
https://github.com/xuebinqin/DIS/issues/61, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADSGORKZAWZ75K2EQ2KDWM3WLOQQFANCNFSM6AAAAAASS5F2AQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Xuebin Qin
PhD
Department of Computing Science
University of Alberta, Edmonton, AB, Canada
Homepage: https://xuebinqin.github.io/

not exactly. set the input as 1024x1024 will gain more details and at the same time the receptive fields will be different from 512x512 input. More importantly, upsample from 512x512 to 1024x1024 at the end seems just an upsample operation. Please remember the supervision is conducted on 1024x1024. The model will be forced to produce more suitable 512x512 maps for the upsampling operation to achieve details. Later on, if you don't care about the memory costs, you can also switch the d0 line one and retrain the model to enable one more convolution on high resolution maps for achieving more details.
…
On Sat, Dec 3, 2022 at 11:54 AM Akif Faruk Nane @.> wrote: Hi @xuebinqin https://github.com/xuebinqin , I looked at the ISNET model code and saw that the model always takes 1024x1024 input and produces 1x512x512 (d1 before up sample) output which later on is up-sampled to 1x1024x1024 (in the model.forward code). This is also the same for the GT Encoder. So, it makes no sense to up sample 1x512x512 to 1x1024x1024 in my opinion because the real output resolution is always 512x512. [image: image] https://user-images.githubusercontent.com/37745467/205459314-77bdc3ce-f7c4-41e6-92bf-b018e98c7a3a.png Could you explain the reasoning behind this? — Reply to this email directly, view it on GitHub <#61>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSGORKZAWZ75K2EQ2KDWM3WLOQQFANCNFSM6AAAAAASS5F2AQ . You are receiving this because you were mentioned.Message ID: @.>
-- Xuebin Qin PhD Department of Computing Science University of Alberta, Edmonton, AB, Canada Homepage: https://xuebinqin.github.io/

Yes, I think what you are saying is true, but I'm not talking about the input size. The input size being 1024x1024 will have more details and therefore the model can produce better detailed 512x512 maps (more accurate and sharper maybe). However, I think, if I were to make the model output 512x512 instead of 1024x1024 (the input size is still the same), it would produce exactly the same quality & accuracy. What are your thoughts on that? Just thinking out loud...
Also, I'd like to ask, did you have any chance to experiment with the first decoder output being 1024x1024 (before up sample)?
Thank you so much!

The inference scheme needs to be consistent with the training. Bilinear
with add a bit more details especially trained with the scheme, then why
not using it. We did test output 1024, but outputing 1024 directly wont
improve the perforkance that much, however it will greatly increase the gpu
memory costs.
On Sat., Dec. 3, 2022, 1:44 p.m. Akif Faruk Nane, @.***>
wrote:

not exactly. set the input as 1024x1024 will gain more details and at the
same time the receptive fields will be different from 512x512 input. More
importantly, upsample from 512x512 to 1024x1024 at the end seems just an
upsample operation. Please remember the supervision is conducted on
1024x1024. The model will be forced to produce more suitable 512x512 maps
for the upsampling operation to achieve details. Later on, if you don't
care about the memory costs, you can also switch the d0 line one and
retrain the model to enable one more convolution on high resolution maps
for achieving more details.
… <#m_7669795789231832260_m_4406007961573205366_m_8068708913753148354_>
On Sat, Dec 3, 2022 at 11:54 AM Akif Faruk Nane @.> wrote: Hi
@xuebinqin https://github.com/xuebinqin https://github.com/xuebinqin
https://github.com/xuebinqin , I looked at the ISNET model code and saw
that the model always takes 1024x1024 input and produces 1x512x512 (d1
before up sample) output which later on is up-sampled to 1x1024x1024 (in
the model.forward code). This is also the same for the GT Encoder. So, it
makes no sense to up sample 1x512x512 to 1x1024x1024 in my opinion because
the real output resolution is always 512x512. [image: image]
https://user-images.githubusercontent.com/37745467/205459314-77bdc3ce-f7c4-41e6-92bf-b018e98c7a3a.png
https://user-images.githubusercontent.com/37745467/205459314-77bdc3ce-f7c4-41e6-92bf-b018e98c7a3a.png
Could you explain the reasoning behind this? — Reply to this email
directly, view it on GitHub <#61
https://github.com/xuebinqin/DIS/issues/61>, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADSGORKZAWZ75K2EQ2KDWM3WLOQQFANCNFSM6AAAAAASS5F2AQ
https://github.com/notifications/unsubscribe-auth/ADSGORKZAWZ75K2EQ2KDWM3WLOQQFANCNFSM6AAAAAASS5F2AQ
. You are receiving this because you were mentioned.Message ID: @.>
-- Xuebin Qin PhD Department of Computing Science University of Alberta,
Edmonton, AB, Canada Homepage: https://xuebinqin.github.io/
Yes, I think what you are saying is true, but I'm not talking about the
input size. The input size being 1024x1024 will have more details and
therefore the model can produce better detailed 512x512 maps (more accurate
and sharper maybe). However, I think, if I were to make the model output
512x512 instead of 1024x1024 (the input size is still the same), it would
produce exactly the same quality & accuracy. What are your thoughts on
that? Just thinking out loud...
Also, I'd like to ask, did you have any chance to experiment with the
first decoder output being 1024x1024 (before up sample)?
Thank you so much!
—
Reply to this email directly, view it on GitHub
https://github.com/xuebinqin/DIS/issues/61#issuecomment-1336263509, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ADSGORPSXAGMWWAFMYAQLUTWLO5KTANCNFSM6AAAAAASS5F2AQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

@xuebinqin Thank you for your answers. What about using up convolution layers at the end (Up-sampling with Transposed Convolution), did you ever try it? (not saying making the decoder itself work in 1024x1024)
This wouldn't add so much memory cost?

But would it be helpful for better accuracy?

That is a good point. I personally don't think transpose conv making that
much sense. you can think about the difference between (1) transpose conv
and (2) bilinear upsample+conv. We did try the (2), which didn't give
perceivable differences. The problem about adding this kind of modules may
not help that much is because all the deep models are "over-fitting" in
some ways on certain training sets. Simply to see, the model is already
"overfitting" on training set. The newly added modules are high likely just
further over fit the training set. In my point of view, think and study
more on the distribution description and comparison are more important than
adding "modules". Of course, more efficient and effective modules are also
non-trivials and should be encouraged. Anyway, you can give it a try,
without experiments no one can tell if it works or not, especially in deep
learning. All the best.
On Sat., Dec. 3, 2022, 3:18 p.m. Akif Faruk Nane, @.***>
wrote:

@xuebinqin https://github.com/xuebinqin Thank you for your answers.
What about using up convolution layers at the end (Up-sampling with
Transposed Convolution), did you ever try it? (not saying making the
decoder itself work in 1024x1024)
This wouldn't add so much memory cost?
[image: image]
https://user-images.githubusercontent.com/37745467/205466170-c61095a0-d277-4363-92cc-9d672bc17753.png
But would it be helpful for better accuracy?
—
Reply to this email directly, view it on GitHub
https://github.com/xuebinqin/DIS/issues/61#issuecomment-1336276644, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ADSGORN6AOFFFLWXVFDJRE3WLPILVANCNFSM6AAAAAASS5F2AQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

Thank you for your answers again. I hope I understand what you mean correctly. If I can experiment about it on my own, I will be happy to let you know about the results. The modules are kind of important to create an ability to learn by providing mathematical pathways. But an ability to learn doesn't guarantee to learn well. Also other things are importamt as you mentioned such as over fitting.

Yes, exactly. That's why in our paper we suggest more researchers to pay a
bit more attention to the (data) distribution description and analysis.
Great modules will help to provide practically usable models for the
society, which has been greatly developed in the past few years.
Distribution analysis could be a great starting point to unveil the essence
of the "black box" (deep models).
On Sat, Dec 3, 2022 at 4:25 PM Akif Faruk Nane @.***>
wrote:

Thank you for your answers again. I hope I understand what you mean
correctly. If I can experiment about it on my own, I will be happy to let
you know about the results. The modules are kind of important to create an
ability to learn by providing mathematical pathways. But an ability to
learn doesn't guarantee to learn well. Also other things are importamt as
you mentioned such as over fitting.
—
Reply to this email directly, view it on GitHub
https://github.com/xuebinqin/DIS/issues/61#issuecomment-1336286275, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ADSGORMONA4UKPMPP3L4CYTWLPQGBANCNFSM6AAAAAASS5F2AQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Xuebin Qin
PhD
Department of Computing Science
University of Alberta, Edmonton, AB, Canada
Homepage: https://xuebinqin.github.io/


Undefining a data variable or function does not remove the symbol for it

Open a binary
Select a function/data variable
Notice bv.get_symbol_at(here) shows the  symbol for what you have selected
Hit u or use undefine from the context menu
Notice bv.get_symbol_at(here) still shows the  symbol for what you have selected

It only removes a user symbol iirc. Is it the case?

Not completely sure here but we might re-parse on BNDB re-load and this might cause the auto symbol to be reloaded. If this is the case then we'd need a symbol black list like we have for functions and data variables already.


Optimize cursor creation and proxy connection state initialization.

Motivation
1.Cannot be removed when the cursor failed callback is called synchronously.
2.The state should be initialized first when the proxy connects to the broker.
Verifying this change

[ x ] Make sure that the change passes the CI checks.

(Please pick either of the following options)
This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end deployment with large payloads (10MB)
Extended integration test for recovery after broker failure

Documentation
Check the box below.
Need to update docs?

[ ] doc-required
(If you need help on updating docs, create a doc issue)

[ x ] no-need-doc
(Please explain why)

[ ] doc
(If this PR contains doc changes)

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: gaoran10:x: mingyifeimingyifei seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Delete manifests/j/JanDeDobbeleer/OhMyPosh/7.43.0 directory

[ ] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.2 schema?

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

Microsoft Reviewers: Open in CodeFlow

@wingetbot run


Can not compile "simple_daplink.ino"

I’m trying to compile “simple_daplink” refer to "How to use Arduino Boards as DAPLink Device", but I’m having trouble getting the following compilation error. The library I’m using are “Adafruit_TinyUSB_Arduino-1.7.1” and “Seeed_Arduino_DAPLink-1.0.2”.
Can anyone help me?
........
........
Error while detecting libraries included by C:\Users\username\Documents\Arduino\libraries\Adafruit_TinyUSB_Arduino-1.7.1\src\class\msc\msc_device.c
........
........
Error while detecting libraries included by C:\Users\username\Documents\Arduino\libraries\Adafruit_TinyUSB_Arduino-1.7.1\src\device\usbd_control.c
........
........
exit status 1

cannot declare variable 'usb_hid' to be of abstract type 'Adafruit_USBD_HID'

I solved it by reading "Issues # 8 daplink_v2.ino" and using "Adafruit TinyUSB Library 0.10.5".
Thanks.


Sending single request

When a specified user is taken it only sends out one request in attempt to claim it, not sure if im doing anything wrong if so plz lmk.

I see, what doesn't make sense to me is if you were to attempt to claim/snipe a username that is inactive by having the program running this wouldn't be possible because it only sends out one request in attempt to claim it. Unless you were to add multiple fields of the same username which still wouldn't work because it would bug out and automatically close the program. The only way you would be able to claim an inactive username using this is if you were to know when it gets deleted and open the program then. Which still would be pointless bc ur better off just hand claiming it if you can. It would be more efficient and have higher success chances in claming / sniping the username if it has a customizable rps / attempts to claim thing that is optional idk. Its kinda hard to explain hopefully you understand, this obviously wont be easy to add but would make things alot smoother for claiming/sniping the username and would give the people who use this program a variety of options to choose from rather then using this as a username swapper. Note: i saw that proxies isn't checked, maybe this is a feature that will be implemented soon?

there isn't really a certain way to know when a username will get deleted other than if the status for that username is "Last seen a long time ago" which would indicate that they've been offline for more than a month, the default setting for telegram accounts is that their account will be deleted after 6 months of inactivity
I will look into implementing that feature and implementing proxies if possible for sure, thank you so much for mentioning it :)
Eta for the update: 2 days and I will have it pushed as well as a new release uploaded so you can set it up quicker, if you want me to update you through telegram, drop your handle here and I will personally shoot you a dm as soon as it's pushed

forgot to clarify about this part:

I see, what doesn't make sense to me is if you were to attempt to claim/snipe a username that is inactive by having the program running this wouldn't be possible because it only sends out one request in attempt to claim it

so, the program sends 1 request only after the username becomes available, it doesn't constantly send requests to claim it, first it checks if it's available for claiming and THEN it claims it, hope that makes it clear, i'm not the best at explaining either


Wifi roaming does not work (802.11k 802.11v 802.11r or client-side roaming) in STA mode (IDFGH-10713)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report
I'm trying to get ESP32-S2 to have as stable wifi connection as possible - that means preiodic monitoring of network and roaming to neighboring AP if necessary (e.g. current AP has RSSI below certain threshold).
I thought I would use the roaming example, but ESP32 just refuses to roam:
00:03:29.421|  +WIFI-ROAM: RSSI threshold hit (-81dBm), will try to look for better AP
00:03:29.530|  +WIFI-RRM: Sending neighbor report request
00:03:29.534|  I (13122) wpa: action frame sent
00:03:29.543|  +WIFI-RRM: Received neighbor report [LEN=31]
00:03:29.552|  0000 | 01 34 0D D0 21 F9 5D 39  36 8F 08 00 00 51 06 07 |.4..!.]9 6....Q..|
00:03:29.560|  0010 | 34 0D 78 45 58 9F 27 D1  8F 58 00 00 51 0B 0E    |4.xEX.'. .X..Q.. |
00:03:29.561|
00:03:29.569|  +WLAN-RMM: Neigbor report bssid=d0:21:f9:5d:39:36 info=0x88f op_class=81 chan=6 phy_type=7
00:03:29.580|  +WLAN-RMM: Neigbor report bssid=78:45:58:9f:27:d1 info=0x588f op_class=81 chan=11 phy_type=14
00:03:29.582|  I (13172) wpa: action frame sent
00:03:29.590|  +WIFI-RRM: Sending transition mgmt query [RES=0]
00:03:29.595|  I (13182) wpa: scan issued at time=169747532768
00:03:29.714|  I (13302) wpa: scan done received
00:03:29.718|  I (13302) wpa: action frame sent
~~ after this nothing relevant happens, no roaming or WLAN-related events... ~~

I have Ubiquiti APs and other devices on the same network roam without any problem.  I also tried to change REASON_FRAME_LOSS to REASON_RSSI in esp_wnm_send_bss_transition_mgmt_query() but nothing has changed. The example mentioned explicitely that the station will be forced to roam but this seems to be false as the station will remain on the same AP.
I also enabled 802.11r in the network but no difference in ESP32 behavior. After that I was trying to figure out how to force ESP32 to initiate client-side roaming without dropping connection altogether (by calling esp_wifi_disconnect() and then esp_wifi_connect()).
Right now it seems that ESP32 will roam only when the current connection fully drops, which is unfortunate.
So to the question:
Is there any way to either get 802.11k/v/r working or debug why it is not working? Or is there any way to force client side roaming so I can have reliable connection without having to wait for the current connection to die (or kill it by calling disconnect)?
Has anyone managed to get ESP32 to have reliable and stable connection without having to manually scan every few seconds and then manually call disconnect()/connect() when better AP becomes available?

Hello @xoores : I experienced the same problem. I am using ESP-IDF v5.1.1 and AVM Fritzbox mesh. I used a Raspberry PI and wireshark as a network sniffer. What I saw, is that the ESP sends a "BTM transition query" to the AP, but the AP ignores it. Thats why the STA does not roam. In other situations, the AP sends a BTM transition request (without a prior query from the STA), which causes the STA to roam.
For me, the big problem is, that it seems not possible with the current Wifi stack to perform a SEAMLESS roaming (i.e. without a connection loss when roaming). The wifi stack always disconnects from the old AP, and then connects to the new AP, which takes at least 2 seconds.
Espressif Team: Do you have plan to change this in the future?

Yeah it is a pain and so far nobody from Espressif did reach out to me so I don't think they are even aware of this issue... :shrug:
Right now I have to scan every 30 seconds or so and if there is a better AP, I have to disconnect (tear down all the connections, MQTT etc) and re-connect to the new AP using its BSSID.

Hello @xoores @KlausPopp , ESP devices right now only supports network assisted roaming(ie AP will tell the device on which it needs to move on using BTM request and device will blindly follow it).
We are in process of adding one application code which will do active roaming(essentially more scans and more trigger points to start roaming), that code will be available in esp-idf in coming months.
However please note that, in all these scenario station will always disconnect first from the AP then connect to the other AP.
Also if AP doesn't reply to btm request, station won't do anything in network assisted roaming(since station is supposed to follow AP's directions).  However there will be different config options in station initiated roaming where station will take different decisions based on configuration options.

Hello @kapilkedawat : Thanks for your reply. Why is it necessary to disconnect from the old AP first before connecting to the new AP. I monitored an iPhone while roaming. I does it absolutely seamless, no IP interruption occurs. I noticed that the IPhone reassociates with the new AP while it is still associated with the old AP. After some seconds, the old AP sends a disassociation request to the iPhone due to missing ACKs.
Would such an approach be possible with ESP wifi stack?

Hi @KlausPopp , This methodology is called make-before-break. However we don't have plans to implement it in near future. Only break-before-make is available with ESP devices.

Hi @kapilkedawat : Ok, could you explain why the feature is not on the raodmap. Is it due to project priority reasons, or due to a technical restriction in ESP-Hardware?

Hi @xoores have you got any leads on this issue ?... coz am facing the same issue and observed that the connected AP keeps reporting itself as the best candidate as the neighbour report is only consisting of info about connected AP

Hi @xoores : Do you know if make-before-brake isn't possible due to a hardware limitation? Or is it "just" a matter of the wifi driver?

Hi @KlausPopp, I honestly don't know :shrug: It all depends whether the ESP is physically capable talking on (possibly) two different channels...
Since @kapilkedawat told us that they don't plan to implement it and only break-before-make is available, I personally suspect that it might very well the case of HW limitation. But that is only my guess, I don't have any hard data to back that claim up. But at the very least it seems that whole ESP-IDF WLAN stack was not really written in high availability in mind so implementing proper mechanism would mean rewriting big chunk of their codebase and that is why they are dodging any hard info when it comes to this :sweat_smile:
But that is just my take on the matter and I only hope to be corrected by someone from Espressif :slightly_smiling_face:

Hello @KlausPopp and @xoores,
Implementing "make before break" will consume significantly more memory with seemingly very little benefit, making it less important from the perspective of IoT devices (it also causes network disruption). However, we are currently working on the next generation ESP roaming app, which will offer users much more control and significantly reduce roaming time. It will utilize both BTM and legacy roaming mechanisms.
Please note that network disruption will always occur in roaming in single PHY systems since the device goes off-channel multiple times for:

scanning
connection

Additionally, it has to wait for WPA2 handshake as well as DHCP to resume data transfer.

Hello @kapilkedawat : Thanks for this info. In my application, the main issue is that I need to restart all existing socket connections in case of roaming. Do you know if there is a way to keep the socket connections intact during roaming?

Hi @kapilkedawat in my case...ESP32 seem to connect randomly to the router or a repeater but not the one with the strongest WiFi-signal
So my question is:
is there a way to force the EPS32 to connect to either
the strongest signal
or
to a specified MAC-Adress?

Hi @kapilkedawat, yeah it may consume some memory but since you can get ESP with 8M of SRAM, it seems like a non-issue. :slightly_smiling_face:
Also even while it may consume more memory, I would trade that for more battery as few of my IoT nodes have quite unstable wifi connection and when they push data through the MQTT, it will disconnect several times, having to stay up way too long... :shrug:
@Saicharan67 You can for sure use BSSID of AP to connect to - that is what I'm doing right now as the roaming does not work.

@KlausPopp, IMO, it's always better to restart sockets in case of roaming (you may encounter more issues in the field if you don't do that :) ). We could have masked the ROAMING disconnect event, which will also prevent LWIP from doing an interface stop, and current sockets may continue working. However, restarting the sockets ensures that everything is refreshed, and things will work as they are supposed to be.
@xoores, as I explained earlier, for ESP devices, even after the implementation of "make before break," it will cause a network disruption since we have a single mac/rf, so multi-channel concurrency will always cause issues in connectivity. Also, the device has to disconnect before any data frame transmission (hardware limitation of station key indexes available). So, the time saved here is too low to even try that (ieee802.11 exchange generally happens under 100ms).
If you are seeing zero disruption in Apple devices, they may be using STA+STA concurrency, where the chip is capable of making two station connections simultaneously on different channels (essentially a dual mac WLAN chip).
@Saicharan67, we have a configuration for that, which is by default set to RSSI. However, please make sure the scan_method is set to FULL_SCAN. If you are experiencing any issues with that, feel free to open a new issue. Please also attach a sniffer capture and debug logs to that.

@kapilkedawat Yeah, I know that there will be slight outage, but that is not a problem as this will be transparently handled by the TCP stack (with retransmission etc).
So small outage in a range of few hundreds ms should not a problem for applications :slightly_smiling_face: There is no need to have dual wlan chip for this - that would also have to be supported by HW and I get that this would make it much more energy & memory hungry.
Problem is when there is a shutdown of all sockets during the change of AP. That way you have to connect & auth to server again (MQTT for example) and you have to basically re-do all the work.

@kapilkedawat as @xoores mentioned, the main problem is the disconnection of sockets while roaming.
Consider the following use case:
ESP32 device is installed on a forklifter. Forklifter is constantly moving between access points. Now a client tries to load recorded data from the device via http. This operation will fail when the device is roaming while the http request is active. Of course, I can think about workarounds, but in my opinion, this should work.
So can you consider to change wifi stack NOT to close underlying LWIP connections while roaming?

@KlausPopp Thanks for the work around.
Currently I am evaluating the roaming_example in IDF. What i found out while debugging is that...the responce STA get from AP (ORBI )after sending BTM transition request contains information only about connected AP which causing it to not roam by saying Already associated with the preferred candidate.
`I (1727) wifi:AP's beacon interval = 102400 us, DTIM period = 3
I (1737) roaming_example: setting rssi threshold as -50
I (1737) roaming_example: RRM supported
I (1747) roaming_example: BTM supported
I (3357) roaming_example: esp_bss_rssi_low_handler:bss rssi is=-59
W (3357) wpa: action frame sent
W (3357) wpa: RRM: Notifying neighbor report (token = 1)
I (3357) roaming_example: rrm: neighbor report len=47
I (3367) roaming_example: 0x3fc9a282   01 34 15 9a a6 7e 60 10  0e 87 d8 00 00 0                                                                                ..~.........| I (3377) roaming_example: 0x3fc9a292   06 03 01 05 00 03 01 00  34 15 9a a6 7e 5                                                                                .....4...~Y.\| I (3387) roaming_example: 0x3fc9a2a2   87 d8 00 00 00 03 0e 06  03 01 05 00 03 0                                                                                ............| I (3397) roaming_example: RMM neigbor report bssid=9a:a6:7e:60:10:0e info=0xd887                                                                                han=3 phy_type=14 I (3407) roaming_example: RMM neigbor report bssid=9a:a6:7e:59:bc:5c info=0xd887                                                                                W (3477) wpa: WNM: Send BSS Transition Management Query to 9a:a6:7e:59:b9:c5  I (3487) wnm_send_bss_transition_mgmt_query: WNM: Send BSS Transition Management                                                                                a6:7e:59:b9:c5 query_reason=1 W (3497) wpa: action frame sent W (3497) wpa: WNM: RX action 7 from 9a:a6:7e:59:b9:c5 W (3507) wpa: WNM: BSS Transition Management Request: dialog_token=1 request_mod                                                                                c_timer=0 validity_interval=100 I (3517) ieee802_11_rx_bss_trans_mgmt_req: neighbor_report_elements length 0 W (3527) wpa: WNM: Neighbor report tag 52 W (3527) wpa: WNM:neighbor report bssid:9a:a6:7e:59:b9:c5 W (3537) wpa: WNM: Subelement id=6 len=3 W (3537) wpa: WNM: Subelement id=3 len=1 W (3547) wpa: WNM: Candidate list valid for 10240 ms W (3547) wpa: WNM: Try to use recent scan results I (3557) compare_scan_neighbor_results: getting into scan compare neighbors I (3567) compare_scan_neighbor_results: number of neighbours - 09a:a6:7e:59:b9:c W (3567) wpa: WNM: Found an acceptable preferred transition candidate BSS 9a:a6:7e:59:b9:c                                                                                RSSI -59) W (3577) wpa: WNM: Transition to BSS 9a:a6:7e:59:b9:c5 based on BSS Transition M                                                                                uest after_new_scan=1) W (3597) wpa: WNM: Sending successful BSS Transition Management Response W (3597) wpa: WNM: Send BSS Transition Management Response to 9a:a6:7e:59:b9:c5                                                                                1 status=0 reason=0 delay=0 W (3607) wpa: WNM: Add candidate list to BSS Transition Management Response frame W (3617) wpa: action frame sent W (3627) wpa: WNM: Already associated with the preferred candidate W (3627) wpa: WNM: RX action 7 from 9a:a6:7e:59:b9:c5 W (3637) wpa: WNM: BSS Transition Management Request: dialog_token=1 request_mod                                                                                c_timer=0 validity_interval=100 I (3647) ieee802_11_rx_bss_trans_mgmt_req: neighbor_report_elements length 0 W (3657) wpa: WNM: Neighbor report tag 52 W (3657) wpa: WNM:neighbor report bssid:9a:a6:7e:59:b9:c5 W (3667) wpa: WNM: Subelement id=6 len=3 W (3667) wpa: WNM: Subelement id=3 len=1 W (3677) wpa: WNM: Candidate list valid for 10240 ms W (3677) wpa: WNM: Try to use recent scan results I (3687) compare_scan_neighbor_results: getting into scan compare neighbors I (3697) compare_scan_neighbor_results: number of neighbours - 09a:a6:7e:59:b9:c W (3707) wpa: WNM: Found an acceptable preferred transition candidate BSS 9a:a6:                                                                                RSSI -59) W (3717) wpa: WNM: Transition to BSS 9a:a6:7e:59:b9:c5 based on BSS Transition M                                                                                uest after_new_scan=1) W (3727) wpa: WNM: Sending successful BSS Transition Management Response W (3727) wpa: WNM: Send BSS Transition Management Response to 9a:a6:7e:59:b9:c5                                                                                1 status=0 reason=0 delay=0 W (3747) wpa: WNM: Add candidate list to BSS Transition Management Response fram W (3747) wpa: action frame sent W (3757) wpa: WNM: Already associated with the preferred candidate I (4067) roaming_example: esp_bss_rssi_low_handler:bss rssi is=-59 W (4067) wpa: action frame sent W (4077) wpa: RRM: Notifying neighbor report (token = 2) I (4077) roaming_example: rrm: neighbor report len=47 I (4077) roaming_example: 0x3fc9a2ae   02 34 15 9a a6 7e 60 10  0e 87 d8 00 00 0                                                                                ..~.........|
I (4087) roaming_example: 0x3fc9a2be   06 03 01 05 00 03 01 00  34 15 9a a6 7e 5`
When I tried with other set off MESH network (TP-Link) and tried to move from base station to satellite the STA roamed to the satellite after few BTM requests
I (116168) roaming_example: rrm: neighbor report len=31 I (116168) roaming_example: 0x3fca269e   0b 34 0d 60 a4 b7 b0 a7  12 c3 08 00 00 00 07 07  |.4.............|
I (116178) roaming_example: 0x3fca26ae   34 0d 60 a4 b7 b0 bb a6  c3 08 00 00 00 07 07     |4.`............|
I (116188) roaming_example: RMM neigbor report bssid=60:a4:b7:b0:a7:12 info=0x8c3 op_class=0 chan=7 phy_type=7
I (116208) roaming_example: RMM neigbor report bssid=60:a4:b7:b0:bb:a6 info=0x8c3 op_class=0 chan=7 phy_type=7
I (116218) roaming_example: Found Candaidate list: 0
I (116218) roaming_example: Return Value : esp_wnm_send_bss_transition_mgmt_query: 0
I (116678) roaming_example: esp_bss_rssi_low_handler:bss rssi is=-53
I (116678) roaming_example: setting rssi threshold as -50
E (117678) roaming_example: report is null
I (117908) roaming_example: esp_bss_rssi_low_handler:bss rssi is=-55
I (117908) roaming_example: setting rssi threshold as -50
I (117908) roaming_example: rrm: neighbor report len=31
I (117918) roaming_example: 0x3fca27ba   0d 34 0d 60 a4 b7 b0 a7  12 c3 08 00 00 00 07 07  |.4.............| I (117918) roaming_example: 0x3fca27ca   34 0d 60 a4 b7 b0 bb a6  c3 08 00 00 00 07 07     |4.............|
I (117938) roaming_example: RMM neigbor report bssid=60:a4:b7:b0:a7:12 info=0x8c3 op_class=0 chan=7 phy_type=7
I (117948) roaming_example: RMM neigbor report bssid=60:a4:b7:b0:bb:a6 info=0x8c3 op_class=0 chan=7 phy_type=7
I (117958) roaming_example: Found Candaidate list: 0
I (117958) roaming_example: Return Value : esp_wnm_send_bss_transition_mgmt_query: 0
I (118418) roaming_example: esp_bss_rssi_low_handler:bss rssi is=-56
I (118418) roaming_example: setting rssi threshold as -50
NIKHIL : WNM: RX action 7 from d8:07:b6:a8:c0:35I (118418) wifi:state: run -> init (cc0)
I (118428) wifi:pm stop, total sleep time: 99263491 us / 116203336 us
I (118428) wifi:idx:0, tid:5
I (118438) wifi:new:<7,0>, old:<7,0>, ap:<255,255>, sta:<7,0>, prof:1
E (118438) roaming_example: report is null
I (118448) roaming_example: station got disconnected reason=207
I (118458) roaming_example: station roaming, do nothing
I (118468) wifi:new:<7,0>, old:<7,0>, ap:<255,255>, sta:<7,0>, prof:1
I (119518) wifi:state: init -> auth (b0)
I (119518) wifi:state: auth -> assoc (0)
I (119558) wifi:state: assoc -> run (30)
W (119608) wifi:[ADDBA]rx delba, code:39, delete tid:0
W (119608) wifi:[ADDBA]rx delba, code:39, delete tid:0
I (119818) wifi:connected with TP-Link_C035, aid = 1, channel 7, BW20, bssid = 60:a4:b7:b0:a7:12
I (119818) wifi:security: WPA2-PSK, phy: bgn, rssi: -46
I (119818) wifi:pm start, type: 1
I (119828) wifi:set rx beacon pti, rx_bcn_pti: 0, bcn_timeout: 25000, mt_pti: 0, mt_time: 10000
I (119838) roaming_example: setting rssi threshold as -50
I (119838) roaming_example: RRM supported
I (119848) roaming_example: BTM supported
I (119878) wifi:idx:0 (ifx:0, 60:a4:b7:b0:a7:12), tid:0, ssn:2, winSize:64
I (119908) wifi:AP's beacon interval = 102400 us, DTIM period = 1
I (121338) esp_netif_handlers: sta ip: <IP_ADDRESS>, mask: <IP_ADDRESS>, gw: <IP_ADDRESS>
I (136798) roaming_example: esp_bss_rssi_low_handler:bss rssi is=-52
I (136798) roaming_example: setting rssi threshold as -50`
Here I can't see where  STA explicitly scanning for AP's.

@KlausPopp Thanks for the work around.
Currently I am evaluating the roaming_example in IDF. What i found out while debugging is that...the responce STA get from AP (ORBI )after sending BTM transition request contains information only about connected AP which causing it to not roam by saying Already associated with the preferred candidate.
I (1727) wifi:AP's beacon interval = 102400 us, DTIM period = 3
I (1737) roaming_example: setting rssi threshold as -50
I (1737) roaming_example: RRM supported
I (1747) roaming_example: BTM supported
I (3357) roaming_example: esp_bss_rssi_low_handler:bss rssi is=-59
W (3357) wpa: action frame sent
W (3357) wpa: RRM: Notifying neighbor report (token = 1)
I (3357) roaming_example: rrm: neighbor report len=47
I (3367) roaming_example: 0x3fc9a282   01 34 15 9a a6 7e 60 10  0e 87 d8 00 00 0
I (3377) roaming_example: 0x3fc9a292   06 03 01 05 00 03 01 00  34 15 9a a6 7e 5
I (3387) roaming_example: 0x3fc9a2a2   87 d8 00 00 00 03 0e 06  03 01 05 00 03 0
I (3397) roaming_example: RMM neigbor report bssid=9a:a6:7e:60:10:0e info=0xd887                                                                                han=3 phy_type=14
I (3407) roaming_example: RMM neigbor report bssid=9a:a6:7e:59:bc:5c info=0xd887
W (3477) wpa: WNM: Send BSS Transition Management Query to 9a:a6:7e:59:b9:c5
I (3487) wnm_send_bss_transition_mgmt_query: WNM: Send BSS Transition Management                                                                                a6:7e:59:b9:c5 query_reason=1
W (3497) wpa: action frame sent
W (3497) wpa: WNM: RX action 7 from 9a:a6:7e:59:b9:c5
W (3507) wpa: WNM: BSS Transition Management Request: dialog_token=1 request_mod                                                                                c_timer=0 validity_interval=100
I (3517) ieee802_11_rx_bss_trans_mgmt_req: neighbor_report_elements length 0
W (3527) wpa: WNM: Neighbor report tag 52
W (3527) wpa: WNM:neighbor report bssid:9a:a6:7e:59:b9:c5
W (3537) wpa: WNM: Subelement id=6 len=3
W (3537) wpa: WNM: Subelement id=3 len=1
W (3547) wpa: WNM: Candidate list valid for 10240 ms
W (3547) wpa: WNM: Try to use recent scan results
I (3557) compare_scan_neighbor_results: getting into scan compare neighbors
I (3567) compare_scan_neighbor_results: number of neighbours - 09a:a6:7e:59:b9:c
W (3567) wpa: WNM: Found an acceptable preferred transition candidate BSS 9a:a6:7e:59:b9:c                                                                                RSSI -59)
W (3577) wpa: WNM: Transition to BSS 9a:a6:7e:59:b9:c5 based on BSS Transition M                                                                                uest after_new_scan=1)
W (3597) wpa: WNM: Sending successful BSS Transition Management Response
W (3597) wpa: WNM: Send BSS Transition Management Response to 9a:a6:7e:59:b9:c5                                                                                1 status=0 reason=0 delay=0
W (3607) wpa: WNM: Add candidate list to BSS Transition Management Response frame
W (3617) wpa: action frame sent
W (3627) wpa: WNM: Already associated with the preferred candidate
W (3627) wpa: WNM: RX action 7 from 9a:a6:7e:59:b9:c5
W (3637) wpa: WNM: BSS Transition Management Request: dialog_token=1 request_mod                                                                                c_timer=0 validity_interval=100
I (3647) ieee802_11_rx_bss_trans_mgmt_req: neighbor_report_elements length 0
W (3657) wpa: WNM: Neighbor report tag 52
W (3657) wpa: WNM:neighbor report bssid:9a:a6:7e:59:b9:c5
W (3667) wpa: WNM: Subelement id=6 len=3
W (3667) wpa: WNM: Subelement id=3 len=1
W (3677) wpa: WNM: Candidate list valid for 10240 ms
W (3677) wpa: WNM: Try to use recent scan results
I (3687) compare_scan_neighbor_results: getting into scan compare neighbors
I (3697) compare_scan_neighbor_results: number of neighbours - 09a:a6:7e:59:b9:c
W (3707) wpa: WNM: Found an acceptable preferred transition candidate BSS 9a:a6:                                                                                RSSI -59)
W (3717) wpa: WNM: Transition to BSS 9a:a6:7e:59:b9:c5 based on BSS Transition M                                                                                uest after_new_scan=1)
W (3727) wpa: WNM: Sending successful BSS Transition Management Response
W (3727) wpa: WNM: Send BSS Transition Management Response to 9a:a6:7e:59:b9:c5                                                                                1 status=0 reason=0 delay=0
W (3747) wpa: WNM: Add candidate list to BSS Transition Management Response fram
W (3747) wpa: action frame sent
W (3757) wpa: WNM: Already associated with the preferred candidate
I (4067) roaming_example: esp_bss_rssi_low_handler:bss rssi is=-59
W (4067) wpa: action frame sent
W (4077) wpa: RRM: Notifying neighbor report (token = 2)
I (4077) roaming_example: rrm: neighbor report len=47
I (4077) roaming_example: 0x3fc9a2ae   02 34 15 9a a6 7e 60 10  0e 87 d8 00 00 0
I (4087) roaming_example: 0x3fc9a2be   06 03 01 05 00 03 01 00  34 15 9a a6 7e 5
When I tried with other set off MESH network (TP-Link) and tried to move from base station to satellite the STA roamed to the satellite after few BTM requests
I (116168) roaming_example: rrm: neighbor report len=31
I (116168) roaming_example: 0x3fca269e   0b 34 0d 60 a4 b7 b0 a7  12 c3 08 00 00 00 07 07  |.4.............| I (116178) roaming_example: 0x3fca26ae   34 0d 60 a4 b7 b0 bb a6  c3 08 00 00 00 07 07     |4.............|
I (116188) roaming_example: RMM neigbor report bssid=60:a4:b7:b0:a7:12 info=0x8c3 op_class=0 chan=7 phy_type=7
I (116208) roaming_example: RMM neigbor report bssid=60:a4:b7:b0:bb:a6 info=0x8c3 op_class=0 chan=7 phy_type=7
I (116218) roaming_example: Found Candaidate list: 0
I (116218) roaming_example: Return Value : esp_wnm_send_bss_transition_mgmt_query: 0
I (116678) roaming_example: esp_bss_rssi_low_handler:bss rssi is=-53
I (116678) roaming_example: setting rssi threshold as -50
E (117678) roaming_example: report is null
I (117908) roaming_example: esp_bss_rssi_low_handler:bss rssi is=-55
I (117908) roaming_example: setting rssi threshold as -50
I (117908) roaming_example: rrm: neighbor report len=31
I (117918) roaming_example: 0x3fca27ba   0d 34 0d 60 a4 b7 b0 a7  12 c3 08 00 00 00 07 07  |.4.............| I (117918) roaming_example: 0x3fca27ca   34 0d 60 a4 b7 b0 bb a6  c3 08 00 00 00 07 07     |4.............|
I (117938) roaming_example: RMM neigbor report bssid=60:a4:b7:b0:a7:12 info=0x8c3 op_class=0 chan=7 phy_type=7
I (117948) roaming_example: RMM neigbor report bssid=60:a4:b7:b0:bb:a6 info=0x8c3 op_class=0 chan=7 phy_type=7
I (117958) roaming_example: Found Candaidate list: 0
I (117958) roaming_example: Return Value : esp_wnm_send_bss_transition_mgmt_query: 0
I (118418) roaming_example: esp_bss_rssi_low_handler:bss rssi is=-56
I (118418) roaming_example: setting rssi threshold as -50
NIKHIL : WNM: RX action 7 from d8:07:b6:a8:c0:35I (118418) wifi:state: run -> init (cc0)
I (118428) wifi:pm stop, total sleep time: 99263491 us / 116203336 us
I (118428) wifi:idx:0, tid:5
I (118438) wifi:new:<7,0>, old:<7,0>, ap:<255,255>, sta:<7,0>, prof:1
E (118438) roaming_example: report is null
I (118448) roaming_example: station got disconnected reason=207
I (118458) roaming_example: station roaming, do nothing
I (118468) wifi:new:<7,0>, old:<7,0>, ap:<255,255>, sta:<7,0>, prof:1
I (119518) wifi:state: init -> auth (b0)
I (119518) wifi:state: auth -> assoc (0)
I (119558) wifi:state: assoc -> run (30)
W (119608) wifi:[ADDBA]rx delba, code:39, delete tid:0
W (119608) wifi:[ADDBA]rx delba, code:39, delete tid:0
I (119818) wifi:connected with TP-Link_C035, aid = 1, channel 7, BW20, bssid = 60:a4:b7:b0:a7:12
I (119818) wifi:security: WPA2-PSK, phy: bgn, rssi: -46
I (119818) wifi:pm start, type: 1
I (119828) wifi:set rx beacon pti, rx_bcn_pti: 0, bcn_timeout: 25000, mt_pti: 0, mt_time: 10000
I (119838) roaming_example: setting rssi threshold as -50
I (119838) roaming_example: RRM supported
I (119848) roaming_example: BTM supported
I (119878) wifi:idx:0 (ifx:0, 60:a4:b7:b0:a7:12), tid:0, ssn:2, winSize:64
I (119908) wifi:AP's beacon interval = 102400 us, DTIM period = 1
I (121338) esp_netif_handlers: sta ip: <IP_ADDRESS>, mask: <IP_ADDRESS>, gw: <IP_ADDRESS>
I (136798) roaming_example: esp_bss_rssi_low_handler:bss rssi is=-52
I (136798) roaming_example: setting rssi threshold as -50
Here I can't see where  STA explicitly scanning for AP's.

@Saicharan67 I would say that it might be better to post this log in the attachment and not as a huge wallpaper of badly formatted text :shrug:

I have a setup with google wifi and the roaming sample will not roam for me ever. it will only connect to the main nest router first. No matter how bad the RSSI. I have the threshold set to -50. I see it parsing one single rrm neighbor report. which contains the same bssid that I'm already connected to. Then nothing.
noroam.log
Using framework 5.1. Not sure if google problem or esp problem. I added the scan first to debug, but the same problem is present when not scanning like vanilla example.

Hi just summarizing before closing.

Most complaints here revolve around the AP not responding to BTM Queries , either by not responding at all or responding with  a candidate list that contains the current AP only. We believe that there is nothing ESP devices can do in this case and recommend checking the setup of the network.
Starting from v5.3 we have an experimental roaming application code that is designed to initiate a station initiated roaming using configurable methods and triggers. (You can try it out at examples/roaming/roaming_app)We will continue to improve and optimise this application and recommend that people facing issues with roaming here, check it out. Please note that this feature is still in experimental  stage.


Warning: findDOMNode is deprecated in StrictMode. findDOMNode was passed an instance of Transition which is inside StrictMode. Instead, add a ref directly to the element you want to reference.

Warning: findDOMNode is deprecated in StrictMode. findDOMNode was passed an instance of Transition which is inside StrictMode. Instead, add a ref directly to the element you want to reference.

Yeah, I think we have to update our react-transition-group dependency. I will do that later, or you can submit a PR if you feel like it.

It doesn't seem to solve the issue, but it think you should also give it a try.

I don't think that's solving the issue.

I think changes need to be done to the code to adapt to the new version of react-transition-group.

I submitted a PR please check it.

I have de same error

Still the same. Any hack?

It's just a warning in the dev env because of the react-transition-group. I've just fixed it by updating the dependency.
Try v7.0.2 and see if it's fixed for you. If it's not, I can reopen it.

Yes, it is fixed now.
Thanks for the quick reply :) Happy coding.

where I do the changed ?  I reinstall the pakage but not be fix the problem. Can I help me ?

@Patricio18 You should check the version in package.json, are you sure about that? Or you can do by uninstall and install again.


Android: stopped working on Android after the update

react-native-doc-viewer stopped working on Android after the update. I solved installing the older version (2.7.3), but I found it good to warn. Sorry for my bad english.
My package.json
"react": "16.0.0",
"react-native": "0.50.4",
"react-native-doc-viewer": "^2.7.3",

I fix it today.

Not a Bug.


Python 3 - pathod.pathoc

@mhils I'm a bit confused with what should be bytes (and what should be str) wrt pathod (like the rfile, wfile etc.)

Ready for review!

Merged! Thanks! 🎉


add missing labels for prez ontology

The URI labels added are required by v3 but not v4 so no need to merge to main; could you check in settings if we can set branch protection on v3-maintenance as well i.e. cannot merge w/o pull request?

ah, my apologies.

No worries I've added it now


Resume is required on application.  Send button won't activate.

Hi,
We have setup the default install and just changed a few required fields.
We have a huge issue in that no one can apply unless they upload a resume.  I have tried to figure out how to bypass this but can't figure it out.
We need people to be able to apply with just first, last name and email.
Any help would be appreciated.

Currently, you are not able to apply to the public-rest API without some form of resume.  This is to ensure the record is successfully parsed into the system.  You can do one of two things to meet the requirements for a "abbreviated apply".
First, you can utilize the full Bullhorn Rest API to create a candidate record with the information entered in.  You can find documentation on this api here.
The second option is to submit applications in a way similar to the way the Apply with LinkedIn applications work,  We submit a txt format resume containing all of the relevant details from the applicant's LinkedIn account.  If the elect to not use the resume, you can possibly have a radio button to control whether or not to upload a resume and then behind the scenes, send a txt "resume" that contains text that says "no resume" or something similar.
You are able to also change the validation for the send button by modifying the enableSendButton method found here.  This will need to be done after executing one of the previously mentioned options.
Please let me know if you have any questions.

Charles, I am having this same issue. Could you please provide a working ink for the enableSendButton method?