Package.json for eslint-config-react-app on NPM is incorrect

Describe the bug
The package.json file for eslint-config-react-app differs between NPM and Git for one peer dependency:

Git: "eslint-plugin-react-hooks": "1.x || 2.x || 3.x || 4.x"
Npm: "eslint-plugin-react-hooks": "1.x || 2.x"

Both has "version": "5.2.1", and everything else matches, except for this one peer dependency. 😕
Steps to reproduce

Inspect package.json on git:
✔ "version": "5.2.1"
✔ "eslint-plugin-react-hooks": "1.x || 2.x || 3.x || 4.x"
Run npm pack eslint-config-react-app
Inspect the package.json within the downloaded tgz package:
✔ "version": "5.2.1"
❌ "eslint-plugin-react-hooks": "1.x || 2.x"

Expected behavior
Would expect the acceptable versions of "eslint-plugin-react-hooks" to be the same in both places.
Actual behavior
Acceptable versions do not match. Means npm gives me a warning when I try to upgrade eslint-plugin-react-hooks to its latest version, 4.x:
> npm install eslint-plugin-react-hooks@4
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>|| 2.x but none is installed. You must install peer dependencies yourself.

+<EMAIL_ADDRESS>updated 1 package and audited 712 packages in 3.669s

Just noticed the package.json downloaded from Npm includes "gitHead": "d2f813f8897ffcd2f0b0d2da75d0c44924c92f4d", and checking the package.json for that, it is indeed different than master, yet both says they are "version": "5.2.1".
Confusing and annoying.
🤷♂😕

As far as I know, it's still an issue, stale bot.

I just came with the same issue while trying to create a React App with create-react-app:
➜ npx create-react-app <project-name>

Creating a new React app in .../projects/<project-name>.

Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts with cra-template...

npm ERR! code ETARGET
npm ERR! notarget No matching version found for<EMAIL_ADDRESS>npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.
npm ERR! notarget
npm ERR! notarget It was specified as a dependency of 'react-scripts'
npm ERR! notarget

npm ERR!

Deleting generated file... package.json
Deleting <project-name>/ from .../projects/
Done.

Steps to reproduce:
npx create-react-app <project-name>

Still an issue. And seems to be "worse" too. The whole peerDependencies section seems to be incorrect.
From GitHub repo:
{
  "peerDependencies": {
    "@typescript-eslint/eslint-plugin": "^3.0.0",
    "@typescript-eslint/parser": "^3.0.0",
    "babel-eslint": "^10.0.0",
    "eslint": "^7.0.0",
    "eslint-plugin-flowtype": "^5.0.0",
    "eslint-plugin-import": "^2.21.1",
    "eslint-plugin-jsx-a11y": "^6.3.0",
    "eslint-plugin-react": "^7.20.0",
    "eslint-plugin-react-hooks": "^4.0.1"
  },
}

From NPM via npm pack eslint-config-react-app:
{
  "peerDependencies": {
    "@typescript-eslint/eslint-plugin": "2.x",
    "@typescript-eslint/parser": "2.x",
    "babel-eslint": "10.x",
    "eslint": "6.x",
    "eslint-plugin-flowtype": "3.x || 4.x",
    "eslint-plugin-import": "2.x",
    "eslint-plugin-jsx-a11y": "6.x",
    "eslint-plugin-react": "7.x",
    "eslint-plugin-react-hooks": "1.x || 2.x"
  },
}

I  really hope we'll see a new npm publish in a reasonable time.

Dear mr. Stale
This projects has not had any new releases since march, so this issue has not been fixed. Please do not close until it has been.
Humbly,
Me

Thank you, most gracious mr. Stale.

I'm having the same issue right now trying to self-host a bot... not sure what's causing it.

Still a problem.

Still a problem.

This is why my plugins are not getting loaded in my eslintrc. Still not stale.

This is still an issue for me too.

This is still an issue:
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>|| 2.x but none is installed. You must install peer dependencies yourself.

This should be resolved in the latest version.


Unit tests

Refactored Tests and DataImportService
Removed GetPatient from DataImportService. Replaced with a new patient creation in the
dependent methods. Placed thrown exception for null or blank externalID in getPatienSnapshots
and createPatient. Created Tests for TreatmentProtocol, DataImortService, and a timed test
for creating and finding DataProjection Nodes.

style: avoid wildcard imports

Looking into it, I don't think you can avoid it here?

Yes, it can be done:
Import static org.mockito.Mockito.when;


Support for stream in detectText

I would love to be able to stream a fileupload from a user straight to the google vision API for textAnnotations, to make the OCR run faster.
Unfortunately the API currently only supports images as buffers, filenames or URLs, not streams.
Us node.js entusiasts love streams, this would make us able to stream a users fileupload both to our file storage, and at the same time to OCR. Making us able to do the OCR much faster, seen from the users perspective.
I would call the REST API myself using request but I find myself lost in the code for authentication. Is there a guide anywhere for calling the REST API in a simple way without using the SDK?

I would call the REST API myself using request but I find myself lost in the code for authentication. Is there a guide anywhere for calling the REST API in a simple way without using the SDK?

The easiest way is probably using google-auto-auth. See the example from the readme, then just plug-in request.

this would make us able to stream a users fileupload both to our file storage, and at the same time to OCR.

Does this mean you would split a single source stream in multiple directions? This can have some side effects-- once a destination stream handles its chunk from the source stream, the source releases it. So, destination streams would have to keep up with each other in order to handle the same data . But, I haven't followed closely any development in this regard-- is there a native/popular solution for this?
We could accept an incoming stream, but I don't believe the response would come any quicker. We send requests through a generated layer, which uses gRPC beneath it. They don't expect any streaming input for this method, so if we received a stream from the user, we would have to buffer the contents into memory before making the request, and then simulate a stream after we got a response by manually emitting data with the sole response object from the API.
This has been how we distinguish between when we offer streams / don't in our API. We want to stay true to how streams work and their benefits, and avoid simulating them.

I have the split stream running in production now. It just buffers in memory if there is backpressure.
The microservice handling calling google vision just collects it in a buffer for now and calls google vision with the buffer.
What I would potentially do is stream write the beginning of the JSON to the REST api and then stream the file upload directly as base64 into the JSON and then write the close of the JSON. That would mean that the OCR would start almost simultaneously with the fileupload finishing.

Den 27. mar. 2017 kl. 16.04 skrev Stephen Sawchuk<EMAIL_ADDRESS>I would call the REST API myself using request but I find myself lost in the code for authentication. Is there a guide anywhere for calling the REST API in a simple way without using the SDK?
The easiest way is probably using google-auto-auth. See the example from the readme, then just plug-in request.
this would make us able to stream a users fileupload both to our file storage, and at the same time to OCR.
Does this mean you would split a single source stream in multiple directions? This can have some side effects-- once a destination stream handles its chunk from the source stream, the source releases it. So, destination streams would have to keep up with each other in order to handle the same data . But, I haven't followed closely any development in this regard-- is there a native/popular solution for this?
We could accept an incoming stream, but I don't believe the response would come any quicker. We send requests through a generated layer, which uses gRPC beneath it. They don't expect any streaming input for this method, so if we received a stream from the user, we would have to buffer the contents into memory before making the request, and then simulate a stream after we got a response by manually emitting data with the sole response object from the API.
This has been how we distinguish between when we offer streams / don't in our API. We want to stay true to how streams work and their benefits, and avoid simulating them.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

We used to do that in various places in this library as well, but it's a little different now with gRPC. I don't believe we have an equivalent way of sending a stream where the generated/gRPC API doesn't expect one.
@jmuk @landrito can you think of a way to get a stream through in the generated layer for the batchAnnotateImages() method? And would it offer any perf benefits (not sure how the gRPC end of this works)?
The goal is; the API request starts once it receives the first chunk of data from a source stream, so that by the time the source stream is drained, the response is practically back. Compare this to currently, where the API request starts after the buffer is drained.

The caution I would put on that (we sort of eluded to this already) is that we need to deliver what it says on the tin. Pretending that we are streaming a request when, in fact, it is uni-directional and the response does not start until the entire request completes, is pointless.

I don't think the goal you stated can be accomplished without a streaming rpc being added to the proto. Maybe @jmuk has an idea?

@lukesneeringer Even if you buffer and then do OCR on your side, a streaming option would still be nice. Then we can stream a file from the file system, a web request etc. And not have to buffer the entire thing in memory on our side. In our experience these kind of streaming solutions scale exceptionally well under heavy load.

I don't think we'd go so far as to fake the stream. The problem with doing it on our side is that it would create an illusion that we're doing something to help the user's app's performance. It might encourage them to do things they otherwise wouldn't, not realizing it was all a facade until they notice their memory usage going up inexplicably. Eventually, they'd realize what was going on, and at that point, they'd probably make us feel pretty bad for doing that to them.
I would recommend buffering on the app's side, even if it is an extra step. concat-stream can make it pretty easy:
function requestHandler(req, res) {
  req.pipe(concat(function(userImageUpload) {
    vision.detectText(userImageUpload, function(err, detections) {})
  }))
}

I'll close the issue for now, since I think we're trapped by the proto files not allowing a streaming version of this method. If @jmuk has any ideas and thinks there is hope here, please re-open.

Oh I didn't mean buffering in the SDK. I meant buffering on the google servers.


Customizer Not Opening.

Customizer Not Opening.  However when I use default WP theme then the customizer works absolutely fine.

Can you open the developer tools on chrome and paste a screenshot of console tab if you see any errors there?

#2026

Closing due to inactivity


Delete self-review.md

Why:
Closes [issue link]

What's being changed (if available, include any code snippets, screenshots, or gifs):

Check off the following:

[ ] I have reviewed my changes in staging (look for the "Automatically generated comment" and click the links in the "Preview" column to view your latest changes).
[ ] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[ ] This pull request impacts the contribution experience

[ ] I have added the 'writer impact' label
[ ] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

This PR appears to have been opened accidentally. I'm going to close it now, but feel free to open a new issue or PR or ask any questions in discussions! 💛
Please take a look at our help wanted section to find open issues you can work on.
Thank you for your interest in improving our docs! ✨


fixFix fe pom cdh download failed issue

Proposed changes
compose FE source download net.sourceforge.czt.dev's cdh jar failed，change repository url.

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


iOS: problem using setLeftWindow after open()

I've been using version 1.1.1 (after migrating from your Slidemenu) I discovered I needed to close/open the mainwin:

mainwin = NappDrawerModule.createDrawer({
    centerWindow : apptabgroup,
    leftWindow : mainmenu.win,
    leftLedge : 100
});

....
//  inside an eventhandler:
mainwin.close();
mainwin.setLeftWindow(itemmenu);
mainwin.open();

To make it work. This causes a black flicker.
After upgrading to 1.1.4. this fix doesn't work anymore, the main win disappears, leaving a black screen.
Am I making a mistake with setLeftWindow?

Same here.
Seems setting the left or right window after open causes the sliders to stop working.
Any updates on this?

I'm having the same issues when I open the right window and THEN the left window. Very odd.


Implement major incident start date field

This field is set to the major incident BZ flag (hightouch and hightouch-lite) creation time, or automatically set when the flaw is set to be an approved major incident in OSIDB.
Closes OSIDB-2728.

@osoukup I think I have to take a different approach to the SLA containing a null major_incident_start_dt. When we check for policies that apply, the SLA is loaded and if it finds a major_incident_start_dt=None it will fail, but maybe it doesn't apply because it did not meet the conditions to begin with (the instance is not a major incident so it shouldn't even load that policy).
So the problem comes from the error being raised too soon, before checking if conditions apply. I think I should add this validation somewhere else, maybe after the SLA is completely loaded, add a method that checks for inconsistencies and enforces some rules: if it uses major_incident_start_dt, then it must enforce it being a major incident, if it uses unembargo_dt then it must enforce that it is not embargoed, etc.

@dmonzonis oh I see! Then it means that I was insisting on something unreasonable... Sorry for that. Then probably your original solution (which was if I remember correctly just skipping the None values) is an acceptable way to go. If the policy is written carefully it should not be an issue anyway and if it eventually is we will deal with it later.

@dmonzonis You have to recreate migrations as they will alter the FlawAudit model as well.


Support iron-list

Hi,
after completing the Firebase+Polymer codelab, I wanted to replace the dom-repeat property with the <iron-list/> element so I can get optimal performance even on really long lists. It unfortunately didn't work as the data supplied by the <firebase-query/> element misses the index key in the model (see the iron-list doc). It also misses the selected key I can we'd want to use it for batch actions such as archive, or delete.
Is Polymerfire going to be pluggable to iron-list, and is there any workaround in the meantime?

It should be compatible without modification -- firebase-query binds to just a normal Polymer array...

So why was the dom empty inside the iron-list, while it was populated with dom-repeat? Could you show me a snippet for a working iron-list version of the Firebase Polymer codelab please?

I was having related issue on another app. I was using <firebase-query> with <iron-list>, and notice whenever data is deleted in firebase, <iron-list> does not remove the item correctly (on display). Adding data into firebase seems to work fine with <iron-list> though.

Just an update on my case, after inspecting the element on the deleted list, I noticed the final item inside the list did have an hidden attribute.
Setting the following CSS style inside the custom element did resolve my issue.
<style>
  .class[hidden] {
    display: none;
  }
</style>

@andrewspy Can you share a snippet/gist on how you made <iron-list/> work with <firebase-query/> please? I couldn't get it to display any single item while it showed data when using dom-repeat.

I found a workaround: fetch your results in a separate component and use Polymers linking functionality with a "temporary" property to make iron-list work.
<firebase-query data="{{_results}}" ...></firebase-query>

// Further down

Polymer({
    properties: {
        _results: {
            type: Array,
            notify: true
        },
        results: {
            type: Array,
            notify: true
        },

        ready: function () {
            this.set('tracks', this._results);
            this.linkPaths('tracks', '_results');
        }
    }
});

Then later use the component in your view and bind iron-list to the results-property. Works for us.

On 2.0-preview, I'm getting this error:
    at HTMLElement.<anonymous> (iron-list.html:1219)
    at HTMLElement._iterateItems (iron-list.html:1184)
    at HTMLElement._assignModels (iron-list.html:1214)
    at HTMLElement._update (iron-list.html:931)
    at HTMLElement._increasePoolIfNeeded (iron-list.html:995)
    at HTMLElement._render (iron-list.html:1035)
    at _timer._asyncModule.run (debounce.html:40)```

I didn't do anything fancy, just a simple firebase-query bound to a property like it shows in polymerfire docs. Then, I bound the iron-list to the same property and got the error above.

It simply does not work at mine.. Why we cannot use it just simple as it used  with dom-repeat?
    <firebase-query log
      path="/posts"
      data="{{posts}}" >
    </firebase-query>

        <iron-list id="list" items="[[posts]]" as="item">
          <template>
              <div> [[item.name]]</div>
          </template>
        </iron-list>

I do not want to stamp<PHONE_NUMBER>34 trillion items in my dom-repeat.. even the chunking mode of dom-repeat is not good for performance.
I really want to use Firebase because its awesome.
Why does firebase-query not respond in the exact same format as a iron-ajax pointent to a .json file?

I am NOT using firebase-query (just a simple iron-ajax), and it is not working either.
I am getting a TypeError: Cannot set property '__key__' of null in _assignModels: function(itemSet) on line 1227...


stdio mode

Please consider adding a --stdio input/output mode for this language server, so it can be used with other editors! :)

absolutely.   I can take a look into that.

This would also make it easier to run cfn-lint through Docker (no mounting required) and apparently allow linting without saving.


--watch failing despite being in hg repo

Do you want to request a feature or report a bug?
Bug
What is the current behavior?
Using jest v21.3.0-beta.8, node v8.5.0. When running jest --watch Foo it says:
--watch is not supported without git/hg, please use --watchAll

But running --watchAll work. This is within a Mercurial (hg) repository, so the error message doesn't make much sense to start with.
What is the expected behavior?
--watch should work.

I'm wondering if that was fixed in #4865. Can you try the latest beta?

Beta 8 does not contain #4865, so closing this. Please reopen if it's still an issue on the latest beta.
$ npm show jest time
...
  '21.3.0-beta.8': '2017-11-07T17:45:00.276Z',
  '21.3.0-beta.9': '2017-11-22T13:18:21.947Z',
  '21.3.0-beta.10': '2017-11-25T12:40:09.119Z'


Update CONTRIBUTORS.yaml: lskatz orcid

we aren't exposing this information anywhere nice currently (other than to add a green badge) but hopefully in the future.


impute missing values as one of the steps for gridsearchcv to tune

this is not an issue for the problem i'm working on right now, so deprioritizing until i run into a problem where this would be useful. should be an easy thing for someone else to add in if they want!

nope. Most tree-based algorithms actually use None or float('nan') as a signal.  imputing missing values generally means losing that signal. Adds additional complexity that is not the highest impact right now.


2uri_file_pgie_iou_tracker_3sgie_tiler_osd_custom_pph_window.py fails to fully transition to play.

This regression was caused by changes to the default common sink properties. Previously, DSL was explicitly setting the async property for all sinks to false. This was changed in the v0.27.alpha release. The default value was left unchanged.
All plugins default to async = true.
The NVIDIA implementation for Secondary Inference components requires the property to be set to false
The workaround for this issue is to call the base sink services to set the property to false
        retval = dsl_sink_async_enabled_set('window-sink', False)

Merged into the v0.27.a.alpha patch release


make fmt doesn't reformat everything

Uncovered in #103:

make fmt doesn't always reformat the entire codebase
make checkfmt doesn't always catch malformatted files

At least one problem is that our makefile definitions exclude test files:
SOURCES := $(shell find . -name '*.go' -not -name '*_test.go') go.mod go.sum
SOURCES_NO_VENDOR := $(shell find . -path ./vendor -prune -o -name "*.go" -not -name '*_test.go' -print)

And fmt depends on them:
fmt: $(SOURCES_NO_VENDOR)


unify test style

closes #62
This pull request is about adding the functionality of chai-as-promised into all tests.
And somtimes choosing nicer names.
And to just have a secong look on it ;)

Current coverage is 87.30% (diff: 100%)

Merging #64 into master will increase coverage by 1.59%

@@             master        #64   diff @@
==========================================
  Files            34         31     -3
  Lines           476        386    -90
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits            408        337    -71
+ Misses           68         49    -19
  Partials          0          0

Powered by Codecov. Last update e4f6927...3d8e4e2


Added spec 1.3.0 for new spec functionality

Coverage increased (+1.2%) to 78.454% when pulling 68cba6901b4e22546373a8dad47d82229ff8d629 on feature-spec-130 into 72355ea7a3049385c256f1e62ca3c089b05c29a7 on master.


Document which methods panic.

In a format suggested by:
https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md

Thanks, very useful!


wxAuiNotebook has delete all pages, check usage

not possible, we have to check for each page if it is modified


Allow using plugin file names and environment variables compatible with Garden and later

🎉 New feature
Summary
Allows using gz-* in plugin filenames (eg.  <plugin filename="gz-sim-physics-system" name="gz::sim::systems::Physics"/>) and using GZ_* environment variables in Fortress. This is meant to help users (especially ROS users) maintain SDF files and launch files that work in both Fortress and Garden/Harmonic.
Test it
I've added tests that exercise:

Using gz-sim-* filenames in <plugin> tags (src/SystemLoader_TEST.cc)
Using GZ_SIM_SYSTEM_PLUGIN_PATH (src/SystemLoader_TEST.cc)
Using GZ_SIM_RESOURCE_PATH (src/Server.cc)
Using GZ_SIM_SERVER_CONFIG_PATH (src/ServerConfig_TEST.cc)

I have not added a test for GZ_SIM_RENDER_ENGINE_PATH since I couldn't find a test for IGN_GAZEBO_RENDER_ENGINE_PATH and I don't think it's a commonly used environment variable.
Checklist

[x] Signed all commits for DCO
[x] Added tests
[ ] Added example and/or tutorial
[ ] Updated documentation (as needed)
[ ] Updated migration guide (as needed)
[ ] Consider updating Python bindings (if the library has them)
[ ] codecheck passed (See contributing)
[ ] All tests passed (See test coverage)
[ ] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

I found that GZ_SIM_RESOURCE_PATH wasn't working even though the tests I added were passing. I've made some fixes and added tests in https://github.com/gazebosim/gz-sim/pull/2275/commits/68a129a2ddd891d6bab0be1a34eba8fdf8e668b1. @iche033 PTAL

the UNIT_Server_TEST failure in gz_sim_ci-pr_any-focal-amd64 build could be unrelated. The tests pass locally

CI is good. Windows warnings are preexisting, so I'll go ahead and merge.


Adding JOSS article to readme

@erikvansebille, #64 will be handled by this PR, just have to sort out the failing tests in the meantime

Actually, that's not quite right, I need to add it to the readthedocs too!

I did not check the index.rst file... The URL doesn't render correctly. Going to fix now


Documentation - Starter Template - No x-basic option in hono-create command

What version of HonoX are you using?
latest
What steps can reproduce the bug?
https://github.com/honojs/honox?tab=readme-ov-file#starter-template
What is the expected behavior?
hono-create command should have a x-basic option?
What do you see instead?
No response
Additional information
No response

Hi @laurentlahmy
create-hono has a x-basic option:

Can you try it again?

ah right I didn't see the arrow keys option, maybe it's a bit unexpected?


  As posted on Telegram, we are working to make sure this works flawlessly.
We want to have temporary and experimental instructions, to facilitate you guys trying to break the release, so we can fix anything and improve stability for a release candidate.
The instructions below ARE EXPERIMENTAL. If you have spare time, please try them and report any issue.  This message will be updated with changing instructions all the time.  It's going to be messy.  You've been warned.
Overview
To better understand syncing process, one must understand how data is flowing inside the dfuse for EOSIO process.
First mindreader app starts and controls a nodeos process, one that has dfuse instrumentation built-in. It connects to nodeos stdout pipe and start to process output generated by dfuse Deep Mind code which live inside nodeos process.
This output is processed by mindreader which from that, generates "dfuse blocks" file. Once those blocks are generated, they are pushed through some communication channel to other app inside the stack:

fluxdb
trxdb-loader
search-indexer

The former first two (fluxdb & trxdb-loader) uses Badger, a local disk-based key-value database while the second creates on-disk searchable indexes that are used by the other search apps to serve search query & streams.
This means after "dfuse blocks" are created by mindreader app, the bottleneck that is probably hit is disk throughput. We never used that setup yet to sync any "existing" chain, we are thus even unsure how everything is going to behave together and even if this setup is able to reprocess a mid-size chain in a reasonable matter. In our testing on "local test chains", we are able to roughly index ~30 blocks/s, and that was only for the trxdb-loader as far as I remember. This is a metric that is probably valid for fluxdb and trxdb-loader, the search-indexer probably goes much faster as it indexes chunk of 200 blocks.
Assuming all indexing apps runs at the same time, keep up a rate of 30 blocks/s, syncing a 3M blocks chain should take roughly 27 hours. This is also discarding the fact that blocks continue to be created while this happens, in 27 hours, there will be 194400 blocks created, that's another 2 hours of reprocessing approximately and so on.
The bottleneck of reprocessing will be definitely Badger here. There is two distributed replacement that exists currently in dfuse for EOSIO:

Google Cloud BigTable
TiKV Database

There is also the possibilities to perform "batch" reprocessing, you start multiple "indexing" instances, each indexing a certain chunk of the chain, like 0 - 2M, 2M - 4M, etc. (any batch size is possible here, highly dependent on the actual chain). While all this exists, it most probably do not work with a local "Badger" instance since only one process can write on it at the same time. To work, someone would need to write a small "app" that would be the single controlling process of the Badge folder, and a new KV store abstraction would need to be written to talk to this "app".
Why saying all? So that you know there is other possibilities to sync the chain, if you are ready to try stuff. Except Google Cloud BigTable, anything else has not been battle tested yet (we are starting to play with TiKV on some deployment though).
The rest of the document will be given per specific configuration.
dfuse for EOSIO - Out of the box experience
Notes You are invited to try those instructions on low to mid size traffic chain. It's guaranteed to not work for example on EOS Mainnet or chain that exists since a long time, event if they are low-traffic.
Some users are currently trying this approach as we speak, and we will probably do it ourself to collect further metrics.
For this sync, we are going to split the process in 3 different phases:

Phase 1 - Launch a mindreader app only that syncs with the existing chain and create "dfuse blocks" file
Phase 2 - Add to the mix the indexing apps: fluxdb, trxdb-loader and search-indexer
Phase 3 - Starts everything else

We are going to run that in the same folder for each phase. Between each phase, we are going to start with a different config file.
In Phase 1, we only create "dfuse blocks" file. This is mostly CPU + Network bound as you are replaying the existing chain from scratch and create "dfuse blocks". This runs until the chain is "live", i.e. that you are processing live blocks.
In Phase 2, the mindreader app is going to continue its processing of live blocks, but we add to the mix the indexing apps. Those apps will not try to read live blocks. Instead, they will read "dfuse blocks" from the filesystem and index them on they various database/storage locations. We run that until everything is live and process live blocks from mindreader.
In Phase 3, we start everything else. Indexing apps will catch up where we terminated Phase 2, and live indexers will start to fill up with live data. All other apps are going to start also, so you will be able to query the APIs and should have a full indexed dfuse stack.
Bootstrap
mkdir ~/work/chain
cd ~/work/chain
dfuseeos init
# Answers `N` to `Do you want dfuse to run a procuder node for you?`
# Enter peer addresses (try to have a few good peers in there)

Once this is done, copy the genesis.json file inside ./mindreader folder. When finish, you should have the following structure:
$ tree

Phase 1
Create a file dfuse-phase1.yaml in your folder with the following content:
start:
  args:
  - mindreader
  flags:
    mindreader-log-to-zap: false
    mindreader-merge-and-store-directly: true
    mindreader-start-failure-handler: true
    mindreader-blocks-chan-capacity: 100000
    mindreader-restore-snapshot-name: latest

    # We suggest to set a stop block manually, because this config cannot deal with fork blocks
    # and with a stop block, "mindreader" will close automatically alone when it finish up sync up
    # to this point.
    #mindreader-stop-block-num: 3000000

Then start up the phase 1 processing with:
dfuseeos -c dfuse-phase1.yaml start

That will kick off creation of "dfuse blocks" and should sync with the chain relatively quickly depending on the size of the chain and the amount of transactions contained in the blocks.
Let it run until you see that nodeos process live blocks (or stops by itself, see Problems/Notes sections item list 3). We suggest also setting a
When you are live (see notes list item 3) , you can continue with Phase 2.
Performance Reports
Note Take all this lightly, it's more to give rough ideas. There is also some performance bottleneck that could probably be improved over time at various location to improve those numbers (#29 for example is one).

Proton chain sync from 0 - 3.3M on 4 vCPUs e5620 2.4ghz xeon, 8gb ram,  connected to LAN wired network took roughly 7 hours
Proton chain sync from 0 - 3M on 8 vCPUs, 2.6 GHz Intel Core i7, 16gb ram,  connected to WiFi (and not with great signal with the router) took roughly 13 hours.

Potential Problems/Notes

Due to usage of merge-and-store-directly, when mindreader quits, it must always start back at least 100 blocks back in time! This is the reason why mindreader-restore-snapshot-name: latest is used. However, this is problematic if there is no snapshot taken yet, mindreader restarts where it left off and there is will be a bundle missing. We need to improve something for this case.
When you will enter Ctrl-C to terminate phase 1, it's gonna take a while before it actually exits. Do not hit Ctrl-C again if the process has still activity, you can do tail -f dfuse-data/dfuse.log.json to monitor for progress, you should see log lines like: {"level":"info","ts":1589529926.052727,"logger":"mindreader","caller":"mindreader/mindreader.go:235","msg":"will shutdown when block count == 0","block_count":99970}.
There is a problem when we reach "live" blocks since the mindreader-merge-and-store-directly cannot deals with forks. This is a minor problem because the process will actually kills itself automatically in the presence of the first fork. This means in this phase, it's impossible to keep a "mindreader" running on live blocks (most probably, unless there is 0 fork which is possible, but more rare on "normal" circumstances). There is the possibility to set a stop block mindreader-stop-block-num: XXX in the config, that will tell mindreader to stop once it reaches this block.

Phase 2
At this point, you should have phase 1 stopped if you added a stop block parameter, or it might have quit when encountering a fork. If you are lucky and it's still running, you should take a snapshot before exiting.
curl -X POST http://localhost:13009/v1/snapshot

Then monitor the folder dfuse-data/storage/snapshots until the snapshot is written there. Then when the snapshot is there, hit Ctrl-C to quit phase 1.
In Phase 2 we are going to still mindreader, but we are going to change it's configuration so it's able to deal with live blocks. For that, we will defer the block merging process to another app, the merger. The relayer app will also be started, so once indexing apps have finished indexing "historical" blocks, they will be able to be kept "warm" and process live blocks (assuming mindreader as correctly sync up to live blocks)
We will also start the fluxdb indexer (history state information), trxdb-loader (transation and blocks database) and search-indexer (search engine indexes).
Create a file dfuse-phase2.yaml in your folder with the following content:
start:
  args:
  - mindreader
  - merger
  - relayer
  - fluxdb
  - trxdb-loader
  - search-indexer
  flags:
    fluxdb-enable-server-mode: false
    mindreader-start-failure-handler: true
    mindreader-blocks-chan-capacity: 100000
    mindreader-restore-snapshot-name: latest
    relayer-max-drift: 0
    trxdb-loader-batch-size: 100

Then start up the phase 2 processing with:
dfuseeos -c dfuse-phase2.yaml start

Monitoring advancement of the indexing processed is done manually right now, extracting logs from dfuse-data/dfuse.log.json file to see what's going on at which rate.
We uses zap-pretty tool (https://github.com/maoueh/zap-pretty) to prettify the log line. Can be replaced by jq . also but it's less pretty and creates longer line. If you use jq . or nothing at all, you can avoid the --line-buffered in the grep statements, that is used to overcome a limitation of zap-pretty (that we will fix eventually).
# App fluxdb progress (check for `block_num` field, no insert rate given here)
tail -f dfuse-data/dfuse.log.json| grep --line-buffered "fluxdb" | grep --line-buffered "wrote irreversible segment" | zap-pretty

# App trxdb-loader (check for `block_num` and `block_sec` (insertion rate))
tail -f dfuse-data/dfuse.log.json| grep --line-buffered "trxdb" | grep --line-buffered "5sec AVG INSERT RATE" | zap-pretty

# App search-indexer  (check for `block`, `blocks_per_sec` and `docs_per_sec` (insertion rate))
tail -f dfuse-data/dfuse.log.json| grep --line-buffered "indexer" | grep --line-buffered "processing irreversible block" | zap-pretty

# Mindeader (to see at which block it is syncing)
tail -f dfuse-data/dfuse.log.json|  grep --line-buffered mindreader | zap-pretty

Performance Reports
Note Take all this lightly, it's more to give rough ideas.

Proton chain sync from 0 - 3.3M on 4 vCPUs e5620 2.4ghz xeon, 8gb ram,  RAID6 SAN (exact number unavailable, reported 2 hours but I image it's much less than that). No break down per app.
Proton chain sync from 0 - 3M on 8 vCPUs, 2.6 GHz Intel Core i7, 16gb ram,  SSD disk

App search-indexer took roughly 35m to index all the data
App trxdb-loader took roughly 55m to index all the data
App fluxdb took roughly 60m to index all the data

Potential Problems/Notes

If there is a hole in the merged-blocks, it's not reported as an error/warning and it looks like nothing is working anymore as the indexing apps are waiting for a 100 blocks file that does not exists (and will never will). Doing a tail dfuse-data/dfuse.log.json shows up that the bstream filesource is waiting for a bundle that does not exist. We should probably think about some way to improve that, after a while the file is not found, could we perform a list files to look if there is any "future" files and as such, detect the hole here?

If there is a hole in the merged-blocks, it's not reported as an error/warning and it looks like nothing is working anymore as the indexing apps are waiting for a 100 blocks file that does not exists (and will never will). Doing a tail dfuse-data/dfuse.log.json shows up that the bstream filesource is waiting for a bundle that does not exist. We should probably think about some way to improve that, after a while the file is not found, could we perform a list files to look if there is any "future" files and as such, detect the hole here?

A good improvement would be to auto detect holes (based on "future" files) in the merged-blocks directory either after encountering a filesource error in phase2 (after few retries) and/or at start of phase2
Once the missing merged-block ranges are identified, dfuseeos can stop and re-launch phase1 with the appropriate merger-start-block-num and merger-stop-block-num flags to create the missing merged-blocks (Might need sequential/parallel runs if more than one missing range)
Phase 2 should kick off again after missing merged-block ranges are created.

The phase producing merged-blocks could simply try to be more resilient, and have retries (but that could be hairy, starting say 100,000 blocks before because of a failed merge, in a loop, if there's an issue).
I think consumers (FileSources) shouldn't bother with warning, because they are powerless in fixing the issue.. and those warnings would be all over the place.
Currently, dfuseeos is not aware of phases, they are operator concepts.
The thing is, in theory, there should be no holes in merged blocks once a pass went over. Otherwise, there's either: a bug that needs to be fixed (in mindreader with --...-store-directly, or the merger), or an operational error, like forgetting to run a certain block range.

@abourget @shaqk when the phase 1 is running with "mindreader-merge-and-store-directly=true", we usually are doing this in parallel with a bunch of vms, and we discard those afterwards.
But for a user who does this on a smaller scale, stoping mindreader after that phase will create a hole between the last "directly-merged-file" (ex: 99,900->99,999) and the next few blocks that passed during phase 1 (block 100,000 and following are never written anywhere with 'merge-and-store-directly'.
I'm working on a "cleanup()" call on the Archiver interface, where a reproc-archiver could dump its buffer to the DefaultArchiver, creating one-block-files for those few blocks close to head. This way, restarting mindreader in a "normal mode" afterwards would not create a hole, as the merger could take over at that point.

See https://docs.dfuse.io/eosio/admin-guide/large-chains-preparation/ now


ubuntu: Fix failure to scp diagnostic data file from SSVM

Description
On trying to get the diagnostic data from SSVM, we face the following issue:
Copying /root/diagnostics_files_20210827-051515.zip from <IP_ADDRESS> to secondary store NFS://<IP_ADDRESS>/acs/secondary/ref-trl-1680-v-Mu20-pearl-dsilva/ref-trl-1680-v-Mu20-pearl-dsilva-sec1
2021-08-27 05:15:15,280 ERROR [o.a.c.d.DiagnosticsServiceImpl] (API-Job-Executor-27:ctx-ec0ca00b job-33 ctx-43bee1c6) (logid:8d3dba6c) Exception caught during scp from <IP_ADDRESS> to secondary store /var/lib/cloudstack/mnt/32987160773173.3029c5e3/diagnostics:
java.io.FileNotFoundException: /var/cloudstack/management/.ssh/id_rsa (No such file or directory)
	at java.base/java.io.FileInputStream.open0(Native Method)
	at java.base/java.io.FileInputStream.open(FileInputStream.java:219)
	at java.base/java.io.FileInputStream.<init>(FileInputStream.java:157)
	at java.base/java.io.FileReader.<init>(FileReader.java:75)
	at com.trilead.ssh2.Connection.authenticateWithPublicKey(Connection.java:504)
	at com.cloud.utils.ssh.SshHelper.scpFrom(SshHelper.java:69)
	at org.apache.cloudstack.diagnostics.DiagnosticsServiceImpl.copyToSecondaryStorageVMware(DiagnosticsServiceImpl.java:345)
	at org.apache.cloudstack.diagnostics.DiagnosticsServiceImpl.copyZipFileToSecondaryStorage(DiagnosticsServiceImpl.java:256)
	at org.apache.cloudstack.diagnostics.DiagnosticsServiceImpl.getDiagnosticsDataCommand(DiagnosticsServiceImpl.java:225)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)

This is because, on ubuntu, the id_rsa file is placed at /var/lib/cloudstack/management/.ssh/
This PR fixes the above mentioned issue

Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[X] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

Feature/Enhancement Scale or Bug Severity
Bug Severity

[ ] BLOCKER
[ ] Critical
[ ] Major
[X] Minor
[ ] Trivial

Screenshots (if appropriate):
How Has This Been Tested?
Successfully ran getDiagnosticsData

Trillian test result (tid-1810)
Environment: kvm-ubuntu20 (x2), Advanced Networking with Mgmt server u20
Total time taken: 36232 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr5384-t1810-kvm-ubuntu20.zip
Intermittent failure detected: /marvin/tests/smoke/test_password_server.py
Intermittent failure detected: /marvin/tests/smoke/test_vpc_vpn.py
Smoke tests completed. 87 look OK, 0 have error(s)
Only failed tests results shown below:

Test
Result
Time (s)
Test File


Profile HFP Ofono no output and no input

Hi,
I am using my Raspberry Pi as a "bluetooth speaker, music controller and call controller" for my phone.
I installed debian ofono package.
I installed bluealsa from master using :
git clone git@github.com:raspberrypi-ui/bluealsa.git && cd bluealsa/
autoreconf --install
mkdir build && cd build
../configure --enable-ofono --enable-debug --enable-aplay
make -j4
sudo make install

I launch bluealsa in a service file :
/usr/bin/bluealsa --profile=a2dp-sink --profile=hfp-ofono

~/.asoundrc
pcm.!default {
	type asym
	playback.pcm {
		type plug
		slave.pcm "dmixer"
	}
	capture.pcm {
		type plug
		slave.pcm "input"
	}
}

pcm.bluealsadmix {
    type plug
    slave.pcm "dmixer"
}

pcm.dmixer {
    type dmix
    ipc_key 1024
    slave.pcm "output"
}

pcm.output {
	type hw
	card 1
}

ctl.!default {
	type hw
	card 1
}

pcm.input {
	type hw
	card 1
}

bluealsa journal is the following one :
Oct 03 13:20:04 rpi4 bluealsa[438]: /usr/bin/bluealsa: ../../src/bluez.c:1330: Signal: org.freedesktop.DBus.Properties.PropertiesChanged()
Oct 03 13:20:04 rpi4 bluealsa[438]: /usr/bin/bluealsa: ../../src/bluez.c:1364: Signal: PropertiesChanged: org.bluez.MediaTransport1: State
Oct 03 13:20:04 rpi4 bluealsa[438]: /usr/bin/bluealsa: ../../src/ba-transport.c:601: State transition: 2 -> 0
Oct 03 13:20:04 rpi4 bluealsa[438]: /usr/bin/bluealsa: ../../src/ba-transport.c:749: Releasing transport: A2DP Sink (SBC)
Oct 03 13:20:04 rpi4 bluealsa[438]: /usr/bin/bluealsa: ../../src/ba-transport.c:778: Closing BT: 12
Oct 03 13:20:04 rpi4 bluealsa[438]: /usr/bin/bluealsa: ../../src/ba-transport.c:928: Exiting IO thread: A2DP Sink (SBC)
Oct 03 13:20:10 rpi4 bluealsa[438]: /usr/bin/bluealsa: ../../src/ofono.c:428: Called: org.ofono.HandsfreeAudioAgent.NewConnection()
Oct 03 13:20:10 rpi4 bluealsa[438]: /usr/bin/bluealsa: ../../src/ofono.c:384: New oFono SCO connection (codec: 0x1): 15
Oct 03 13:20:41 rpi4 bluealsa[438]: /usr/bin/bluealsa: ../../src/io.c:2248: SCO poll error status: 0x18
Oct 03 13:20:41 rpi4 bluealsa[438]: /usr/bin/bluealsa: ../../src/ofono.c:136: Closing oFono SCO: 15
Oct 03 13:20:41 rpi4 bluealsa[438]: /usr/bin/bluealsa: ../../src/bluez.c:1330: Signal: org.freedesktop.DBus.Properties.PropertiesChanged()
Oct 03 13:20:41 rpi4 bluealsa[438]: /usr/bin/bluealsa: ../../src/bluez.c:1364: Signal: PropertiesChanged: org.bluez.MediaTransport1: State
Oct 03 13:20:41 rpi4 bluealsa[438]: /usr/bin/bluealsa: ../../src/ba-transport.c:601: State transition: 0 -> 1
Oct 03 13:20:41 rpi4 bluealsa[438]: /usr/bin/bluealsa: ../../src/ba-transport.c:722: New transport: 12 (MTU: R:672 W:1008)
Oct 03 13:20:41 rpi4 bluealsa[438]: /usr/bin/bluealsa: ../../src/bluez.c:1330: Signal: org.freedesktop.DBus.Properties.PropertiesChanged()
Oct 03 13:20:41 rpi4 bluealsa[438]: /usr/bin/bluealsa: ../../src/bluez.c:1364: Signal: PropertiesChanged: org.bluez.MediaTransport1: State
Oct 03 13:20:41 rpi4 bluealsa[438]: /usr/bin/bluealsa: ../../src/ba-transport.c:601: State transition: 1 -> 2
Oct 03 13:20:41 rpi4 bluealsa[438]: /usr/bin/bluealsa: ../../src/io.c:2576: Created new IO thread: A2DP Sink (SBC)
Oct 03 13:20:41 rpi4 bluealsa[438]: /usr/bin/bluealsa: ../../src/io.c:305: Starting IO loop: A2DP Sink (SBC)

Bluetooth music with AD2P Sink works perfectly but, unfortunatly, phone calls do not produce any sound or hear anything.
Is there something I am missing in configurations file ?

I partialy solved my issue.
Launching a second "bluealsa-aplay service" with --profile-sco :
[Unit]
Description=BlueALSA Ofono aplay service
After=bluealsa.service
Requires=bluealsa.service

[Service]
Type=simple
User=pi
ExecStartPre=/bin/sleep 20
ExecStart=/usr/bin/bluealsa-aplay -vv --profile-sco -d ofonoalsadmix 00:00:00:00:00:00

[Install]
WantedBy=multi-user.target

I added to my .asoundrc :
pcm.ofonoalsadmix {
    type plug
    slave.pcm "dmixer"
}

However, I can't hear the sound of the microphone of my Raspberry PI in the caller's phone.
Am I missing something ?

sudo su
export LIBASOUND_THREAD_SAFE=0
bluealsa -p hfp-ofono
and in another terminal:
arecord -D bluealsa | aplay
to receive stream
and in another terminal:
arecord | aplay -D bluealsa
to send stream
sudo ofono-1.xx/test/dial-number 0815xyz
works, but huge delay 20s :-(
only using incomming stream the delay is ok –1s
cat ~/.asoundrc
defaults.bluealsa.service "org.bluealsa"
defaults.bluealsa.device "XX:XX:XX:XX:XX:XX"
defaults.bluealsa.profile "sco"
defaults.bluealsa.delay 10000

@dr-ni I can't explain the delay (I don't use ofono), but I advise that arecord by default always converts the stream to unsigned 8-bit samples. For use with HFP you should tell it to use signed 16-bit little-endian samples, so:
arecord -f s16_le -D bluealsa | aplay

and
arecord -f s16_le | aplay -D bluealsa

Also you could try to reduce the delay by setting explicit buffer and period sizes and start delay, I'm not sure how successful that will be though (see aplay --help and man aplay).

@borine @dr-ni
Given my .asoundrc
pcm.!default {
	type asym
	playback.pcm {
		type plug
		slave.pcm "dmixer"
	}
	capture.pcm {
		type plug
		slave.pcm "input"
	}
}

pcm.bluealsadmix {
    type plug
    slave.pcm "dmixer"
}

pcm.ofonoalsadmix {
    type plug
    slave.pcm "dmixer"
}

pcm.dmixer {
    type dmix
    ipc_key 1024
    slave.pcm "output"
}

pcm.output {
	type hw
	card 0
}

ctl.!default {
	type hw
	card 0
}

pcm.input {
    type hw
    card 0
}

How should I launch bluealsa-aplay in my service file to avoid doing:
arecord -f s16_le | aplay -D bluealsa

@xavi-b

Am I missing something ?

Your description does not say how you intend to capture sound from the microphone to send to bluealsa sco device. The bluealsa-aplay application does not do that for you. So arecord -f s16_le | aplay -D bluealsa is one way. If you have bluealsa v3.0.0 or later, you could try as an alternative:
alsaloop -f s16_le -c 1 -r 8000 -P bluealsa -t 100000
Note that both those commands assume that you have
defaults.bluealsa.device "XX:XX:XX:XX:XX:XX"
defaults.bluealsa.profile "sco"

in your ,asoundrc file

So the command /usr/bin/bluealsa-aplay -vv --profile-sco -d ofonoalsadmix 00:00:00:00:00:00 only works for the audio sent from the phone to the Linux system ?
I have to admit I expected it to also work for the audio sent from (the microphone of) the Linux system to the phone when setting a ..
Will it work with any connected device if I replace "XX:XX:XX:XX:XX:XX" with 00:00:00:00:00:00 ?

defaults.bluealsa.device "XX:XX:XX:XX:XX:XX"
defaults.bluealsa.profile "sco"

Won't adding those lines affect all my configured PCM devices ?

I have to admit I expected it to also work for the audio sent from (the microphone of) the Linux system

No. The man page for bluealsa-aplay is available on-line here: https://github.com/Arkq/bluez-alsa/blob/master/doc/bluealsa-aplay.1.rst . There is no equivalent utility from the bluez-alsa project that sends audio in the other direction.

Will it work with any connected device if I replace "XX:XX:XX:XX:XX:XX" with 00:00:00:00:00:00 ?

No, unfortunately not. To use alsa utilities such as arecord or alsaloop you have to tell them a specific PCM device to capture from. And also, that device must be connected before the alsa utility is started otherwise it will fail with "No such device" error. So you cannot simply start arecord or alsaloop at boot, you have to wait until the device is connected. I don't use ofono, so I have limited experience here, if there are any other applications available that handle the outgoing audio side of the connection maybe someone else can advise.

Won't adding those lines affect all my configured PCM devices ?

They only apply to bluealsa devices, but yes it will apply to all of those. You can instead specify the device id on the application command line, e.g:
arecord -f s16_le -D plughw:0,0 | aplay -D bluealsa:DEV=XX:XX:XX:XX:XX:XX,PROFILE=sco

or
alsaloop -C plughw:0,0 -P bluealsa:DEV=XX:XX:XX:XX:XX:XX,PROFILE=sco,DELAY=0 -t 100000

That way there is no need for .asoundrc. See the wiki page https://github.com/Arkq/bluez-alsa/wiki/Using-the-bluealsa-ALSA-pcm-plugin for more information on using the bluealsa pcm plugin with alsa applications,

@borine
still not working correct with your suggestion
arecord -f s16_le -D bluealsa | aplay
and
arecord -f s16_le | aplay -D bluealsa

Also you could try to reduce the delay by setting explicit buffer and period sizes and start delay,
what do you think - what are good values to start testing?

pi@raspberrypi_zero_w:~$ sudo su
root@pilot:/home/pilot# export LIBASOUND_THREAD_SAFE=0
root@pilot:/home/pilot# bluealsa -p hfp-ofono
bluealsa: D: ofono.c:471: Registering oFono audio agent: /org/bluez/HFP/oFono
bluealsa: D: ofono.c:247: Adding new oFono card: /card_1
bluealsa: D: ba-transport.c:765: Starting transport: HFP Hands-Free (CVSD)
bluealsa: D: ba-transport.c:1047: Created new thread [ba-sco]: HFP Hands-Free (CVSD)
bluealsa: D: main.c:390: Acquiring D-Bus service name: org.bluealsa
bluealsa: D: main.c:395: Starting main dispatching loop
bluealsa: D: sco.c:241: Starting SCO loop: HFP Hands-Free (CVSD)
bluealsa: D: bluez.c:1009: Signal: org.freedesktop.DBus.ObjectManager.InterfacesRemoved()
bluealsa: D: bluez.c:1009: Signal: org.freedesktop.DBus.ObjectManager.InterfacesRemoved()
bluealsa: D: bluez.c:1009: Signal: org.freedesktop.DBus.ObjectManager.InterfacesRemoved()
bluealsa: D: bluez.c:1009: Signal: org.freedesktop.DBus.ObjectManager.InterfacesRemoved()
bluealsa: D: bluez.c:1009: Signal: org.freedesktop.DBus.ObjectManager.InterfacesRemoved()
bluealsa: D: bluez.c:1009: Signal: org.freedesktop.DBus.ObjectManager.InterfacesRemoved()
bluealsa: D: bluez.c:1009: Signal: org.freedesktop.DBus.ObjectManager.InterfacesRemoved()
bluealsa: D: bluez.c:1009: Signal: org.freedesktop.DBus.ObjectManager.InterfacesRemoved()
bluealsa: D: bluez.c:1009: Signal: org.freedesktop.DBus.ObjectManager.InterfacesRemoved()
bluealsa: D: dbus.c:59: Called: org.bluealsa.Manager1.GetPCMs() on /org/bluealsa
bluealsa: D: dbus.c:59: Called: org.bluealsa.PCM1.Open() on /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink
bluealsa: D: ba-transport.c:804: PCM resumed: 9
bluealsa: D: dbus.c:59: Called: org.bluealsa.Manager1.GetPCMs() on /org/bluealsa
bluealsa: D: dbus.c:59: Called: org.bluealsa.PCM1.Open() on /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/source
bluealsa: D: ba-transport.c:804: PCM resumed: 13
bluealsa: D: dbus.c:59: Called: org.ofono.HandsfreeAudioAgent.NewConnection() on /org/bluez/HFP/oFono
bluealsa: D: ofono.c:398: New oFono SCO connection (codec: 0x1): 15
bluealsa: D: hci.c:132: SCO link socket MTU: 15: 64
bluealsa: D: ba-transport.c:1021: Closing PCM: 13
bluealsa: D: sco.c:410: SCO poll error status: 0x18
bluealsa: D: ofono.c:137: Closing oFono SCO: 15
bluealsa: E: SCO write error: Bad file descriptor
bluealsa: D: dbus.c:59: Called: org.ofono.HandsfreeAudioAgent.NewConnection() on /org/bluez/HFP/oFono
bluealsa: D: ofono.c:398: New oFono SCO connection (codec: 0x1): 13
bluealsa: D: hci.c:132: SCO link socket MTU: 13: 64
bluealsa: D: sco.c:410: SCO poll error status: 0x18
bluealsa: D: ofono.c:137: Closing oFono SCO: 13
bluealsa: E: SCO write error: Bad file descriptor
pi@raspberrypi_zero_w:~$ arecord -f s16_le | aplay -D bluealsa
D: bluealsa-pcm.c:1004: Getting BlueALSA PCM: PLAYBACK xx_xx_xx_xx_xx_xx sco
D: bluealsa-pcm.c:876: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Setting constraints
Aufnahme: WAVE 'stdin' : Signed 16 bit Little Endian, Rate: 8000 Hz, mono
Wiedergabe: WAVE 'stdin' : Signed 16 bit Little Endian, Rate: 8000 Hz, mono
D: bluealsa-pcm.c:443: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Initializing HW
D: bluealsa-pcm.c:466: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: FIFO buffer size: 2048 frames
D: bluealsa-pcm.c:474: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Selected HW buffer: 4 periods x 2000 bytes == 8000 bytes
D: bluealsa-pcm.c:489: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Initializing SW
D: bluealsa-pcm.c:489: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Initializing SW
D: bluealsa-pcm.c:526: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Prepared
D: bluealsa-pcm.c:489: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Initializing SW
D: bluealsa-pcm.c:356: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Starting
D: bluealsa-pcm.c:213: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Starting IO loop: 7
Überlauf!!! (mindestens 13,358 ms)
Überlauf!!! (mindestens 12,476 ms)
D: bluealsa-pcm.c:218: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Pausing IO thread: -1
Unterlauf!!! (mindestens 244415,380 ms)
D: bluealsa-pcm.c:526: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Prepared
D: bluealsa-pcm.c:356: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Starting
D: bluealsa-pcm.c:232: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: IO thread resumed
pi@raspberrypi_zero_w:~$ arecord -f s16_le -D bluealsa | aplay
D: bluealsa-pcm.c:1004: Getting BlueALSA PCM: CAPTURE xx_xx_xx_xx_xx_xx sco
D: bluealsa-pcm.c:876: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/source: Setting constraints
Aufnahme: WAVE 'stdin' : Signed 16 bit Little Endian, Rate: 8000 Hz, mono
D: bluealsa-pcm.c:443: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/source: Initializing HW
D: bluealsa-pcm.c:466: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/source: FIFO buffer size: 32768 frames
D: bluealsa-pcm.c:474: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/source: Selected HW buffer: 4 periods x 2000 bytes == 8000 bytes
D: bluealsa-pcm.c:489: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/source: Initializing SW
D: bluealsa-pcm.c:489: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/source: Initializing SW
D: bluealsa-pcm.c:526: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/source: Prepared
D: bluealsa-pcm.c:489: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/source: Initializing SW
Wiedergabe: WAVE 'stdin' : Signed 16 bit Little Endian, Rate: 8000 Hz, mono
D: bluealsa-pcm.c:356: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/source: Starting
D: bluealsa-pcm.c:213: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/source: Starting IO loop: 7
aplay: xrun:1624: Lese-/Schreibfehler, Status = RUNNING
pi@raspberrypi_zero_w:~$

Unterlauf!!! (mindestens 244415,380 ms)

An underrun of over 4 minutes ? something seriously broken, i thiink!
Please can you post the versions of:
bluealsa (bluealsa --version)
alsa (aplay --version)
kernel (uname -vr)
also what kind of bluetooth adapter are you using: hciconfig -a

$ bluealsa --version
v3.0.0-9-g63e2eea
$ aplay --version
aplay: version 1.1.3 by Jaroslav Kysela<EMAIL_ADDRESS>$ uname -vr
4.19.66+ #1253 Thu Aug 15 11:37:30 BST 2019
$ hciconfig -a
hci0:	Type: Primary  Bus: UART
BD Address: xx:xx:xx:xx:xx:xx  ACL MTU: 1021:8  SCO MTU: 64:1
UP RUNNING
RX bytes:1596195 acl:114 sco:24726 events:427 errors:0
TX bytes:1681966 acl:69 sco:32256 commands:150 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'pilot'
Class: 0x200000
Service Classes: Audio
Device Class: Miscellaneous,
HCI Version: 4.1 (0x7)  Revision: 0x168
LMP Version: 4.1 (0x7)  Subversion: 0x2209
Manufacturer: Broadcom Corporation (15)

with bluez-alsa 3.0.0 and later, you can try alsaloop instead of arecord/aplay to get rid of the delay. You'll need to disable alsa thread blocking for this. Try:
LIBASOUND_THREAD_SAFE=0 alsaloop  -P bluealsa:DELAY=0 -t 100000

Also, it might be helpful to know which plugins are used by the default capture device. Please can you post the output from:
arecord -v -f s16_le -d 1 /dev/null

LIBASOUND_THREAD_SAFE=0 alsaloop  -P bluealsa:DELAY=0 -t 100000

I'll check this later...
$ arecord -v -f s16_le -d 1 /dev/null
Aufnahme: WAVE '/dev/null' : Signed 16 bit Little Endian, Rate: 8000 Hz, mono
Plug PCM: Rate conversion PCM (48000, sformat=S16_LE)
Converter: libsamplerate
Protocol version: 10002
Its setup is:
stream       : CAPTURE
access       : RW_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 1
rate         : 8000
exact rate   : 8000 (8000/1)
msbits       : 16
buffer_size  : 3000
period_size  : 1000
period_time  : 125000
tstamp_mode  : NONE
tstamp_type  : MONOTONIC
period_step  : 1
avail_min    : 1000
period_event : 0
start_threshold  : 1
stop_threshold   : 3000
silence_threshold: 0
silence_size : 0
boundary     : 196608000
Slave: Route conversion PCM (sformat=S16_LE)
Transformation table:
0 <- 00,5 + 10,5
Its setup is:
stream       : CAPTURE
access       : MMAP_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 1
rate         : 48000
exact rate   : 48000 (48000/1)
msbits       : 16
buffer_size  : 18000
period_size  : 6000
period_time  : 125000
tstamp_mode  : NONE
tstamp_type  : MONOTONIC
period_step  : 1
avail_min    : 6000
period_event : 0
start_threshold  : 6
stop_threshold   : 18000
silence_threshold: 0
silence_size : 0
boundary     :<PHONE_NUMBER>
Slave: Direct Snoop PCM
Its setup is:
stream       : CAPTURE
access       : MMAP_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 2
rate         : 48000
exact rate   : 48000 (48000/1)
msbits       : 16
buffer_size  : 18000
period_size  : 6000
period_time  : 125000
tstamp_mode  : NONE
tstamp_type  : MONOTONIC
period_step  : 1
avail_min    : 6000
period_event : 0
start_threshold  : 6
stop_threshold   : 18000
silence_threshold: 0
silence_size : 0
boundary     :<PHONE_NUMBER>
Hardware PCM card 0 'wm8960-soundcard' device 0 subdevice 0
Its setup is:
stream       : CAPTURE
access       : MMAP_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 2
rate         : 48000
exact rate   : 48000 (48000/1)
msbits       : 16
buffer_size  : 18000
period_size  : 6000
period_time  : 125000
tstamp_mode  : ENABLE
tstamp_type  : MONOTONIC
period_step  : 1
avail_min    : 6000
period_event : 0
start_threshold  : 1
stop_threshold   :<PHONE_NUMBER>
silence_threshold: 0
silence_size : 0
boundary     :<PHONE_NUMBER>
appl_ptr     : 0
hw_ptr       : 0

here now more - but only digital noise in the remote phone - no sound local
$ LIBASOUND_THREAD_SAFE=0 bluealsa -p hfp-ofono
bluealsa: D: ofono.c:471: Registering oFono audio agent: /org/bluez/HFP/oFono
bluealsa: D: ofono.c:247: Adding new oFono card: /card_1
bluealsa: D: ba-transport.c:765: Starting transport: HFP Hands-Free (CVSD)
bluealsa: D: ba-transport.c:1047: Created new thread [ba-sco]: HFP Hands-Free (CVSD)
bluealsa: D: main.c:390: Acquiring D-Bus service name: org.bluealsa
bluealsa: D: sco.c:241: Starting SCO loop: HFP Hands-Free (CVSD)
bluealsa: D: main.c:395: Starting main dispatching loop
bluealsa: D: dbus.c:59: Called: org.bluealsa.Manager1.GetPCMs() on /org/bluealsa
bluealsa: D: dbus.c:59: Called: org.bluealsa.Manager1.GetPCMs() on /org/bluealsa
bluealsa: D: dbus.c:59: Called: org.bluealsa.PCM1.Open() on /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink
bluealsa: D: ba-transport.c:804: PCM resumed: 9
bluealsa: D: ba-transport.c:838: PCM dropped: 9
bluealsa: D: ba-transport.c:1021: Closing PCM: 9
bluealsa: D: dbus.c:59: Called: org.bluealsa.Manager1.GetPCMs() on /org/bluealsa
bluealsa: D: dbus.c:59: Called: org.bluealsa.PCM1.Open() on /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink
bluealsa: D: ba-transport.c:804: PCM resumed: 9
bluealsa: D: dbus.c:59: Called: org.ofono.HandsfreeAudioAgent.NewConnection() on /org/bluez/HFP/oFono
bluealsa: D: ofono.c:398: New oFono SCO connection (codec: 0x1): 13
bluealsa: D: hci.c:132: SCO link socket MTU: 13: 64
bluealsa: D: ofono.c:137: Closing oFono SCO: 13
bluealsa: D: ba-transport.c:838: PCM dropped: 9
bluealsa: D: ba-transport.c:1021: Closing PCM: 9
^C
bluealsa: D: main.c:398: Exiting main loop
$ LIBASOUND_THREAD_SAFE=0 alsaloop -P bluealsa:DELAY=0 -t 100000
D: bluealsa-pcm.c:1004: Getting BlueALSA PCM: PLAYBACK xx:xx:xx:xx:xx:xx sco
D: bluealsa-pcm.c:876: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Setting constraints
D: bluealsa-pcm.c:443: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Initializing HW
D: bluealsa-pcm.c:466: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: FIFO buffer size: 2048 frames
D: bluealsa-pcm.c:474: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Selected HW buffer: 8 periods x 800 bytes == 6400 bytes
D: bluealsa-pcm.c:489: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Initializing SW
D: bluealsa-pcm.c:489: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Initializing SW
D: bluealsa-pcm.c:489: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Initializing SW
D: bluealsa-pcm.c:526: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Prepared
D: bluealsa-pcm.c:489: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Initializing SW
D: bluealsa-pcm.c:496: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Changing SW avail min: 400 -> 2600
D: bluealsa-pcm.c:526: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Prepared
D: bluealsa-pcm.c:356: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Starting
D: bluealsa-pcm.c:213: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Starting IO loop: 9
overrun for capture hw:0,0
overrun for capture hw:0,0
D: bluealsa-pcm.c:218: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Pausing IO thread: -1
underrun for playback bluealsa:DELAY=0
D: bluealsa-pcm.c:526: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Prepared
D: bluealsa-pcm.c:526: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Prepared
D: bluealsa-pcm.c:356: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Starting
D: bluealsa-pcm.c:232: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: IO thread resumed
D: bluealsa-pcm.c:218: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Pausing IO thread: -1
underrun for playback bluealsa:DELAY=0
D: bluealsa-pcm.c:526: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Prepared
D: bluealsa-pcm.c:526: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Prepared
D: bluealsa-pcm.c:356: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Starting
D: bluealsa-pcm.c:232: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: IO thread resumed
overrun for capture hw:0,0
overrun for capture hw:0,0
overrun for capture hw:0,0
^C
D: bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Stopping
D: bluealsa-pcm.c:145: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: IO thread cleanup
D: bluealsa-pcm.c:481: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Freeing HW
D: bluealsa-pcm.c:431: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Closing

no sound local

the alsaloop command I gave was only for outgoing audio. You still need a separate stream for incoming. If arecord | aplay was acceptable before, stick with that until you have outgoing audio working too.

only digital noise in the remote phone

Two other things to try:

increase the target latency for alsaloop:

LIBASOUND_THREAD_SAFE=0 alsaloop  -P bluealsa:DELAY=0 -t 500000

Avoid all plugins on the capture side by using the native format of the card:

LIBASOUND_THREAD_SAFE=0 alsaloop  -C hw:0,0 -f s16_le -c 2 -r 48000 -P bluealsa:DELAY=0 -t 500000

On my Raspberry PI 4, I have a 1 sec delay using
LIBASOUND_THREAD_SAFE=0 arecord -f s16_le | aplay -D bluealsa:DEV=XX:XX:XX:XX:XX:XX,PROFILE=sco
which is perfectly fine for me.
I will use my C++/Qt project and the Ofono-Qt lib signals to run this command each time a call is started with a specific device.
Thanks @borine !

sorry for the delay - no time yesterday
still very long delay while only sending :-(  but no errors:
root@raspberrypi_zero_w:/home/pi# LIBASOUND_THREAD_SAFE=0 bluealsa -p hfp-ofono
bluealsa: D: ofono.c:471: Registering oFono audio agent: /org/bluez/HFP/oFono
bluealsa: D: ofono.c:247: Adding new oFono card: /card_1
bluealsa: D: ba-transport.c:765: Starting transport: HFP Hands-Free (CVSD)
bluealsa: D: ba-transport.c:1047: Created new thread [ba-sco]: HFP Hands-Free (CVSD)
bluealsa: D: main.c:390: Acquiring D-Bus service name: org.bluealsa
bluealsa: D: main.c:395: Starting main dispatching loop
bluealsa: D: sco.c:241: Starting SCO loop: HFP Hands-Free (CVSD)
bluealsa: D: dbus.c:59: Called: org.bluealsa.Manager1.GetPCMs() on /org/bluealsa
bluealsa: D: dbus.c:59: Called: org.bluealsa.PCM1.Open() on /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink
bluealsa: D: ba-transport.c:804: PCM resumed: 9
bluealsa: D: dbus.c:59: Called: org.ofono.HandsfreeAudioAgent.NewConnection() on /org/bluez/HFP/oFono
bluealsa: D: ofono.c:398: New oFono SCO connection (codec: 0x1): 13
bluealsa: D: hci.c:132: SCO link socket MTU: 13: 64
bluealsa: D: sco.c:410: SCO poll error status: 0x18
bluealsa: D: ofono.c:137: Closing oFono SCO: 13
bluealsa: E: SCO write error: Bad file descriptor
^C
bluealsa: D: main.c:398: Exiting main loop
pi@raspberrypi_zero_w:~$ LIBASOUND_THREAD_SAFE=0 alsaloop  -P bluealsa:DELAY=0 -t 500000
D: bluealsa-pcm.c:1004: Getting BlueALSA PCM: PLAYBACK xx:xx:xx:xx:xx:xx sco
D: bluealsa-pcm.c:876: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Setting constraints
D: bluealsa-pcm.c:443: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Initializing HW
D: bluealsa-pcm.c:466: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: FIFO buffer size: 2048 frames
D: bluealsa-pcm.c:474: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Selected HW buffer: 8 periods x 4000 bytes == 32000 bytes
D: bluealsa-pcm.c:489: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Initializing SW
D: bluealsa-pcm.c:489: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Initializing SW
D: bluealsa-pcm.c:489: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Initializing SW
D: bluealsa-pcm.c:526: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Prepared
D: bluealsa-pcm.c:489: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Initializing SW
D: bluealsa-pcm.c:496: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Changing SW avail min: 2000 -> 13000
D: bluealsa-pcm.c:526: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Prepared
D: bluealsa-pcm.c:356: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Starting
D: bluealsa-pcm.c:213: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Starting IO loop: 9
D: bluealsa-pcm.c:145: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: IO thread cleanup
pcmjob failed
root@raspberrypi_zero_w:/home/pi# LIBASOUND_THREAD_SAFE=0 bluealsa -p hfp-ofono
bluealsa: D: ofono.c:471: Registering oFono audio agent: /org/bluez/HFP/oFono
bluealsa: D: ofono.c:247: Adding new oFono card: /card_1
bluealsa: D: ba-transport.c:765: Starting transport: HFP Hands-Free (CVSD)
bluealsa: D: ba-transport.c:1047: Created new thread [ba-sco]: HFP Hands-Free (CVSD)
bluealsa: D: main.c:390: Acquiring D-Bus service name: org.bluealsa
bluealsa: D: main.c:395: Starting main dispatching loop
bluealsa: D: sco.c:241: Starting SCO loop: HFP Hands-Free (CVSD)
bluealsa: D: dbus.c:59: Called: org.bluealsa.Manager1.GetPCMs() on /org/bluealsa
bluealsa: D: dbus.c:59: Called: org.bluealsa.PCM1.Open() on /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink
bluealsa: D: ba-transport.c:804: PCM resumed: 9
bluealsa: D: dbus.c:59: Called: org.ofono.HandsfreeAudioAgent.NewConnection() on /org/bluez/HFP/oFono
bluealsa: D: ofono.c:398: New oFono SCO connection (codec: 0x1): 13
bluealsa: D: hci.c:132: SCO link socket MTU: 13: 64
bluealsa: D: ba-transport.c:838: PCM dropped: 9
bluealsa: D: ba-transport.c:1021: Closing PCM: 9
bluealsa: D: sco.c:410: SCO poll error status: 0x18
bluealsa: D: ofono.c:137: Closing oFono SCO: 13
pi@raspberrypi_zero_w:~$ LIBASOUND_THREAD_SAFE=0 alsaloop  -C hw:0,0 -f s16_le -c 2 -r 48000 -P bluealsa:DELAY=0 -t 500000
D: bluealsa-pcm.c:1004: Getting BlueALSA PCM: PLAYBACK xx:xx:xx:xx:xx:xx sco
D: bluealsa-pcm.c:876: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Setting constraints
D: bluealsa-pcm.c:443: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Initializing HW
D: bluealsa-pcm.c:466: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: FIFO buffer size: 2048 frames
D: bluealsa-pcm.c:474: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Selected HW buffer: 8 periods x 4000 bytes == 32000 bytes
D: bluealsa-pcm.c:489: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Initializing SW
D: bluealsa-pcm.c:489: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Initializing SW
D: bluealsa-pcm.c:489: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Initializing SW
D: bluealsa-pcm.c:526: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Prepared
D: bluealsa-pcm.c:489: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Initializing SW
D: bluealsa-pcm.c:496: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Changing SW avail min: 2000 -> 13000
D: bluealsa-pcm.c:526: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Prepared
D: bluealsa-pcm.c:356: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Starting
D: bluealsa-pcm.c:213: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Starting IO loop: 9
^CD: bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Stopping
D: bluealsa-pcm.c:145: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: IO thread cleanup
D: bluealsa-pcm.c:481: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Freeing HW
D: bluealsa-pcm.c:431: /org/bluealsa/hci0/dev_xx_xx_xx_xx_xx_xx/hfphf/sink: Closing

@dr-ni is the delay still around 20 seconds with alsaloop, or is it now a more understandable 1 or 2 seconds ? Have you tested your local microphone to send to a locally-connected speaker instead of sending to bluealsa? I really cannot understand where such a long delay is coning from.

@dr-ni is the delay still around 20 seconds with alsaloop, or is it now a more understandable 1 or 2 seconds ?

still around 7 to 10s

Have you tested your local microphone to send to a locally-connected speaker instead of sending to bluealsa?

arecord -f s16_le | aplay works pretty fast

If possible, you could also try with USB bluetooth dongle instead of the on-board UART device. If your board is a Raspberry Pi then there may be issues with the UART configuration, or with Wifi interference.

in the past bluetooth was working good in combination with wifi, may be I'll buy a dongle for testing

why is then only receiving working ok?

I don't know either. Clearly a similar setup is working for @xavi-b who is also using an RPi, but doesn't say which model. A delay of 7s needs buffering of  112kB, so that is definitely not in any bluealsa code, nor in the bluetooth stack (HFP latency should not exceed 7.5ms within the bluetooth-specified components). So the HCI link (ie UART serial device on the RPi) is the only other place I can think of. You may well be right though, I can think of no explanation why or how the UART could be at fault.

If i am using 3.0, can i run two instances of alsaloop, one for playback and another for capture ?

This issue has been idle for a year now. There have been some changes to the BlueALSA server and plugins since then, and there are now also some notes on using the SCO profiles in the wiki here: https://github.com/Arkq/bluez-alsa/wiki/Using-BlueALSA-with-HFP-and-HSP-Devices.
If anyone has issues with the latest BlueALSA code with HFP or HSP after reading the wiki article, please raise a new issue with debug output from the latest code.


sysvol: init at 0-unstable-2024-06-07

Description of changes
sysvol is a GTK4 volume indicator, similar to packages like wob, avizo, or swayosd. built for wayland and pipewire (or pulse -- if you pass PULSEAUDIO=1 to makeFlags -- but it can only be built for one or the other). nix-build -A sysvol and run the binary, then adjust the system volume externally, and you should see an overlay like as shown on the project's readme.
licensed under wtfpl as per here.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Seems like the -v argument is broken:

should be fixed now; it gets these from git, so needed leaveDotGit = true.
$ sysvol -v
Commit: Wireplumber Cleanup
Date: 2024-06-07

Result of nixpkgs-review pr 318440 run on x86_64-linux 1

1 package built:

syshud


Balance Not Showing Up in PirateWallet Lightclient

As of Tuesday, May 4, 2021, 5:21am, My PirateWallet Lightclient v1.04 I get the message:
There was an error sending the transaction.  The error was:
Server's latest block(647215) is behind ours(1371363)
I double-checked this account on the Ghostship OS that also runs PirateWallet Lightclient.
It synced up to all the blocks and gave no error - but - SHOWED a balance of ZERO too!

Same problem. I hope someone from the Pirate team says something soon.

Anyone get any answers?


Refactor cluster patch

Please provide a description for what this PR is for.
Now this is the general way to do cluster patch, like listener patch.
And to help us figure out who should review this PR, please
put an X in all the areas that this PR affects.
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Pull Request Attributes
Please check any characteristics that apply to this pull request.
[ ] Does not have any user-facing changes. This may include CLI changes, API changes, behavior changes, performance improvements, etc.

@hzxuzhonghu: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
daa23f61204892ee9285efdd2167b324f7781ef3
link
/test release-notes_istio

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

@hzxuzhonghu: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
daa23f61204892ee9285efdd2167b324f7781ef3
link
/test release-notes_istio

lint_istio
daa23f61204892ee9285efdd2167b324f7781ef3
link
/test lint_istio

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

They should not conflict, the cache key used by cds is not changed.

We need to apply the patches to individual clusters, not all clusters in
aggregate. The cache works on a per-cluster basis not a collection of
clusters
On Tue, Jun 15, 2021, 6:56 PM Zhonghu Xu @.***> wrote:

They should not conflict, the cache key used by cds is not changed.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/33431#issuecomment-861955420, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXNNONCJ5NYIILTZHXDTTAAGNANCNFSM46WTITGQ
.

@hzxuzhonghu: PR needs rebase.

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


(Azure CXP) fixes MicrosoftDocs/azure-docs#1274

Fixed Install Powershell link

Docs Build status updates of commit aefa8d2:
:clock10: Full build: the average full build time is 22 min(s) 34 sec(s), this is based on the last 266 build(s) for this repository.

Docs Build status updates of commit aefa8d2:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-conceptual/azurermps-6.13.0/overview.md
:white_check_mark:Succeeded
View (azurermps-6.13.0)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

#sign-off


Update docker runtime with the latest openjdk:24-slim image tag

the openjdk:17-slim image is outdated with high- and critical-level vulnerabilities. Updating it with the latest image should fix the issue.

Careful, we had an eclipse-temurin JDK which resulted random crashes with the docker image, I think we need to use an ubuntu official build for the docker image, because the base image for tensorflow is ubuntu-based, and we never had problems with openjdk in contrast.


Update Dhalion dependency version

Dhalion version 0.2.x has many api and feature improvements. For e.g.

Deep-nested hashmaps have been replaced with filter-friendly table structures. This reduces the code required to add new health policy components in Heron.
The new Dhalion version also adds a state cache which provides access to all the events created in the past. Event history is needed by some components, which earlier required to manage their own state. It will also be used to publish metrics required by Heron.
Provides execution checkpoint/timestamp to which all outputs can be tagged.
The new version also strictly enforces type of event a specific phase can create and uses a consistent structure for output generated from each phase.

The PR includes updates to heron components according to the updated Dhalion api.

@kramasamy  any further comments?

I am planning to merge this PR today. Please let me know if anyone has additional comments. Thanks !


various: update zod/openapi, consolidate zod location

updates @hono/zod-openapi to 0.15.0
uses extendZodWithOpenApi on regular old zod in a library file. If we see further weird phenomenon we need to look more at the zod that gets shipped with zod-openapi because it's not intended for use as sole middleware
amends all our server responses to always give a status code

Tested by pushing nolita@experimental tag and running in a Docker container running node 20 and no other dependencies. I think this is safe to hit dev for further testing of functionality.

Poking around and now it seemingly doesn't get anything coming in from requests, but again ... only in prod (running npx nolita@experimental serve; pnpm run build will produce a build):
TypeError: Cannot destructure property 'agent' of 'c.req.valid(...)' as it is undefined.
    at Array.<anonymous> (/usr/src/app/nolita/node_modules/nolita/dist/server/browser/launch.js:68:20)
    at _OpenAPIHono.dispatch (/usr/src/app/nolita/node_modules/hono/dist/cjs/hono-base.js:210:38)
    at fetch (/usr/src/app/nolita/node_modules/hono/dist/cjs/hono-base.js:236:17)
    at Server.<anonymous> (/usr/src/app/nolita/node_modules/@hono/node-server/dist/index.js:440:13)
    at Server.emit (node:events:519:28)
    at parserOnIncoming (node:_http_server:1140:12)
    at HTTPParser.parserOnHeadersComplete (node:_http_common:119:17)

My only guess is a stray npm warn ERESOLVE overriding peer dependency preventing conversion of JSON to whatever Hono seems to want, but npm doesn't really tell you what it can't resolve. Assessing the dependency graph again...

The peer dependency thing seems rather moot so no wonder it doesn't report anything.
npm verbose attempt to log crashed ERESOLVE overriding peer dependency {
npm verbose   code: 'ERESOLVE',
npm verbose   edge: {
npm verbose     type: 'peer',
npm verbose     name: 'zod',
npm verbose     spec: '^3.23.3',
npm verbose     error: 'INVALID',
npm verbose     from: {
npm verbose       name: 'zod-to-json-schema',
npm verbose       version: '3.23.1',
npm verbose       location: 'node_modules/zod-stream/node_modules/zod-to-json-schema',
npm verbose       isWorkspace: false,
npm verbose       dependents: [Array]
npm verbose     }
npm verbose   },
npm verbose   dep: {
npm verbose     name: 'zod',
npm verbose     version: '3.23.8',
npm verbose     whileInstalling: {
npm verbose       name: 'zod-stream',
npm verbose       version: '1.0.3',
npm verbose       path: '/usr/src/app/nolita/node_modules/zod-stream'
npm verbose     },
npm verbose     location: 'node_modules/zod',
npm verbose     isWorkspace: false,
npm verbose     dependents: [ [Object] ]
npm verbose   },
npm verbose   force: false,
npm verbose   isMine: false,
npm verbose   strictPeerDeps: false,
npm verbose   current: {
npm verbose     name: 'zod',
npm verbose     version: '3.22.4',
npm verbose     location: 'node_modules/zod',
npm verbose     isWorkspace: false,
npm verbose     dependents: [ [Object] ]
npm verbose   },
npm verbose   peerConflict: {
npm verbose     name: 'zod',
npm verbose     version: '3.22.4',
npm verbose     location: 'node_modules/zod',
npm verbose     isWorkspace: false,
npm verbose     dependents: [ [Object] ]
npm verbose   }
npm verbose } TypeError: Cannot read properties of undefined (reading 'extraneous')
npm verbose     at printNode (/usr/local/lib/node_modules/npm/lib/utils/explain-dep.js:24:13)
npm verbose     at explainNode (/usr/local/lib/node_modules/npm/lib/utils/explain-dep.js:4:3)
npm verbose     at explain (/usr/local/lib/node_modules/npm/lib/utils/explain-eresolve.js:39:16)
npm verbose     at #tryWriteLog (/usr/local/lib/node_modules/npm/lib/utils/display.js:345:41)
npm verbose     at /usr/local/lib/node_modules/npm/lib/utils/display.js:233:28
npm verbose     at process.<anonymous> (/usr/local/lib/node_modules/npm/lib/utils/display.js:95:10)
npm verbose     at process.emit (node:events:531:35)
npm verbose     at Object.warn (/usr/local/lib/node_modules/npm/node_modules/proc-log/lib/index.js:62:22)
npm verbose     at PlaceDep.warnPeerConflict (/usr/local/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/place-dep.js:496:9)
npm verbose     at new PlaceDep (/usr/local/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/place-dep.js:165:14)

All this is complaining about schema-stream, our lone dependency pinned to 3.22.4 zod, for some reason, even though it isn't, on the same version, on GitHub meaning their npm code and their GitHub code differ. Everything else will take ^3.22 and up. This shouldn't affect Hono not receiving incoming JSON, though why only built via this CI and deployed to npm? Let me try building one and pushing to experimental.

Anyway, filed that, but I genuinely have no idea what's going on here anymore. Are you able to debug incoming JSON blobs ... only in prod???

If we use @hono/zod-openapi's z, everything seems hunky dory. The difference between this PR and #115 is that this PR uses the latest versions of everything, so ... maybe this is the one you really want.


Allow to disable pagination

Is your feature request related to a problem? Please describe.
How can i disable the pagination? When i tried to not chain the limit and page, i got an error says "page or limit cannot be less than 0"
Describe the solution you'd like
Like this NPM (JS) package here, there is an option "pagination"  if it is set to false, it will return all docs without adding limit condition. (Default: True)

@ahmedfaragngoco this package was developed for pagination purposes, so I think adding this feature will not serve any purpose because you can use normal queries to get data without pagination.


performPrivateCommand provokes Null exception

Steps to Reproduce
I do not know which widget provokes this exception.
Not having the error-causing widget is still a recurrent problem with all kinds of debugging in Flutter.

Logs
Exception
Fatal Exception: io.flutter.plugins.firebase.crashlytics.FlutterError: Null check operator used on a null value. Error thrown Instance of 'ErrorDescription'.
       at EditableTextState.performPrivateCommand(editable_text.dart:2155)
       at TextInput._handleTextInputInvocation(text_input.dart:1821)
       at TextInput._loudlyHandleTextInputInvocation(text_input.dart:1701)
       at MethodChannel._handleAsMethodCall(platform_channel.dart:536)
       at MethodChannel.setMethodCallHandler.<fn>(platform_channel.dart:529)
       at _DefaultBinaryMessenger.setMessageHandler.<fn>(binding.dart:387)

Flutter doctor
[√] Flutter (Channel stable, 3.3.0, on Microsoft Windows [version 10.0.19044.1889], locale fr-BE)
    • Flutter version 3.3.0 on channel stable at C:\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision ffccd96b62 (9 days ago), 2022-08-29 17:28:57 -0700
    • Engine revision 5e9e0e0aa8
    • Dart version 2.18.0
    • DevTools version 2.15.0

[√] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at C:\Users\user\AppData\Local\Android\sdk
    • Platform android-33, build-tools 30.0.3
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 11.0.12+7-b1504.28-7817840)
    • All Android licenses accepted.

[√] Visual Studio - develop for Windows (Visual Studio Community 2022 17.1.6)
    • Visual Studio at C:\Program Files\Microsoft Visual Studio\2022\Community
    • Visual Studio Community 2022 version 17.1.32421.90
    • Windows 10 SDK version 10.0.19041.0

[√] Android Studio (version 2021.2)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin can be installed from:
       https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
       https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.12+7-b1504.28-7817840)

[√] VS Code, 64-bit edition (version 1.68.1)
    • VS Code at C:\Program Files\Microsoft VS Code
    • Flutter extension version 3.44.0

[√] Connected device (2 available)
    • SM A750FN (mobile) • 32005e294fcf368d • android-arm64 • Android 10 (API 29)
    • Windows (desktop)  • windows          • windows-x64   • Microsoft Windows [version 10.0.19044.1889]

[√] HTTP Host Availability
    • All required HTTP hosts are available

• No issues found!

I believe this has already been fixed in https://github.com/flutter/flutter/pull/107683/files#diff-f5f93c879cef9a102adbf148583de9f3d9a05f9678fdcad7bde106f62200bb34

@LongCatIsLooong I also have the same issue from the stable version 3.3.
The fix is not available in the Latest stable version.

Same issue reported by a user to our crash reporting system, version 3.3.1.
Stacktrace:
Message: Null check operator used on a null value
EditableTextState.performPrivateCommand in package:flutter/src/widgets/editable_text.dart:2155
TextInput._handleTextInputInvocation in package:flutter/src/services/text_input.dart:1821
TextInput._loudlyHandleTextInputInvocation in package:flutter/src/services/text_input.dart:1701
MethodChannel._handleAsMethodCall in package:flutter/src/services/platform_channel.dart:536
MethodChannel.setMethodCallHandler.<fn> in package:flutter/src/services/platform_channel.dart:529
_DefaultBinaryMessenger.setMessageHandler.<fn> in package:flutter/src/services/binding.dart:387
_invoke2 in dart:ui/hooks.dart:186
_ChannelCallbackRecord.invoke in dart:ui/channel_buffers.dart:42
_Channel.push in dart:ui/channel_buffers.dart:132
ChannelBuffers.push in dart:ui/channel_buffers.dart:329
PlatformDispatcher._dispatchPlatformMessage in dart:ui/platform_dispatcher.dart:599
_dispatchPlatformMessage in dart:ui/hooks.dart:89

I believe the problem is this line here: https://github.com/flutter/flutter/blob/4f9d92fbbdf072a70a70d2179a9f87392b94104c/packages/flutter/lib/src/widgets/editable_text.dart#L2155
The patch https://github.com/flutter/flutter/pull/107683/files#diff-f5f93c879cef9a102adbf148583de9f3d9a05f9678fdcad7bde106f62200bb34 should fix it, however is still not available on stable.
Also going to older versions of Flutter won't fix the issue either, i.e. the exclamation call is still there in 3.0.5: https://github.com/flutter/flutter/blob/3.0.5/packages/flutter/lib/src/widgets/editable_text.dart#L2016 and there seems to be other older similar reports: https://github.com/flutter/flutter/issues/76601
So the only thing we can do is to wait for the patch to be published.


Cleanup of TranslationUnit and CodeCompleteResults.

@zalox: hope you can look over and merge this soon. The main problem was a bit confusing constructors and methods, and the std::map that forced us to previously do a copy of the source buffer (which is expensive). This is fixed now.
Mind that only one unsaved buffer is used now when calling the libclang functions. I really do not see any case where sending several unsaved files to libclang is a good idea, at least we would never do that in juCi++. If this is needed anyway (highly doubtful), I suggest that we try find a better solution than std::map, in order to avoid copy.

I used this approach to eliminate some common use-cases.
For instance:

Edit header file (add definitions)
Jump to implementation file
Now I expect accurate completions from the header file, which I won't get unless I remember to save

Reparsing based on a changed header that is not saved is a bad idea since libclang have to recreate its translation unit cache and this is very slow. Also if a header file is changed and not saved, the errors and warnings would not reflect what would happen if you run compile.


CLOUDP-190400: Disable and hide deletion protection

We cannot release it yet, not even disabled by default, as it is still needs to be implemented on several Custom Resources.
All Submissions:

[X] Have you signed our CLA?
[ ] Put closes #XXXX in your comment to auto-close the issue that your PR fixes (if there is one).
[ ] Update docs/release-notes/release-notes.md if your changes should be included in the release notes for the next release.

I merge into deletion-protection-main first, so that the PR can be reviewed properly for this particular change. But after this is merged, it is safe to deletion-protection-main into main.