Restore "show all key bindings" shortcut

Description

This PR restore "show all key bindings" shortcut and adds an option to edit it from preferences dialog
Type of change

[x] Bug-fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

References

fix  #4625
How has this been tested?

[ ] example: the test suite for my feature covers cases x, y, and z
[ ] example: all tests pass with my change
[ ] example: I check if my changes works with both PySide and PyQt backends
as there are small differences between the two Qt bindings.

Final checklist:

[ ] My PR is the minimum possible work for the desired functionality
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] If I included new strings, I have used trans. to make them localizable.
For more information see our translations guide.

on Ubuntu nothing happens when I press Ctrl+Alt+/

Strange. I develop this on ubuntu. Did you test it on napari plugi or it is possible that some plugin overwritten it?

Did you test it on napari plugi or it is possible that some plugin overwritten it?

I tested in a brand new conda env so I don't think it's a plugin overwrite - especially since even after I changed the shortcut it still didn't work. I tried other shortcuts and they did work. It could just be something with my machine though so it would be good if someone else could try on Ubuntu.

This is my napari --info:
napari: 0.4.16rc2.dev79+gddafd39c
Platform: Linux-5.4.0-113-generic-x86_64-with-glibc2.31
System: Ubuntu 20.04.4 LTS
Python: 3.9.12 (main, Jun  1 2022, 11:38:51)  [GCC 7.5.0]
Qt: 5.15.2
PyQt5: 5.15.6
NumPy: 1.22.4
SciPy: 1.8.1
Dask: 2022.05.2
VisPy: 0.10.0

OpenGL:
  - GL version:  4.6 (Compatibility Profile) Mesa 21.2.6
  - MAX_TEXTURE_SIZE: 16384

Screens:
  - screen 1: resolution 1920x1080, scale 1.0
  - screen 2: resolution 1920x515, scale 1.0

Plugins:
  - console: 0.0.4
  - napari-svg: 0.1.6
  - scikit-image: 0.4.16rc2.dev79+gddafd39c

in the console:
from napari.utils.action_manager import action_manager
action_manager.trigger("napari:show_shortcuts")

did this show shortcuts in preferences?
And what desktop environment do you have on ubuntu? Gnome?

If I run the above in console or ipython I get:
>>> from napari.utils.action_manager import action_manager
>>> action_manager.trigger("napari:show_shortcuts")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/draga/napari/napari/utils/action_manager.py", line 376, in trigger
    return self._actions[name].injected()
KeyError: 'napari:show_shortcuts'

I am indeed using gnome.

Hm.
I think that we found the core of the problem. If the action manager does not know the action then we have a problem
what happens if you call
$ pytest napari/_qt/menus/_tests/test_file_menu.py

did it collect 2 rest and both pass?

@Czaki yeah oddly enough, when I run pytest on that file in that environment, the tests pass fine...
(napari-edit) draga@DragaZenBook:~/napari$ python -m pytest napari/_qt/menus/_tests/test_file_menu.py
============================================================ test session starts =============================================================
platform linux -- Python 3.9.12, pytest-7.1.2, pluggy-1.0.0
PyQt5 5.15.6 -- Qt runtime 5.15.2 -- Qt compiled 5.15.2
rootdir: /home/draga/napari, configfile: pyproject.toml
plugins: napari-0.4.16rc2.dev79+gddafd39c, qt-4.0.2, hypothesis-6.47.0, napari-plugin-engine-0.2.0
collected 2 items

napari/_qt/menus/_tests/test_file_menu.py ..                                                                                [100%]

============================================================ slowest 10 durations ============================================================
0.89s call     napari/_qt/menus/_tests/test_file_menu.py::test_sample_data_triggers_reader_dialog
0.45s call     napari/_qt/menus/_tests/test_file_menu.py::test_show_shortcuts_actions
0.21s setup    napari/_qt/menus/_tests/test_file_menu.py::test_sample_data_triggers_reader_dialog
0.14s teardown napari/_qt/menus/_tests/test_file_menu.py::test_sample_data_triggers_reader_dialog
0.04s setup    napari/_qt/menus/_tests/test_file_menu.py::test_show_shortcuts_actions
0.03s teardown napari/_qt/menus/_tests/test_file_menu.py::test_show_shortcuts_actions
============================================================= 2 passed in 2.23s ==============================================================

Do you know why it was removed ? Could it be that it conflict with something else on some keyboard layouts ?


This resolves #43 by making epoch configurable.

Moved epoch from being hardcoded 0 in the build() method into a new setPackage() method, and maintains the old functionality.

Thanks for the patch!


Metallib parse failed: incompleteFunctionInfo

Metallib parse failed: incompleteFunctionInfo
web app

Thank you. Your email is received and will be handled  as soon as possible.


Cli test

Add a test to see if CLI still works to prevent reoccurence of #64

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
294

Relevant Lines:
294

💛  - Coveralls


added GitHub action to request review of PR

Description
this will auto request review of PR from the admin and collaborators
Fixes # (issue)
#134

[x] New feature (non-breaking change which adds functionality)

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] Any dependent changes have been merged and published in downstream modules
[x] I have added all the three reviewers: @vinitshahdeo, @kashish121 & @ishika1727

@Kashish121 @vinitshahdeo @ishika1727 please have a look


Add types.

Hard to do this with just core, being that telnetserver/telnetsocket and websocketserver/websocket aren't in the repo and offered as a bundle. But added some base classes and updated as best I could.
Updated EventUtil as well to account for null as the player.socket can accept the type null and can be the case that a player instance exists without a socket. Makes sense to handle in that EventUtil.
This setup is pretty much what I have in my game, but thought I could PR it into this repo. Let me know if there is anything better we can do, but it might be a good next step to have this in.

Looks link my prettier made a few changes as well.


[d3d11] Make D3D11Device share DXGIDevice's refcount

If we query IDXGIDevice interface from d3d11 device as follows:
D3D11CreateDevice(..., &device, NULL, NULL);
device->QueryInterface(IDXGIDevice, (void **)&dxgi_device);
then manipulating dxgi_device's refcount using AddRef()/Release() will
also change device's refcount (and vice versa). In fact they seem to match.
Also, according to wine's tests, code like
D3D11CreateDevice(..., &device, NULL, NULL);
device->QueryInterface(IDXGIDevice, (void **)&dxgi_device);
device->Release();
does not destroy the device. Make the refcount shared to implement this.

Unsure if it's the right approach, but it makes wine's tests progress much further.

The main issue here is that DXVK does not follow COM rules properly, so messing around with the ref count will probably cause more issues than it solves.
A better solution would be to create some sort of container object which stores all the objects, implements QueryInterface and the reference counting methods, and D3D11Device and DXGIDevice would store a pointer to that object.

ae88f83b8691fad6432409c09e017606b747b547 should fix this.


Missing Resumable Upload

Currently the Gmail client uses multipart upload, which is capped at 5MB.
Is there a way to use it to do resumable uploads for larger files?

@Joe-brainlabs No, typically we zip to get around this.

It looks like your best bet is to upload to Google Drive and send an email with a link to the new file.


move version to vs2019, the 1903 sdk, and the 14.2 build tools.

Summary of the Pull Request
Moves the solution to VS2019 and the latest SDK/tools

PR Checklist

[x] Closes #565
[x] CLA signed. If not, go over here and sign the CLA
[x] Tests added/passed
[x] Does not require documentation to be updated
[x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #565

Detailed Description of the Pull Request / Additional comments
This is sitting here until we figure out what to do with the build agents regarding versioning and signing.

WELP. Looks like the 2019 hosted pool doesn't have the 1903 SDK yet either...
https://github.com/Microsoft/azure-pipelines-image-generation/blob/master/images/win/Vs2019-Server2019-Readme.md

Dependent on https://github.com/microsoft/azure-pipelines-image-generation/issues/734 and the discussion in https://github.com/microsoft/azure-pipelines-image-generation/pull/770

In VS2019, we don't have to specify SDK full version number. VS selects latest version. For example, we can use 10 instead of 10.0.18362.0.

I ran this locally on my machine after I saw that it failed the pipeline as the pipeline doesn’t have the v142 tool kit and the build was a success! I downloaded the zip from this Archive and set it up just as mentioned in #489 as #565 only worked the first build then failed afterwards. In this attempt I specifically retargeted the build to the 10.0.18362.0 SDK and checked the toolkit to make sure it was targeted to v142 despite knowing it is now predefined in the code. I let it run and it came back with a few warnings that are all common in the other pipeline builds but not of massive concern as the build did succeed. I certainly do hope to see this solution work for others. Keep up the great work!

18362 is coming...
https://github.com/microsoft/azure-pipelines-image-generation/pull/953

If there ever was a pipeline that's in dire need of azure devops build cache save/restore tasks, this one is it. Apparently these things are real, and coming pretty soon.

If there ever was a pipeline that's in dire need of azure devops build cache save/restore tasks, this one is it. Apparently these things are real, and coming pretty soon.

Say what now? Can you provide a link to this?

@miniksa Looks like it's available for testing for internal orgs: https://github.com/Microsoft/azure-pipelines-yaml/pull/113

@andersosuthus, thanks. We're not operating as an internal org right now, so I'll probably wait on this like the rest of everyone in the public.

I'm going to tee this up again now that all our dependencies have merged.

/azp run

any update on this?

We're waiting on the 18362 SDK to be deployed to the Azure DevOps tenant from which we're running our CI builds.

/azp run


[FEATURE]: Leaderboard positions

Feature Summary
It would be great to have the position for each racer displayed on the leader board next to their username, reduces cognitive load and improves UX.
I will work on this if approved
Code of Conduct

[X] I agree to follow this project's Code of Conduct

This would be a really nice UX change. But right now I'm working on adding new field (Top languages) in leader-boards consequently updating leader-board UI which might cause conflict with this.

No problem at all, you go ahead. I can wait until you are done, or if you want to add the position yourself,   feel free 👍.

My task is completed and you are proceed ahead.

Thank you,  I will look to make a start this evening ✅

@bkbCodes I think you can link this issue to your PR to close it when your pr is merged 👌🏼

I'll pull from your branch to continue from that or should I work from start?

I'll pull from your branch to continue from that or should I work from start?

sorry, i had deleted branch but have restored now

This one https://github.com/BlakeLawrence/code-racer/tree/leaderboard-place right?


Enable automatic merging of "Bump version" pull requests

The goal is to make the "Bump version in project.go" pull requests faster to merge.
To be tested: what happens in a GitHub repo that has "automatic merging" disabled?
Checklist

[x] Update changelog in CHANGELOG.md.

If the repo does not allow auto-merge, the gh pr merge --auto fails with exit code one. To prevent the action from failing, I made the command an OR term.


Encode heights used as keys in sled-based light store in big-endian representation

Close #769

[x] Referenced an issue explaining the need for the change
[x] Updated all relevant documentation in docs
[x] Updated all code comments where relevant
[ ] Wrote tests
[ ] Updated CHANGELOG.md

Codecov Report

Merging #768 (4fbf84b) into master (e65337a) will increase coverage by 0.0%.
The diff coverage is 0.0%.

@@          Coverage Diff           @@
##           master    #768   +/-   ##
======================================
  Coverage    50.6%   50.6%
======================================
  Files         197     197
  Lines       13567   13562    -5
  Branches     3249    3242    -7
======================================
  Hits         6869    6869
+ Misses       6336    6334    -2
+ Partials      362     359    -3

Impacted Files
Coverage Δ

light-client/src/store/sled.rs
0.0% <0.0%> (ø)

light-client/src/store/sled/utils.rs
0.0% <0.0%> (ø)

Continue to review full report at Codecov.

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

Codecov Report

Merging #768 (4fbf84b) into master (e65337a) will increase coverage by 0.0%.
The diff coverage is 0.0%.

@@          Coverage Diff           @@
##           master    #768   +/-   ##
======================================
  Coverage    50.6%   50.6%
======================================
  Files         197     197
  Lines       13567   13562    -5
  Branches     3249    3242    -7
======================================
  Hits         6869    6869
+ Misses       6336    6334    -2
+ Partials      362     359    -3

Impacted Files
Coverage Δ

light-client/src/store/sled.rs
0.0% <0.0%> (ø)

light-client/src/store/sled/utils.rs
0.0% <0.0%> (ø)

Continue to review full report at Codecov.

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


NaN value in testing

When running the testing script, I found nan values occur in the computation, thus giving all 0 output depth. What are possible reasons? Thanks

Which dataset are you evaluating? Have you modified some parameters of the script?

Both DTU and T&T. No modification

That's strange. Have you checked your pytorch version? Or maybe the dataset itself is different?

After switching to the exact pytorch version you use, it works, though not fully knowing the underlying reason. Thanks


fix(versions): update Activiti/activiti-cloud-full-chart-security versions into master

UpdateBot pushed helm dependency: activiti-cloud-full-example to: 7.1.71

UpdateBot commands:
updatebot push-version --kind helm activiti-cloud-full-example 7.1.71


Intermittent 426 Upgrade required

Hi all, I'm having a strange issue. I'm running Ambassador with Envoy, and there are intermittent 426 errors returned. I'm not quite sure what to make of it. I'm using an Azure internal load balancer, which is on a static IP.
The endpoint is /api/v1/gateway, which just returns a 200, and a JSON string. Nothing fancy.
I did see that @huxiaobabaer had a similar issue, but it was closed. Here's some requests:
ACCESS [2018-11-14T18:17:06.296Z] "GET /api/v1/gateway HTTP/1.0" 426 - 0 0 0 - "-" "-" "-" "<IP_ADDRESS>" "-"

However, tcpdump shows:
18:17:06.295890 IP <IP_ADDRESS>.24882 > ambassador-67dcc99954-g9fgg.80: Flags [P.], seq 6916:7007, ack 7905, win 1024, length 91: HTTP: GET /api/v1/gateway HTTP/1.1
18:17:06.296270 IP ambassador-67dcc99954-g9fgg.80 > <IP_ADDRESS>.24882: Flags [P.], seq 7905:8009, ack 7007, win 237, length 104: HTTP: HTTP/1.1 426 Upgrade Required

And I've started getting this in my browser as well:
18:58:17.043326 IP (tos 0x0, ttl 126, id 29750, offset 0, flags [DF], proto TCP (6), length 499)
    <IP_ADDRESS>.25999 > ambassador-67dcc99954-g9fgg.80: Flags [P.], cksum 0xbd5c (correct), seq 2920:3379, ack 2425, win 1025, length 459: HTTP, length: 459
    OPTIONS / HTTP/1.1
    Connection: Keep-Alive
    Host: <IP_ADDRESS>
    Max-Forwards: 10
    User-Agent: Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)
    Origin: example.com
    Access-Control-Request-Method: CONNECT
    X-FORWARDED-PROTO: http
    X-FORWARDED-PORT: 80
    X-ORIGINAL-HOST: 98d7d566-9097-44a3-9db2-bfd229f405bf.cloudapp.net
    X-Original-URL: /
    X-Forwarded-For: [EDITED]
    X-ARR-LOG-ID: a2b7c9d9-ed13-4603-8b4c-db638dcc3ee4

18:58:17.043706 IP (tos 0x0, ttl 64, id 64491, offset 0, flags [DF], proto TCP (6), length 144)
    ambassador-67dcc99954-g9fgg.80 > <IP_ADDRESS>.25999: Flags [P.], cksum 0x16a5 (incorrect -> 0x145d), seq 2425:2529, ack 3379, win 303, length 104: HTTP, length: 104
    HTTP/1.1 426 Upgrade Required
    date: Wed, 14 Nov 2018 18:58:16 GMT
    server: envoy
    content-length: 0

And the corresponding Envoy log:
':authority', '<IP_ADDRESS>'
':path', '/'
':method', 'OPTIONS'
'connection', 'Keep-Alive'
'max-forwards', '10'
'user-agent', 'Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)'
'origin', 'example.com'
'access-control-request-method', 'CONNECT'
'x-forwarded-proto', 'http'
'x-forwarded-port', '80'
'x-original-host', '98d7d566-9097-44a3-9db2-bfd229f405bf.cloudapp.net'
'x-original-url', '/'
'x-forwarded-for', '[EDITED]'
'x-arr-log-id', 'a2b7c9d9-ed13-4603-8b4c-db638dcc3ee4'

[2018-11-14 18:58:17.043][67][debug][http] source/common/http/conn_manager_impl.cc:984] [C67648][S2895827541538762879] encoding headers via codec (end_stream=true):
':status', '426'
'date', 'Wed, 14 Nov 2018 18:58:16 GMT'
'server', 'envoy'

The odd part is that when I restart Envoy, it behaves for a little bit. I'm running tcpdump in the same container that Envoy is running in.
Running a kubectl port-forward ... to bypass Envoy works fine. So I'm not sure where this HTTP/1.0 downgrade is coming from and I'm not sure where to go from here. Looking through the Envoy source, I only see one instance of where this response is sent.
I've attached some of the stats/logs. I couldn't run the collector - when I restart it, it's intermittent so I'm not sure how large the logs would get - it's also running in a container
Now, I know this is an older version of Envoy, I can try upgrading to the latest Ambassador EA 5, but I'm not able to do that at the moment.
Thanks for the help!
diag.txt

In my case, the HTTP/1.0 requests are health checks issued by digitaloceans loadbalancer.
We need to be able to say "OK" to these health checks, or the service will be marked as DOWN.

@daimoniac It looks like http/1.0 is supported, but it needs explicit configuration: https://github.com/envoyproxy/envoy/blob/02b2e798593ecebc48ef7c4a4f1832d5e533498d/source/common/http/conn_manager_impl.cc#L568


Add log event properties to eventhubdata

EventHub Data will always ignore LogEvent Properties, this PR will pass and allow EventHubData to use them.
LogEvent properties can contain a lot of additional information from the program and it will be usually used with Sentry or other Serilog Sinks.

Hey @Ahmad-Magdy thanks for stopping by.
Looks like this attempts to address #9.
I think would be safer if there was a way to opt-in to adding properties.
I wonder if we can take inspiration from any other sinks that have a similar behaviour implemented?
Would you be interested in designing such a feature?

Hi @adamchester
Thanks.
Sure, let me take a look into it today.

@adamchester What do you think about now?
I reused Simplify method from https://github.com/serilog/serilog-sinks-azuredocumentdb/blob/master/src/Serilog.Sinks.AzureDocumentDb/Sinks/Extensions/LogEventExtensions.cs#L102
With some modification and i have tested the changes against event hub and i think it works.

@Ahmad-Magdy sorry for the delay in replying here.
What I meant was I think there needs to be a way to allow the user of the sink to decide which properties will be added as event hub properties and which ones will be in the payload.
I wonder if we can come up with simple way to achieve that?


When Building I Get : Plumber found unhandled error:  Error: no writecb in Transform class

When trying to Build or Watch, I get the following error;
Plumber found unhandled error:
Error: no writecb in Transform class
Does anyone already fixed that? Thanks!

I'm unable to reproduce this. Could you give me the output of node -v && npm -v && npm list --depth=0 run from the Bootstrap for Vanilla root directory?

Closing as the project won't receive further updates until the release of Bootstrap 4.


fix: css url public path

Summary
fixes https://github.com/webpack/webpack/issues/16969

🤖 Generated by Copilot at 33215ce
This pull request adds a new feature to the CSS modules plugin that allows using a placeholder for the public path in the CSS source and dependencies. This enables the public path to be resolved at runtime instead of being hardcoded in the generated CSS assets. It also adds a test case to verify the functionality and refactors some code for clarity and consistency.
Details

🤖 Generated by Copilot at 33215ce

Import ReplaceSource class and getUndoPath function to enable replacing public path placeholder in CSS module source (link, link)
Obtain filename and info properties of CSS asset by calling compilation.getPathWithInfo and compute publicPath property using getUndoPath or compilation.getAssetPath (link)
Replace filenameTemplate and pathOptions properties of CSS asset with filename, info, publicPath, and modules properties (link)
Add publicPath parameter to renderContentAsset method of CssModulesPlugin class and wrap moduleSource in ReplaceSource instance to replace public path placeholder (link, link, link)
Define PUBLIC_PATH_PLACEHOLDER constant as a special string to mark public path in CSS url dependencies and use it in runtimeTemplate.assetUrl calls in CssUrlDependencyTemplate class (link, link, link, link)
Add test case to test/configCases/css/urls-css-filename/index.js to check styles in div.css (link)
Add nested.css file to test/configCases/css/urls-css-filename/ to test nested import and url handling (link)
Add webpack.config.js file to test/configCases/css/urls-css-filename/ to set up output options, CSS experiments, and split chunks optimization for test case (link)

@ahabhgk I tried different solution and I think I found. We have two problems here:

When we have an asset only in CSS module we include runtime for loading assets modules in JS bundle, but there is no asset module for loading in JS, we should fix it, I will do it in a separate PR
Your solution is not bad, we need to improve path using getUndoPath (so we need to do it late), I will finish your PR soon too

Time to finish CSS feature

A lot of tests... If you have time you can add them to your solution to ensure the idea is working

And feel free to rebase

I want to make a release on this week with this fix, so don't worry, it is not abadoned, will review in the next few days

@ahabhgk Can you rebase, thank you :star:

Thank you, will look soon and we will make a release :star:

Thank you, release will be tomorrow with a lot of fixes and features


include from field on eth_call

calling query function on a contract API is always resulting in sender being passed as 0x0 because the from field is not included in the RPC call.
If options.from is provided to firefly core, it is being passed down to evmconnect but it is not being included in the RPC call in the case where the type is query.

Codecov Report

Merging #74 (1921560) into main (2b1a0be) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main      #74   +/-   ##
=======================================
  Coverage   97.39%   97.39%
=======================================
  Files          23       23
  Lines        1422     1423    +1
=======================================
+ Hits         1385     1386    +1
  Misses         27       27
  Partials       10       10

Impacted Files
Coverage Δ

internal/ethereum/prepare_transaction.go
94.11% <100.00%> (+0.08%)
:arrow_up:

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


Transitions jumpy and out of place

Hi Ian,
Firstly, thanks for the great plugin, it's really useful!
I'm just having some issues with the transitions from div to div, my content is centered, but while it's transitioning it jumps to the left as if it has no positioning, then it jumps back to it's correct position when the animation finishes. The transitions are also erratically jumpy on and off. Is there anything I might be missing? I think I followed the instructions to the letter. Any help is appreciated, thanks!

Hi Quatlin,
Thanks for giving Multi-Screen.js a try, I hope you can get it to work for your project.
For every animation, the plugin plays with the positioning settings of the leaving and entering screens (changing the screen to show to be absolute, and the leaving screen to be fixed) which may affect the centering of your elements. How are you centering your content in each div? In the demo page of the plugin, you'll notice the content is centered as well, without any animation issues. One thing I do there in the CSS is this:
html, body {
width: 100%;
height: 100%;
}
This forces the page to always be at least the size of the screen and may issues where the body size automatically shrinks to zero because during the duration of the animation there is no "absolute" positioned content to show.
If you have some sample code to share anywhere, I would be happy to help debug.
Best,
Ian


can i use patternfly With angular 7?

PatternFly-ng is built with Angular 6 and Typescript 2.9.2, but it works with Angular 7. I have not tried it with Angular 8, but believe 8 supports Typescript 3.2, while Angular 7 supports 3.1?

@dlabrecq is it on the roadmap to update patternfly-ng to not complain about peerDependencies?

I created a PR to update the peer dependencies.
https://github.com/patternfly/patternfly-ng/pull/462
A couple caveats, tho.

PatternFly-ng is not compatible with the dropdown of ngx-bootstrap v3.3.0. Tested v3.0.0-v3.2.0 and they worked fine.

The following may also need to be added to the options of angular.json

"options": {
  "preserveSymlinks": true,

See: https://stackoverflow.com/questions/53833985/no-provider-for-viewcontainerref-while-using-ng-packagr-component


Apple Music: Fetch original file format

IMU maximises all Apple Music/iTunes covers to a PNG version. However, the source image might not be a PNG. We should add an exception to the maximisation so that we don't unnecessarily consume more bandwidth and storage for a "lossless" version of a lossy source.
For Apple Music, we should be able to determine whether the source image is a JPEG through its URL, see https://beta.musicbrainz.org/edit/81901201. However, old iTunes-style cover art URLs don't contain that filename. The only way to still get those links, AFAIK, is through the old iTunes API. However, a-tisket still uses this old iTunes API, so seeding covers from there will always lead to a PNG unless we skip maximising altogether, which doesn't seem like the right solution. I also doubt we can determine the correct Apple Music URL from an iTunes cover URL. Instead, we should let the a-tisket seeder seed the Apple Music/iTunes release URL which can get processed by the Apple Music provider to determine the Apple Music cover art URL, which then has the original filename through which we can identify the original file format.
All of that is possible, but we should be very careful with cached a-tisket pages. If we seed the release URL itself, the provider will grab the current cover art, even though the cached page may display old cover art which was replaced. So for cached pages, we should fall back to seeding the original cover art URL.
For any direct iTunes cover art links where we cannot or should not use the Apple Music release page to find the Apple Music cover art URL, we should maybe use JPEG images by default instead of PNG.

Many thanks for the detailed write-up!

Is this one extra generation of (arguably imperceptible) rounding errors acceptable?

Personally, I'm not sure. The extreme digital archivist in me says "unacceptable", but the realist says that the costs vastly outweigh the benefits. I've seen plenty of huge PNGs served by Apple, some going up to 30MB, uploading those takes quite a while even on a decent-ish connection, and takes up a lot of unnecessary storage space at the Internet Archive/Cover Art Archive. If it was a question of "original or smaller with imperceptible differences" I'd probably prefer original, but since we don't have access to the original (as far as I know), using the smaller JPEG seems like the better option if the source is also a JPEG.

Certainly, if we could get the original and avoid an extra generation entirely (lossy or lossless) that would be the ideal from a quality and storage perspective. I'm super sympathetic to Extreme Digital Archiving, but the cost of the diminished returns in these cases seem unjustifiably high. (Yet this doesn't stop my inner archivist from trying to make me feel guilty about it.)

https://github.com/qsniyg/maxurl/issues/962
Apparently someone has found a way to get the Apple source images, I checked a few albums with https://artwork.themoshcrypt.net/ and the source JPEGs (HD Source) were smaller than the blown-up 99999x0w-100.jpg JPEGs which we are currently using. Probably these are indeed the untouched original images.

URL transformation


Make monkey patch work in Python 3.6

When we initially introduced the asyncio core we started to run into segfaults. Eventually we managed to track it down to Python bug 26617. This was fixed in Python 3.5.3 and up. However, it seems that there is another bug in Python that is causing segfaults as reported in #7752.
We have not been able to track it down properly yet. We do have a hint that it is again related to GC as @AlexMekkering managed to capture the following GDB stacktrace: https://github.com/home-assistant/home-assistant/issues/7752#issuecomment-305100009 :
Thread 1 (Thread 0x76f34010 (LWP 1904)):
#0  0x76dc5298 in PyObject_GC_Del () from /usr/lib/libpython3.6m.so.1.0
#1  0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

In Python 3.6, the Task class in asyncio has been converted to C. This has the problem that we're unable to apply our monkey patch. So @bbangert came up with a way to avoid loading the C extensions so we can still apply our monkey patch.
Since this hack is very invasive, it will have to be activated via an environment variable that has to be set while running hass:
HASS_MONKEYPATCH_ASYNCIO=1 hass -c config

This should allow us to keep using the latest version of Python in our Dockerfile while we try to track down the issue.

I've opened a python bug for the 3.6 issue: https://bugs.python.org/issue31061 as I couldn't find anything related. If anyone can help with more information that would be great!


Bump version to 1.2.5.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (37cd468) 97.57% compared to head (75c5c22) 97.57%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #291   +/-   ##
=======================================
  Coverage   97.57%   97.57%
=======================================
  Files          35       35
  Lines        2265     2265
  Branches      217      217
=======================================
  Hits         2210     2210
  Misses         54       54
  Partials        1        1

Flag
Coverage Δ

unittests
97.57% <ø> (ø)

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


[asio-grpc] Update to 1.5.0

Update asio-grpc to 1.5.0

Which triplets are supported/not supported?  Closing until 1.5.1 releases.


"Link to this page" pannel lost in Publish

Hi,
When I use Minimal theme in a published vault, the "Link to this page" pannel dissapears. How can I enable again?
I tried to find it in the CSS, but I couldn't.

Sorry I am not sure I know what you mean. Can you share a screenshot of what it looks like the default theme?


Prepare Timber\PostCollections to work better with integrations

This pull request prepares Timber\PostCollection to be more versatile and possibly make it easier to integrate third party plugins into Timber that still rely heavily on the loop.
Issue
The Timber\PostsIterator class acts as the base for a default WordPress environment, because it sets the $post global when looping over an array of posts.
Sometimes other plugins rely on other globals, that are not set when using Timber\PostsIterator. WooCommerce for example relies on $product global. By making it possible to use a different Iterator class in certain circumstances, it would be easier to integrate third party plugins. Here’s how an Iterator for WooCommerce could look like:
/**
 * Class ProductsIterator
 *
 * @package Timber\Integrations\WooCommerce
 */
class ProductsIterator extends \ArrayIterator {
    /**
     * Set $product global in addition to $post global.
     *
     * For some functionality, WooCommerce works with a global named $product. When looping over multiple product posts,
     * this global is not automatically set. With this custom ArrayIterator, we can prepare the globals that are needed.
     *
     * @see \Timber\PostsIterator::current()
     *
     * @return \Timber\Post
     */
    public function current() {
        global $post, $product;

        $post = parent::current();
        $product = wc_get_product( $post->ID );

        return $post;
    }
}

The current() method sets the correct values for both $post and $product globals.
The premise here is that you always need an instance of Timber\PostsCollection for this to work. I guess that’s what the $return_collection parameter in Timber::get_posts() is used for? When set to true, it always returns a collection, and not simply an array of posts.
Solution

Move Timber\PostsIterator into a separate file to act as a basic example.
A new filter timber/class/posts_iterator that allows it to filter the default class that is used  when looping over a collection of posts.

Impact
None.
Usage Changes
No.
Considerations
The filter is now named timber/class/posts_iterator. I don’t know that the current naming convention for filters is, but I guess it’s something like timber/functionality_or_namespace/value.
So the reasoning behind this is that all filters that change classes that are used throughout the code could start with timber/class/ (maybe the Timber\PostClassMap filter would have to renamed to timber/class/post, but that’s another topic).
Make it easier to work with get_post and get_posts
Currently, Timber::get_posts() takes three parameters: $query, $PostClass and $return_collection. When working with custom iterators and classes, I don’t always want to set $PostClass when I use $return_collection. Maybe we could take the approach that WordPress uses for a lot of functionality by using an array with arguments:
// Use default query, but return a collection
$posts = Timber::get_posts( false, array( 'return_collection' => true ) );

This example would still use Timber\Post as a default for $PostClass, but I don’t have to think about setting it.
Or will get_posts() be replaced with PostQuery() in the future anyway?
Testing
No, not yet.
Todo

[ ] Decide on what naming convention to use for filters used in Timber (@jarednova)?
[ ] Write tests.
[ ] Write documentation.

Thanks @gchtr! I merged in with #1544


Error: etcdserver: member not found, after upgrading helm chart etcd replicas 1 to 3

Describe the bug
After upgrading chart with mayastor.etcd.replicaCount=3 from 1.
etcd-0 member crashloopbackoff with log:
etcd 09:39:00.03 Welcome to the Bitnami etcd container
etcd 09:39:00.03 Subscribe to project updates by watching https://github.com/bitnami/containers
etcd 09:39:00.04 Submit issues and feature requests at https://github.com/bitnami/containers/issues
etcd 09:39:00.04
etcd 09:39:00.05 INFO  ==> ** Starting etcd setup **
etcd 09:39:00.07 INFO  ==> Validating settings in ETCD_* env vars..
etcd 09:39:00.07 WARN  ==> You set the environment variable ALLOW_NONE_AUTHENTICATION=yes. For safety reasons, do not use this flag in a production environment.
etcd 09:39:00.09 INFO  ==> Initializing etcd
etcd 09:39:00.09 INFO  ==> Generating etcd config file using env variables
etcd 09:39:00.15 INFO  ==> Detected data from previous deployments
etcd 09:39:00.49 INFO  ==> Updating member in existing cluster
{"level":"warn","ts":"2024-05-16T09:39:00.595Z","logger":"etcd-client","caller":"v3@v3.5.6/retry_interceptor.go:62","msg":"retrying of unary invoker failed","target":"etcd-endpoints://0xc00037a8c0/openebs-etcd-0.openebs-etcd-headless.openebs.svc.cluster.local:2379","attempt":0,"error":"rpc error: code = NotFound desc = etcdserver: member not found"}
Error: etcdserver: member not found

other new deployed etcd members logs:
Defaulted container "etcd" out of: etcd, volume-permissions (init)
etcd 09:26:48.36
etcd 09:26:48.36 Welcome to the Bitnami etcd container
etcd 09:26:48.37 Subscribe to project updates by watching https://github.com/bitnami/containers
etcd 09:26:48.37 Submit issues and feature requests at https://github.com/bitnami/containers/issues
etcd 09:26:48.37
etcd 09:26:48.37 INFO  ==> ** Starting etcd setup **
etcd 09:26:48.39 INFO  ==> Validating settings in ETCD_* env vars..
etcd 09:26:48.39 WARN  ==> You set the environment variable ALLOW_NONE_AUTHENTICATION=yes. For safety reasons, do not use this flag in a production environment.
etcd 09:26:48.40 INFO  ==> Initializing etcd
etcd 09:26:48.40 INFO  ==> Generating etcd config file using env variables
etcd 09:26:48.45 INFO  ==> There is no data from previous deployments
etcd 09:26:48.45 INFO  ==> Bootstrapping a new cluster
etcd 09:26:48.48 INFO  ==> Obtaining cluster member ID
etcd 09:26:48.50 INFO  ==> Starting etcd in background
etcd 09:26:51.69 INFO  ==> Stored member ID: 6f5be5a5cdec82d9
etcd 09:26:51.70 INFO  ==> Stopping etcd
Terminated
etcd 09:26:52.72 INFO  ==> ** etcd setup finished! **

etcd 09:26:52.74 INFO  ==> ** Starting etcd **
{"level":"info","ts":"2024-05-16T09:26:52.780Z","caller":"flags/flag.go:113","msg":"recognized and used environment variable","variable-name":"ETCD_ADVERTISE_CLIENT_URLS","variable-value":"http://openebs-etcd-1.openebs-etcd-headless.openebs.svc.cluster.local:2379,http://openebs-etcd.openebs.svc.cluster.local:2379"}
{"level":"info","ts":"2024-05-16T09:26:52.781Z","caller":"flags/flag.go:113","msg":"recognized and used environment variable","variable-name":"ETCD_AUTH_TOKEN","variable-value":"jwt,priv-key=/opt/bitnami/etcd/certs/token/jwt-token.pem,sign-method=RS256,ttl=10m"}
{"level":"info","ts":"2024-05-16T09:26:52.781Z","caller":"flags/flag.go:113","msg":"recognized and used environment variable","variable-name":"ETCD_AUTO_COMPACTION_MODE","variable-value":"revision"}
{"level":"info","ts":"2024-05-16T09:26:52.781Z","caller":"flags/flag.go:113","msg":"recognized and used environment variable","variable-name":"ETCD_AUTO_COMPACTION_RETENTION","variable-value":"100"}
{"level":"info","ts":"2024-05-16T09:26:52.781Z","caller":"flags/flag.go:113","msg":"recognized and used environment variable","variable-name":"ETCD_AUTO_TLS","variable-value":"false"}
{"level":"info","ts":"2024-05-16T09:26:52.781Z","caller":"flags/flag.go:113","msg":"recognized and used environment variable","variable-name":"ETCD_CLIENT_CERT_AUTH","variable-value":"false"}
{"level":"info","ts":"2024-05-16T09:26:52.782Z","caller":"flags/flag.go:113","msg":"recognized and used environment variable","variable-name":"ETCD_DATA_DIR","variable-value":"/bitnami/etcd/data"}
{"level":"info","ts":"2024-05-16T09:26:52.782Z","caller":"flags/flag.go:113","msg":"recognized and used environment variable","variable-name":"ETCD_INITIAL_ADVERTISE_PEER_URLS","variable-value":"http://openebs-etcd-1.openebs-etcd-headless.openebs.svc.cluster.local:2380"}
{"level":"info","ts":"2024-05-16T09:26:52.782Z","caller":"flags/flag.go:113","msg":"recognized and used environment variable","variable-name":"ETCD_INITIAL_CLUSTER","variable-value":"openebs-etcd-0=http://openebs-etcd-0.openebs-etcd-headless.openebs.svc.cluster.local:2380,openebs-etcd-1=http://openebs-etcd-1.openebs-etcd-headless.openebs.svc.cluster.local:2380,openebs-etcd-2=http://openebs-etcd-2.openebs-etcd-headless.openebs.svc.cluster.local:2380"}
{"level":"info","ts":"2024-05-16T09:26:52.782Z","caller":"flags/flag.go:113","msg":"recognized and used environment variable","variable-name":"ETCD_INITIAL_CLUSTER_STATE","variable-value":"new"}
{"level":"info","ts":"2024-05-16T09:26:52.782Z","caller":"flags/flag.go:113","msg":"recognized and used environment variable","variable-name":"ETCD_INITIAL_CLUSTER_TOKEN","variable-value":"etcd-cluster-k8s"}
{"level":"info","ts":"2024-05-16T09:26:52.782Z","caller":"flags/flag.go:113","msg":"recognized and used environment variable","variable-name":"ETCD_LISTEN_CLIENT_URLS","variable-value":"http://<IP_ADDRESS>:2379"}
{"level":"info","ts":"2024-05-16T09:26:52.782Z","caller":"flags/flag.go:113","msg":"recognized and used environment variable","variable-name":"ETCD_LISTEN_PEER_URLS","variable-value":"http://<IP_ADDRESS>:2380"}
{"level":"info","ts":"2024-05-16T09:26:52.782Z","caller":"flags/flag.go:113","msg":"recognized and used environment variable","variable-name":"ETCD_LOG_LEVEL","variable-value":"info"}
{"level":"info","ts":"2024-05-16T09:26:52.782Z","caller":"flags/flag.go:113","msg":"recognized and used environment variable","variable-name":"ETCD_NAME","variable-value":"openebs-etcd-1"}
{"level":"info","ts":"2024-05-16T09:26:52.782Z","caller":"flags/flag.go:113","msg":"recognized and used environment variable","variable-name":"ETCD_PEER_AUTO_TLS","variable-value":"false"}
{"level":"info","ts":"2024-05-16T09:26:52.782Z","caller":"flags/flag.go:113","msg":"recognized and used environment variable","variable-name":"ETCD_QUOTA_BACKEND_BYTES","variable-value":"8589934592"}
{"level":"warn","ts":"2024-05-16T09:26:52.782Z","caller":"flags/flag.go:93","msg":"unrecognized environment variable","environment-variable":"ETCD_TRUSTED_CA_FILE="}
{"level":"warn","ts":"2024-05-16T09:26:52.783Z","caller":"flags/flag.go:93","msg":"unrecognized environment variable","environment-variable":"ETCD_DISABLE_STORE_MEMBER_ID=no"}
{"level":"warn","ts":"2024-05-16T09:26:52.783Z","caller":"flags/flag.go:93","msg":"unrecognized environment variable","environment-variable":"ETCD_CONF_FILE=/opt/bitnami/etcd/conf/etcd.yaml"}
{"level":"warn","ts":"2024-05-16T09:26:52.783Z","caller":"flags/flag.go:93","msg":"unrecognized environment variable","environment-variable":"ETCD_ON_K8S=yes"}
{"level":"warn","ts":"2024-05-16T09:26:52.783Z","caller":"flags/flag.go:93","msg":"unrecognized environment variable","environment-variable":"ETCD_SNAPSHOTS_DIR=/snapshots"}
{"level":"warn","ts":"2024-05-16T09:26:52.783Z","caller":"flags/flag.go:93","msg":"unrecognized environment variable","environment-variable":"ETCD_BIN_DIR=/opt/bitnami/etcd/bin"}
{"level":"warn","ts":"2024-05-16T09:26:52.783Z","caller":"flags/flag.go:93","msg":"unrecognized environment variable","environment-variable":"ETCD_VOLUME_DIR=/bitnami/etcd"}
{"level":"warn","ts":"2024-05-16T09:26:52.783Z","caller":"flags/flag.go:93","msg":"unrecognized environment variable","environment-variable":"ETCD_CLUSTER_DOMAIN=openebs-etcd-headless.openebs.svc.cluster.local"}
{"level":"warn","ts":"2024-05-16T09:26:52.783Z","caller":"flags/flag.go:93","msg":"unrecognized environment variable","environment-variable":"ETCD_DISASTER_RECOVERY=no"}
{"level":"warn","ts":"2024-05-16T09:26:52.783Z","caller":"flags/flag.go:93","msg":"unrecognized environment variable","environment-variable":"ETCD_KEY_FILE="}
{"level":"warn","ts":"2024-05-16T09:26:52.783Z","caller":"flags/flag.go:93","msg":"unrecognized environment variable","environment-variable":"ETCD_CONF_DIR=/opt/bitnami/etcd/conf"}
{"level":"warn","ts":"2024-05-16T09:26:52.783Z","caller":"flags/flag.go:93","msg":"unrecognized environment variable","environment-variable":"ETCD_DAEMON_GROUP=etcd"}
{"level":"warn","ts":"2024-05-16T09:26:52.783Z","caller":"flags/flag.go:93","msg":"unrecognized environment variable","environment-variable":"ETCD_START_FROM_SNAPSHOT=no"}
{"level":"warn","ts":"2024-05-16T09:26:52.783Z","caller":"flags/flag.go:93","msg":"unrecognized environment variable","environment-variable":"ETCD_INIT_SNAPSHOT_FILENAME="}
{"level":"warn","ts":"2024-05-16T09:26:52.783Z","caller":"flags/flag.go:93","msg":"unrecognized environment variable","environment-variable":"ETCD_INIT_SNAPSHOTS_DIR=/init-snapshot"}
{"level":"warn","ts":"2024-05-16T09:26:52.783Z","caller":"flags/flag.go:93","msg":"unrecognized environment variable","environment-variable":"ETCD_DISABLE_PRESTOP=no"}
{"level":"warn","ts":"2024-05-16T09:26:52.783Z","caller":"flags/flag.go:93","msg":"unrecognized environment variable","environment-variable":"ETCD_TMP_DIR=/opt/bitnami/etcd/tmp"}
{"level":"warn","ts":"2024-05-16T09:26:52.784Z","caller":"flags/flag.go:93","msg":"unrecognized environment variable","environment-variable":"ETCD_BASE_DIR=/opt/bitnami/etcd"}
{"level":"warn","ts":"2024-05-16T09:26:52.784Z","caller":"flags/flag.go:93","msg":"unrecognized environment variable","environment-variable":"ETCD_CERT_FILE="}
{"level":"warn","ts":"2024-05-16T09:26:52.784Z","caller":"flags/flag.go:93","msg":"unrecognized environment variable","environment-variable":"ETCD_NEW_MEMBERS_ENV_FILE=/bitnami/etcd/data/new_member_envs"}
{"level":"warn","ts":"2024-05-16T09:26:52.784Z","caller":"flags/flag.go:93","msg":"unrecognized environment variable","environment-variable":"ETCD_DAEMON_USER=etcd"}
{"level":"info","ts":"2024-05-16T09:26:52.784Z","caller":"etcdmain/etcd.go:73","msg":"Running: ","args":["etcd"]}
{"level":"warn","ts":"2024-05-16T09:26:52.785Z","caller":"etcdmain/etcd.go:446","msg":"found invalid file under data directory","filename":"member_id","data-dir":"/bitnami/etcd/data"}
{"level":"info","ts":"2024-05-16T09:26:52.785Z","caller":"etcdmain/etcd.go:116","msg":"server has been already initialized","data-dir":"/bitnami/etcd/data","dir-type":"member"}
{"level":"info","ts":"2024-05-16T09:26:52.785Z","caller":"embed/etcd.go:124","msg":"configuring peer listeners","listen-peer-urls":["http://<IP_ADDRESS>:2380"]}
{"level":"info","ts":"2024-05-16T09:26:52.785Z","caller":"embed/etcd.go:132","msg":"configuring client listeners","listen-client-urls":["http://<IP_ADDRESS>:2379"]}
{"level":"info","ts":"2024-05-16T09:26:52.786Z","caller":"embed/etcd.go:306","msg":"starting an etcd server","etcd-version":"3.5.6","git-sha":"cecbe35ce","go-version":"go1.16.15","go-os":"linux","go-arch":"amd64","max-cpu-set":10,"max-cpu-available":10,"member-initialized":true,"name":"openebs-etcd-1","data-dir":"/bitnami/etcd/data","wal-dir":"","wal-dir-dedicated":"","member-dir":"/bitnami/etcd/data/member","force-new-cluster":false,"heartbeat-interval":"100ms","election-timeout":"1s","initial-election-tick-advance":true,"snapshot-count":100000,"max-wals":5,"max-snapshots":5,"snapshot-catchup-entries":5000,"initial-advertise-peer-urls":["http://openebs-etcd-1.openebs-etcd-headless.openebs.svc.cluster.local:2380"],"listen-peer-urls":["http://<IP_ADDRESS>:2380"],"advertise-client-urls":["http://openebs-etcd-1.openebs-etcd-headless.openebs.svc.cluster.local:2379","http://openebs-etcd.openebs.svc.cluster.local:2379"],"listen-client-urls":["http://<IP_ADDRESS>:2379"],"listen-metrics-urls":[],"cors":["*"],"host-whitelist":["*"],"initial-cluster":"","initial-cluster-state":"new","initial-cluster-token":"","quota-backend-bytes":8589934592,"max-request-bytes":1572864,"max-concurrent-streams":4294967295,"pre-vote":true,"initial-corrupt-check":false,"corrupt-check-time-interval":"0s","compact-check-time-enabled":false,"compact-check-time-interval":"1m0s","auto-compaction-mode":"revision","auto-compaction-retention":"100ns","auto-compaction-interval":"100ns","discovery-url":"","discovery-proxy":"","downgrade-check-interval":"5s"}
{"level":"info","ts":"2024-05-16T09:26:52.789Z","caller":"etcdserver/backend.go:81","msg":"opened backend db","path":"/bitnami/etcd/data/member/snap/db","took":"229.366µs"}
{"level":"info","ts":"2024-05-16T09:26:52.789Z","caller":"etcdserver/server.go:530","msg":"No snapshot found. Recovering WAL from scratch!"}
{"level":"info","ts":"2024-05-16T09:26:52.795Z","caller":"etcdserver/raft.go:529","msg":"restarting local member","cluster-id":"f2b3b9f758cdc80","local-member-id":"6f5be5a5cdec82d9","commit-index":8}
{"level":"info","ts":"2024-05-16T09:26:52.798Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6f5be5a5cdec82d9 switched to configuration voters=()"}
{"level":"info","ts":"2024-05-16T09:26:52.798Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6f5be5a5cdec82d9 became follower at term 3"}
{"level":"info","ts":"2024-05-16T09:26:52.798Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"newRaft 6f5be5a5cdec82d9 [peers: [], term: 3, commit: 8, applied: 0, lastindex: 8, lastterm: 3]"}
{"level":"info","ts":"2024-05-16T09:26:52.827Z","caller":"mvcc/kvstore.go:393","msg":"kvstore restored","current-rev":1}
{"level":"info","ts":"2024-05-16T09:26:52.828Z","caller":"etcdserver/quota.go:117","msg":"enabled backend quota","quota-name":"v3-applier","quota-size-bytes":8589934592,"quota-size":"8.6 GB"}
{"level":"info","ts":"2024-05-16T09:26:52.828Z","caller":"etcdserver/server.go:854","msg":"starting etcd server","local-member-id":"6f5be5a5cdec82d9","local-server-version":"3.5.6","cluster-version":"to_be_decided"}
{"level":"info","ts":"2024-05-16T09:26:52.829Z","caller":"fileutil/purge.go:44","msg":"started to purge file","dir":"/bitnami/etcd/data/member/snap","suffix":"snap.db","max":5,"interval":"30s"}
{"level":"info","ts":"2024-05-16T09:26:52.829Z","caller":"fileutil/purge.go:44","msg":"started to purge file","dir":"/bitnami/etcd/data/member/snap","suffix":"snap","max":5,"interval":"30s"}
{"level":"info","ts":"2024-05-16T09:26:52.829Z","caller":"fileutil/purge.go:44","msg":"started to purge file","dir":"/bitnami/etcd/data/member/wal","suffix":"wal","max":5,"interval":"30s"}
{"level":"info","ts":"2024-05-16T09:26:52.829Z","caller":"etcdserver/server.go:754","msg":"starting initial election tick advance","election-ticks":10}
{"level":"info","ts":"2024-05-16T09:26:52.829Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6f5be5a5cdec82d9 switched to configuration voters=(8024259661377864409)"}
{"level":"info","ts":"2024-05-16T09:26:52.829Z","caller":"membership/cluster.go:421","msg":"added member","cluster-id":"f2b3b9f758cdc80","local-member-id":"6f5be5a5cdec82d9","added-peer-id":"6f5be5a5cdec82d9","added-peer-peer-urls":["http://openebs-etcd-1.openebs-etcd-headless.openebs.svc.cluster.local:2380"]}
{"level":"info","ts":"2024-05-16T09:26:52.829Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6f5be5a5cdec82d9 switched to configuration voters=(8024259661377864409<PHONE_NUMBER>994443348)"}
{"level":"info","ts":"2024-05-16T09:26:52.829Z","caller":"membership/cluster.go:421","msg":"added member","cluster-id":"f2b3b9f758cdc80","local-member-id":"6f5be5a5cdec82d9","added-peer-id":"799d284f4d21d454","added-peer-peer-urls":["http://openebs-etcd-2.openebs-etcd-headless.openebs.svc.cluster.local:2380"]}
{"level":"info","ts":"2024-05-16T09:26:52.829Z","caller":"rafthttp/peer.go:133","msg":"starting remote peer","remote-peer-id":"799d284f4d21d454"}
{"level":"info","ts":"2024-05-16T09:26:52.829Z","caller":"rafthttp/pipeline.go:72","msg":"started HTTP pipelining with remote peer","local-member-id":"6f5be5a5cdec82d9","remote-peer-id":"799d284f4d21d454"}
{"level":"info","ts":"2024-05-16T09:26:52.831Z","caller":"rafthttp/peer.go:137","msg":"started remote peer","remote-peer-id":"799d284f4d21d454"}
{"level":"info","ts":"2024-05-16T09:26:52.831Z","caller":"rafthttp/stream.go:169","msg":"started stream writer with remote peer","local-member-id":"6f5be5a5cdec82d9","remote-peer-id":"799d284f4d21d454"}
{"level":"info","ts":"2024-05-16T09:26:52.831Z","caller":"rafthttp/transport.go:317","msg":"added remote peer","local-member-id":"6f5be5a5cdec82d9","remote-peer-id":"799d284f4d21d454","remote-peer-urls":["http://openebs-etcd-2.openebs-etcd-headless.openebs.svc.cluster.local:2380"]}
{"level":"info","ts":"2024-05-16T09:26:52.831Z","caller":"rafthttp/stream.go:395","msg":"started stream reader with remote peer","stream-reader-type":"stream MsgApp v2","local-member-id":"6f5be5a5cdec82d9","remote-peer-id":"799d284f4d21d454"}
{"level":"info","ts":"2024-05-16T09:26:52.831Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6f5be5a5cdec82d9 switched to configuration voters=(8024259661377864409<PHONE_NUMBER>994443348<PHONE_NUMBER>8179729187)"}
{"level":"info","ts":"2024-05-16T09:26:52.831Z","caller":"membership/cluster.go:421","msg":"added member","cluster-id":"f2b3b9f758cdc80","local-member-id":"6f5be5a5cdec82d9","added-peer-id":"df54898d3b4a1323","added-peer-peer-urls":["http://openebs-etcd-0.openebs-etcd-headless.openebs.svc.cluster.local:2380"]}
{"level":"info","ts":"2024-05-16T09:26:52.831Z","caller":"rafthttp/peer.go:133","msg":"starting remote peer","remote-peer-id":"df54898d3b4a1323"}
{"level":"info","ts":"2024-05-16T09:26:52.831Z","caller":"rafthttp/stream.go:169","msg":"started stream writer with remote peer","local-member-id":"6f5be5a5cdec82d9","remote-peer-id":"799d284f4d21d454"}
{"level":"info","ts":"2024-05-16T09:26:52.831Z","caller":"rafthttp/pipeline.go:72","msg":"started HTTP pipelining with remote peer","local-member-id":"6f5be5a5cdec82d9","remote-peer-id":"df54898d3b4a1323"}
{"level":"info","ts":"2024-05-16T09:26:52.831Z","caller":"rafthttp/stream.go:395","msg":"started stream reader with remote peer","stream-reader-type":"stream Message","local-member-id":"6f5be5a5cdec82d9","remote-peer-id":"799d284f4d21d454"}
{"level":"info","ts":"2024-05-16T09:26:52.832Z","caller":"rafthttp/stream.go:169","msg":"started stream writer with remote peer","local-member-id":"6f5be5a5cdec82d9","remote-peer-id":"df54898d3b4a1323"}
{"level":"info","ts":"2024-05-16T09:26:52.834Z","caller":"rafthttp/stream.go:169","msg":"started stream writer with remote peer","local-member-id":"6f5be5a5cdec82d9","remote-peer-id":"df54898d3b4a1323"}
{"level":"info","ts":"2024-05-16T09:26:52.834Z","caller":"embed/etcd.go:275","msg":"now serving peer/client/metrics","local-member-id":"6f5be5a5cdec82d9","initial-advertise-peer-urls":["http://openebs-etcd-1.openebs-etcd-headless.openebs.svc.cluster.local:2380"],"listen-peer-urls":["http://<IP_ADDRESS>:2380"],"advertise-client-urls":["http://openebs-etcd-1.openebs-etcd-headless.openebs.svc.cluster.local:2379","http://openebs-etcd.openebs.svc.cluster.local:2379"],"listen-client-urls":["http://<IP_ADDRESS>:2379"],"listen-metrics-urls":[]}
{"level":"info","ts":"2024-05-16T09:26:52.835Z","caller":"embed/etcd.go:586","msg":"serving peer traffic","address":"[::]:2380"}
{"level":"info","ts":"2024-05-16T09:26:52.835Z","caller":"embed/etcd.go:558","msg":"cmux::serve","address":"[::]:2380"}
{"level":"info","ts":"2024-05-16T09:26:52.836Z","caller":"rafthttp/peer_status.go:53","msg":"peer became active","peer-id":"799d284f4d21d454"}
{"level":"info","ts":"2024-05-16T09:26:52.836Z","caller":"rafthttp/stream.go:412","msg":"established TCP streaming connection with remote peer","stream-reader-type":"stream MsgApp v2","local-member-id":"6f5be5a5cdec82d9","remote-peer-id":"799d284f4d21d454"}
{"level":"info","ts":"2024-05-16T09:26:52.836Z","caller":"rafthttp/peer.go:137","msg":"started remote peer","remote-peer-id":"df54898d3b4a1323"}
{"level":"info","ts":"2024-05-16T09:26:52.836Z","caller":"rafthttp/transport.go:317","msg":"added remote peer","local-member-id":"6f5be5a5cdec82d9","remote-peer-id":"df54898d3b4a1323","remote-peer-urls":["http://openebs-etcd-0.openebs-etcd-headless.openebs.svc.cluster.local:2380"]}
{"level":"info","ts":"2024-05-16T09:26:52.836Z","caller":"membership/cluster.go:584","msg":"set initial cluster version","cluster-id":"f2b3b9f758cdc80","local-member-id":"6f5be5a5cdec82d9","cluster-version":"3.5"}
{"level":"info","ts":"2024-05-16T09:26:52.836Z","caller":"api/capability.go:75","msg":"enabled capabilities for version","cluster-version":"3.5"}
{"level":"info","ts":"2024-05-16T09:26:52.836Z","caller":"rafthttp/stream.go:395","msg":"started stream reader with remote peer","stream-reader-type":"stream MsgApp v2","local-member-id":"6f5be5a5cdec82d9","remote-peer-id":"df54898d3b4a1323"}
{"level":"info","ts":"2024-05-16T09:26:52.837Z","caller":"rafthttp/stream.go:249","msg":"set message encoder","from":"6f5be5a5cdec82d9","to":"799d284f4d21d454","stream-type":"stream Message"}
{"level":"info","ts":"2024-05-16T09:26:52.837Z","caller":"rafthttp/stream.go:274","msg":"established TCP streaming connection with remote peer","stream-writer-type":"stream Message","local-member-id":"6f5be5a5cdec82d9","remote-peer-id":"799d284f4d21d454"}
{"level":"info","ts":"2024-05-16T09:26:52.837Z","caller":"rafthttp/stream.go:395","msg":"started stream reader with remote peer","stream-reader-type":"stream Message","local-member-id":"6f5be5a5cdec82d9","remote-peer-id":"df54898d3b4a1323"}
{"level":"info","ts":"2024-05-16T09:26:52.837Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"raft.node: 6f5be5a5cdec82d9 elected leader 799d284f4d21d454 at term 3"}
{"level":"info","ts":"2024-05-16T09:26:52.837Z","caller":"rafthttp/stream.go:249","msg":"set message encoder","from":"6f5be5a5cdec82d9","to":"799d284f4d21d454","stream-type":"stream MsgApp v2"}
{"level":"info","ts":"2024-05-16T09:26:52.837Z","caller":"rafthttp/stream.go:274","msg":"established TCP streaming connection with remote peer","stream-writer-type":"stream MsgApp v2","local-member-id":"6f5be5a5cdec82d9","remote-peer-id":"799d284f4d21d454"}
{"level":"info","ts":"2024-05-16T09:26:52.839Z","caller":"rafthttp/stream.go:412","msg":"established TCP streaming connection with remote peer","stream-reader-type":"stream Message","local-member-id":"6f5be5a5cdec82d9","remote-peer-id":"799d284f4d21d454"}
{"level":"warn","ts":"2024-05-16T09:26:52.841Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"info","ts":"2024-05-16T09:26:52.842Z","caller":"embed/serve.go:100","msg":"ready to serve client requests"}
{"level":"warn","ts":"2024-05-16T09:26:52.842Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"info","ts":"2024-05-16T09:26:52.842Z","caller":"etcdserver/server.go:2054","msg":"published local member to cluster through raft","local-member-id":"6f5be5a5cdec82d9","local-member-attributes":"{Name:openebs-etcd-1 ClientURLs:[http://openebs-etcd-1.openebs-etcd-headless.openebs.svc.cluster.local:2379 http://openebs-etcd.openebs.svc.cluster.local:2379]}","request-path":"/0/members/6f5be5a5cdec82d9/attributes","cluster-id":"f2b3b9f758cdc80","publish-timeout":"7s"}
{"level":"info","ts":"2024-05-16T09:26:52.842Z","caller":"etcdmain/main.go:44","msg":"notifying init daemon"}
{"level":"info","ts":"2024-05-16T09:26:52.842Z","caller":"etcdmain/main.go:50","msg":"successfully notified init daemon"}
{"level":"info","ts":"2024-05-16T09:26:52.844Z","caller":"embed/serve.go:146","msg":"serving client traffic insecurely; this is strongly discouraged!","address":"[::]:2379"}
{"level":"warn","ts":"2024-05-16T09:26:52.845Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:52.845Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:52.948Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:52.949Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:53.045Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:53.045Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:53.149Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:53.154Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:53.251Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:53.251Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:53.347Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:53.348Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:53.450Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:53.458Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:53.546Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:53.547Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:53.648Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:53.649Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:53.757Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:53.761Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:53.851Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:53.851Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:53.947Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:53.948Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:54.049Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:54.050Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"info","ts":"2024-05-16T09:26:54.057Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6f5be5a5cdec82d9 [term 3] received MsgTimeoutNow from 799d284f4d21d454 and starts an election to get leadership."}
{"level":"info","ts":"2024-05-16T09:26:54.057Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6f5be5a5cdec82d9 is starting a new election at term 3"}
{"level":"info","ts":"2024-05-16T09:26:54.057Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6f5be5a5cdec82d9 became candidate at term 4"}
{"level":"info","ts":"2024-05-16T09:26:54.057Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6f5be5a5cdec82d9 received MsgVoteResp from 6f5be5a5cdec82d9 at term 4"}
{"level":"info","ts":"2024-05-16T09:26:54.057Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6f5be5a5cdec82d9 [logterm: 3, index: 9] sent MsgVote request to 799d284f4d21d454 at term 4"}
{"level":"info","ts":"2024-05-16T09:26:54.057Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6f5be5a5cdec82d9 [logterm: 3, index: 9] sent MsgVote request to df54898d3b4a1323 at term 4"}
{"level":"info","ts":"2024-05-16T09:26:54.057Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"raft.node: 6f5be5a5cdec82d9 lost leader 799d284f4d21d454 at term 4"}
{"level":"info","ts":"2024-05-16T09:26:54.063Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6f5be5a5cdec82d9 received MsgVoteResp from 799d284f4d21d454 at term 4"}
{"level":"info","ts":"2024-05-16T09:26:54.063Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6f5be5a5cdec82d9 has received 2 MsgVoteResp votes and 0 vote rejections"}
{"level":"info","ts":"2024-05-16T09:26:54.063Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6f5be5a5cdec82d9 became leader at term 4"}
{"level":"info","ts":"2024-05-16T09:26:54.063Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"raft.node: 6f5be5a5cdec82d9 elected leader 6f5be5a5cdec82d9 at term 4"}
{"level":"error","ts":"2024-05-16T09:26:54.067Z","caller":"rafthttp/util.go:99","msg":"request sent was ignored due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-cluster-id":"f2b3b9f758cdc80","stacktrace":"go.etcd.io/etcd/server/v3/etcdserver/api/rafthttp.checkPostResponse\n\tgo.etcd.io/etcd/server/v3/etcdserver/api/rafthttp/util.go:99\ngo.etcd.io/etcd/server/v3/etcdserver/api/rafthttp.(*pipeline).post\n\tgo.etcd.io/etcd/server/v3/etcdserver/api/rafthttp/pipeline.go:163\ngo.etcd.io/etcd/server/v3/etcdserver/api/rafthttp.(*pipeline).handle\n\tgo.etcd.io/etcd/server/v3/etcdserver/api/rafthttp/pipeline.go:100"}
{"level":"error","ts":"2024-05-16T09:26:54.077Z","caller":"rafthttp/util.go:99","msg":"request sent was ignored due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-cluster-id":"f2b3b9f758cdc80","stacktrace":"go.etcd.io/etcd/server/v3/etcdserver/api/rafthttp.checkPostResponse\n\tgo.etcd.io/etcd/server/v3/etcdserver/api/rafthttp/util.go:99\ngo.etcd.io/etcd/server/v3/etcdserver/api/rafthttp.(*pipeline).post\n\tgo.etcd.io/etcd/server/v3/etcdserver/api/rafthttp/pipeline.go:163\ngo.etcd.io/etcd/server/v3/etcdserver/api/rafthttp.(*pipeline).handle\n\tgo.etcd.io/etcd/server/v3/etcdserver/api/rafthttp/pipeline.go:100"}
{"level":"error","ts":"2024-05-16T09:26:54.103Z","caller":"rafthttp/util.go:99","msg":"request sent was ignored due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-cluster-id":"f2b3b9f758cdc80","stacktrace":"go.etcd.io/etcd/server/v3/etcdserver/api/rafthttp.checkPostResponse\n\tgo.etcd.io/etcd/server/v3/etcdserver/api/rafthttp/util.go:99\ngo.etcd.io/etcd/server/v3/etcdserver/api/rafthttp.(*pipeline).post\n\tgo.etcd.io/etcd/server/v3/etcdserver/api/rafthttp/pipeline.go:163\ngo.etcd.io/etcd/server/v3/etcdserver/api/rafthttp.(*pipeline).handle\n\tgo.etcd.io/etcd/server/v3/etcdserver/api/rafthttp/pipeline.go:100"}
{"level":"warn","ts":"2024-05-16T09:26:54.146Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:54.150Z","caller":"rafthttp/stream.go:653","msg":"request sent was ignored by remote peer due to cluster ID mismatch","remote-peer-id":"df54898d3b4a1323","remote-peer-cluster-id":"cc6a2769e8595d1d","local-member-id":"6f5be5a5cdec82d9","local-member-cluster-id":"f2b3b9f758cdc80","error":"cluster ID mismatch"}
{"level":"warn","ts":"2024-05-16T09:26:54.162Z","caller":"rafthttp/stream.go:421","msg":"lost TCP streaming connection with remote peer","stream-reader-type":"stream MsgApp v2","local-member-id":"6f5be5a5cdec82d9","remote-peer-id":"799d284f4d21d454","error":"EOF"}
{"level":"warn","ts":"2024-05-16T09:26:54.166Z","caller":"rafthttp/stream.go:421","msg":"lost TCP streaming connection with remote peer","stream-reader-type":"stream Message","local-member-id":"6f5be5a5cdec82d9","remote-peer-id":"799d284f4d21d454","error":"EOF"}
...
{"level":"warn","ts":"2024-05-16T09:45:46.015Z","caller":"etcdserver/cluster_util.go:288","msg":"failed to reach the peer URL","address":"http://openebs-etcd-0.openebs-etcd-headless.openebs.svc.cluster.local:2380/version","remote-member-id":"df54898d3b4a1323","error":"Get \"http://openebs-etcd-0.openebs-etcd-headless.openebs.svc.cluster.local:2380/version\": dial tcp <IP_ADDRESS>:2380: connect: connection refused"}
{"level":"warn","ts":"2024-05-16T09:45:46.015Z","caller":"etcdserver/cluster_util.go:155","msg":"failed to get version","remote-member-id":"df54898d3b4a1323","error":"Get \"http://openebs-etcd-0.openebs-etcd-headless.openebs.svc.cluster.local:2380/version\": dial tcp <IP_ADDRESS>:2380: connect: connection refused"}
{"level":"warn","ts":"2024-05-16T09:45:48.208Z","caller":"rafthttp/probing_status.go:68","msg":"prober detected unhealthy status","round-tripper-name":"ROUND_TRIPPER_SNAPSHOT","remote-peer-id":"df54898d3b4a1323","rtt":"3.654257ms","error":"dial tcp <IP_ADDRESS>:2380: connect: connection refused"}
{"level":"warn","ts":"2024-05-16T09:45:48.224Z","caller":"rafthttp/probing_status.go:68","msg":"prober detected unhealthy status","round-tripper-name":"ROUND_TRIPPER_RAFT_MESSAGE","remote-peer-id":"df54898d3b4a1323","rtt":"8.09826ms","error":"dial tcp <IP_ADDRESS>:2380: connect: connection refused"}
{"level":"warn","ts":"2024-05-16T09:45:50.022Z","caller":"etcdserver/cluster_util.go:288","msg":"failed to reach the peer URL","address":"http://openebs-etcd-0.openebs-etcd-headless.openebs.svc.cluster.local:2380/version","remote-member-id":"df54898d3b4a1323","error":"Get \"http://openebs-etcd-0.openebs-etcd-headless.openebs.svc.cluster.local:2380/version\": dial tcp <IP_ADDRESS>:2380: connect: connection refused"}
{"level":"warn","ts":"2024-05-16T09:45:50.022Z","caller":"etcdserver/cluster_util.go:155","msg":"failed to get version","remote-member-id":"df54898d3b4a1323","error":"Get \"http://openebs-etcd-0.openebs-etcd-headless.openebs.svc.cluster.local:2380/version\": dial tcp <IP_ADDRESS>:2380: connect: connection refused"}

Current helm values:
release:
  version: "4.0.1"
mayastor:
  enabled: true
  etcd:
    replicaCount: 3

Previous helm values:
release:
  version: "4.0.1"
mayastor:
  enabled: true
  etcd:
    replicaCount: 1

To Reproduce

install openebs helm with mayastor etcd replica 1
upgrade chart with etcd replica 3

Expected behavior
all etcd members are healthy
Screenshots
If applicable, add screenshots to help explain your problem.
OS info (please complete the following information):
openebs.io/version: 2.6.1
Additional context
Add any other context about the problem here.

did also a test scalling to 2 replicas, in that case etcd-0 was healthy but etcd-1 show errors:
k logs -n openebs openebs-etcd-1
Defaulted container "etcd" out of: etcd, volume-permissions (init)
etcd 10:38:13.72
etcd 10:38:13.72 Welcome to the Bitnami etcd container
etcd 10:38:13.72 Subscribe to project updates by watching https://github.com/bitnami/containers
etcd 10:38:13.72 Submit issues and feature requests at https://github.com/bitnami/containers/issues
etcd 10:38:13.72
etcd 10:38:13.72 INFO  ==> ** Starting etcd setup **
etcd 10:38:13.76 INFO  ==> Validating settings in ETCD_* env vars..
etcd 10:38:13.77 WARN  ==> You set the environment variable ALLOW_NONE_AUTHENTICATION=yes. For safety reasons, do not use this flag in a production environment.
etcd 10:38:13.78 INFO  ==> Initializing etcd
etcd 10:38:13.78 INFO  ==> Generating etcd config file using env variables
etcd 10:38:13.81 INFO  ==> Detected data from previous deployments
etcd 10:38:14.00 INFO  ==> Updating member in existing cluster
{"level":"warn","ts":"2024-05-16T10:38:14.099Z","logger":"etcd-client","caller":"v3@v3.5.6/retry_interceptor.go:62","msg":"retrying of unary invoker failed","target":"etcd-endpoints://0xc0000e6a80/openebs-etcd-0.openebs-etcd-headless.openebs.svc.cluster.local:2379","attempt":0,"error":"rpc error: code = NotFound desc = etcdserver: member not found"}
Error: etcdserver: member not found

Also after 1st case when I rollback from 3 to 1 replica for etcd. etcd-0 lost its all data. Fortunately I made a snapshot of etcd before and restored it.
In 2nd case etcd-0 when scalling from 1 to 2 and rollback from 2 to 1. etcd-0 was healthy entire time so data was kept.

I haven't had the time yet, but I wonder if the etcd-operator would help here? https://github.com/openebs/mayastor/issues/1630


fix(vscode): read telemetryLevel too, to decide if telemetry should be enabled

Closes https://github.com/prisma/language-tools/issues/1463

Nice, thanks for the swift fix!

Note that the telemetry is always off due to a bug in this PR, fix is in https://github.com/prisma/language-tools/pull/1470


Using cursor on main menu

What is your question?
I wanted to make it so you can use your mouse cursor instead of the directional buttons to click things on the main menu. How can I do this?


MINOR: Wait for tasks to terminate to avoid exception in test teardown

Fix for the failure of tearDown after kafka.api.ConsumerBounceTest.testCloseDuringRebalance  in https://builds.apache.org/job/kafka-trunk-jdk8/1780/:
java.util.ConcurrentModificationException: KafkaConsumer is not safe for multi-threaded access
	at org.apache.kafka.clients.consumer.KafkaConsumer.acquire(KafkaConsumer.java:1691)
	at org.apache.kafka.clients.consumer.KafkaConsumer.close(KafkaConsumer.java:1585)
	at org.apache.kafka.clients.consumer.KafkaConsumer.close(KafkaConsumer.java:1565)
	at kafka.api.IntegrationTestHarness.$anonfun$tearDown$2(IntegrationTestHarness.scala:99)
	at kafka.api.IntegrationTestHarness.$anonfun$tearDown$2$adapted(IntegrationTestHarness.scala:99)

@hachikuji Can you review, please? Thank you...

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/5877/
Test PASSed (JDK 8 and Scala 2.12).

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.11/5892/
Test PASSed (JDK 7 and Scala 2.11).

@ijuma Thank you for the review. I will merge it since it occasionally causes test failures. If @hachikuji has any suggestions, I will do it as a separate PR.


Cache system implement

Changes:
/ Implemented a cache system to reduce resource usage
/ Ensure IP is formatted as well in conversions

All right, ASAP.


Transaction: make Sign(key,coin) overloads stop using params keyword

Having the params keyword meant that it was easy to shoot
yourself in the foot, as a newbie, by not providing any
element of the array at all, which would end up not signing
the transaction at all without throwing any exception (silent
failing). See discussion in:
https://github.com/MetacoSA/NBitcoin/pull/260
Also provide two new overloads for non-array variables, though
(this is harmless, as opposed to params keyword, because
we make sure at least there's one element provided).
As this is an API breaking change, version is bumped to 5.0.

No need to bump to 5.0.
Changing this code will break no existing code.
There is no reason that anyone was using Sign(keys, c1,c 2), except for testing stuff.

Even if you believe a specific API doesn't have any consumers, bumping version is always the right thing to do when breaking it.
How about 4.1? Although according to http://semver.org/ , an API break should always pose a major version change actually.

I think "every breaking change requires major version update" is overkill, I keep major version when there is really a big change that is likely to impact people (last version bump was BitconAddress not depending on Base58Data)

Ok then I change to 4.1?

Just to <IP_ADDRESS>

Fair enough. Updated.


Documentation on the security aspects with abapGit

Can we have a brief documentation on the security aspects which one needs to be aware of before starting with abapGit and also any guidelines or best practices that can be followed in the same context. This can help out in clearing the security concerns, if any, related to the usage of abapGit.

we have https://docs.abapgit.org/#security, but I'll add a bit more, and move it to a separate page


WS281x led device fails to start with "Device '' was not ready! Trying to re-open."

The changes from #654 have unfortunately broken the WS281x Led Device (and presumably other led devices, although I haven't tested any others). On attempting to start hyperion, I see the following messages in the log:

[hyperiond LEDDEVICE] (DEBUG) (LedDevice.cpp:68:setEnable()) Device '' was not ready! Trying to re-open.
[hyperiond LEDDEVICE] (DEBUG) (LedDevice.cpp:68:setEnable()) Previous line repeats 200 times

The _deviceReady flag is set in the LedDevice::start function, which calls LedDevice::open and sets the flag depending on the result. However, in the LedDevice::open function, LedDevice::setEnable is called, which checks _deviceReady and throws an error if it isn't. This will always fail because _deviceReady hasn't be set to true until LedDevice::open returns.
In a related note, if _deviceReady is false when LedDevice::setEnable is called, LedDevice::open is called again (which in turn calls LedDevice::setEnable and so on and so forth).
I agree with the type of check that was intended here, but the logic needs some tweaks.

@mharring Thanks for the feedback. I will have a look and come back to you.

@mharring Seems I found the problem. The open() method for the  WS281x device was not invoked. I think, I fixed the problem.
The device is now recognised and goes now correctly in error in my environment.
Would you do me the favour testing the changes before I will publish them widely?
I included some additional Debug statements just to trace the initialization part.
It would be good, if you could run hyperiond in Debug mode and share the output with me afterwards.
Many thanks in advance for your support!
The updated files you find here 20200213_ws281x-fix.tar.
Just put the tar file in the hyperion home directory and extract the files via
tar -xvf 20200213_ws281x-fix.tar
Now compile as before and start hyperiond.

Thanks for taking a look. I'm not sure when I'll have time to rebuild but I'll give it a shot when I can.
Open was being called on the master branch by the start function when the led device thread was created (see start function in LedDevice.h).

@TheAndi You are welcome to test the fix, too.

It's compiling, I'll let you know soon

Ok, I gave it a test. The ws281x device does work now and the smoothing can be disabled.
One note to that: The activation state of the smoothing is still not properly synced between the control panel and the activate checkbox of the smoothing settings.
Furthermore, I noticed that the LED output stops when global smoothing is turned on and a Effekt is selected. Unfortunately there is no error in the logs.
A quick disable/reanable of smoothing or led device however makes the effect show as intended.
Let me know how if I can provide more info.

And one more thing, when smoothing is disabled I get random flicker in my led strips. Especially noticeable with the breath effect. Even a little smoothing of 25ms solves it.
I'm not sure if it's the same flickr I mentioned in https://github.com/hyperion-project/hyperion.ng/issues/641 (here I thought it's the SPI driving method)

One note to that: The activation state of the smoothing is still not properly synced between the control panel and the activate checkbox of the smoothing settings.

I captured a separate issue #680.

Furthermore, I noticed that the LED output stops when global smoothing is turned on and a Effekt is selected. Unfortunately there is no error in the logs.
A quick disable/re-enable of smoothing or led device however makes the effect show as intended.

Would you mind outlining the steps you executed for the test?
What is your expectation?
Currently the effect starts immediately after the last standard write. There is no smooth transition between output and effect .

And one more thing, when smoothing is disabled I get random flicker in my led strips. Especially noticeable with the breath effect. Even a little smoothing of 25ms solves it.

I tested with the "file" LedDevice which outputs the LED RGB values written.
I ran a Colour Effect with pure red and there were not any differences in the output records over the whole time.
I would assume it is a hardware setup/configuration problem, not a software one.

Would you mind outlining the steps you executed for the test?
What is your expectation?
Currently the effect starts immediately after the last standard write. There is no smooth transition between output and effect .

Sure here's my commented log
[hyperiond ComponentRegister] <DEBUG> <ComponentRegister.cpp:67:componentStateChanged()> Smoothing: enabled
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:250:clearInput()> Removed source priority 1
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:333:setCurrentTime()> Set visible priority to 254
[hyperiond EFFECTENGINE] <INFO> effect finished
[hyperiond EFFECTENGINE] <INFO> Run effect "Atomic swirl" on channel 1
[hyperiond EFFECTENGINE] <DEBUG> <EffectEngine.cpp:183:runEffectScript()> Start the effect: name [Atomic swirl], smoothCfg [2]
--effect not showing--
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:153:registerInput()> Register new input 'Web Configuration@::ffff:<IP_ADDRESS>/EFFECT' with priority 1 as inactive
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:233:setInputImage()> Priority 1 is now active
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:333:setCurrentTime()> Set visible priority to 1
[hyperiond ComponentRegister] <DEBUG> <ComponentRegister.cpp:67:componentStateChanged()> LED device: disabled
[hyperiond ComponentRegister] <DEBUG> <ComponentRegister.cpp:67:componentStateChanged()> LED device: enabled
--"Atomic swirl"  shows up--
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:250:clearInput()> Removed source priority 1
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:333:setCurrentTime()> Set visible priority to 254
[hyperiond EFFECTENGINE] <INFO> effect finished
[hyperiond EFFECTENGINE] <INFO> Run effect "Breath" on channel 1
[hyperiond EFFECTENGINE] <DEBUG> <EffectEngine.cpp:183:runEffectScript()> Start the effect: name [Breath], smoothCfg [2]
--effect not showing--
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:153:registerInput()> Register new input 'Web Configuration@::ffff:<IP_ADDRESS>/EFFECT' with priority 1 as inactive
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:193:setInput()> Priority 1 is now active
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:333:setCurrentTime()> Set visible priority to 1
[hyperiond ComponentRegister] <DEBUG> <ComponentRegister.cpp:67:componentStateChanged()> Smoothing: disabled
[hyperiond ComponentRegister] <DEBUG> <ComponentRegister.cpp:67:componentStateChanged()> Smoothing: enabled
--"Breath" shwoing up--
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:250:clearInput()> Removed source priority 1
[hyperiond HYPERION] <DEBUG> <PriorityMuxer.cpp:333:setCurrentTime()> Set visible priority to 254
[hyperiond EFFECTENGINE] <INFO> effect finished

When I remember correctly every time the effect was "not showing" hyperion wen't back to my background color and wasn't showing any more inputs (also no single colors) until either smooth or led device was toggled.

I tested with the "file" LedDevice which outputs the LED RGB values written.
I ran a Colour Effect with pure red and there were not any differences in the output records over the whole time.
I would assume it is a hardware setup/configuration problem, not a software one.

I am running my strip setup for many years now (with old Hyperion and Pi3) without any flicker, so I would say my hardware is fine. Furthermore, with smoothing enabled, there is no more flicker.
Flicker was first seen when I switched to Hyperion.ng and a Pi1 B+.
Could it be that some effects are updating the LEDs even faster than the 60Hz of the enabled smoothing and are therefore overloading my Pi1 when not "framelimeted" by the smoothing algorithm?


[Bot] Exact match not returned unless $ used in command

Had this conversation with the DocDex bot recently:

It would be ideal if, given a limit of n, when an exact match is found to build an embed around that instead of returning the same query in a list of suggestions - giving the bot a limit, I had thought, would cause it to create several paginated embeds with the first result first, but even if this is not the case when an exact match is found but a limit other than 'first' is given, the error should probably not say that no match was found 😄

The bug is a legitimate bug, I'll look into that, but the suggestion is the same as #18.

The bug is a legitimate bug, I'll look into that, but the suggestion is the same as #18.


task1

Issue: #2
Kali Linux installed successfully

Hey @AdityaKishore29
Thanks for opening this PR 🚀. Mentor will review your pull request soon and till then, keep contributing and stay calm.
Thanks for contributing in OpenCode'24 ✨✨!

Hey @AdityaKishore29
Your PR has been merged 🥳🥳 and you have earned 20 points.
Thanks for contributing in OpenCode'24 ✨✨


unable to run the nats-pub/sub go program

trying to run the examples nats-pub and nats-sub, had this error
nats-pub.go:20:3: found packages bench (main.go) and main (nats-pub.go) in C:\go-work\src\github.com\nats-io\go-nats
please help me, i think it has something to do with the GOPATH.

Might be easier to go get the examples, you could try:
cd $GOPATH
go get github.com/nats-io/go-nats/examples/nats-pub
go get github.com/nats-io/go-nats/examples/nats-sub
$GOPATH/bin/nats-pub
$GOPATH/bin/nats-sub

I'm working on windows and i got this error when i tried to use go get:
package github.com/nats-io/go-nats/examples/nats-pub: cannot download, C:\go-work is a GOROOT, not a GOPATH. For more details see: 'go help gopath'
PS: GOROOT is in C:/Go not in C:/go-work

Changed the path i got another error:
C:\tools\Go projects>go get github.com/nats-io/nats-top
cd .; git clone https://github.com/nats-io/nats-top C:\tools\Go projects\src\github.com\nats-io\nats-top
Cloning into 'C:\tools\Go projects\src\github.com\nats-io\nats-top'...
fatal: Invalid path '/cygdrive/c/tools/Go projects/C:\tools\Go projects\src\github.com\nats-io\nats-top': No such file or directory
package github.com/nats-io/nats-top: exit status 128

Looks like you are using cygwin? Maybe you might be running into this issue? => https://github.com/golang/go/issues/23155#issuecomment-355558176


chore(release): change release cadence

@mason-org/triage
 🤖 This is an automated comment.    📖 Source code


Add formatting guidelines to CONTRIBUTING.md

Fixes #97

Content LGTM - I'll repeat my earlier question, I think it got missed:

Curious question - #97 does mention a .editorconfig but we don't have an .editorconfig , even though this is closing that ticket.
Should we have a .editorconfig?

@markmandel Since opening the issue, I have realized gofmt does what .editorconfig hopes to do. So, I think we're good without it.


More elaborate explanation for google search engine

As per #11, here's a more elaborate README for google search setup

Thank you for this @thanpolas


Porting to objective-c

I'm thinking to port the ActiveLabel into objective-c in case if anyone needs it without bridging objc/swift. Do you guys its worth to do this? I'd like to hear any advices!

and also distributing it through cocoapods would be great.

#20 dupe


[ALLUXIO-2433] Permissive startup check consistency

https://alluxio.atlassian.net/browse/ALLUXIO-2433

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/12336/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/12352/
Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/12353/
Test PASSed.

Merged build finished. Test PASSed.


handling missing values

Having the default in the Yaml as True will change some tables in the test.ipynb and also some tests in the test_initial.py will fail because the summary will be (review; missing values found) instead of for example (fail; threshold: 6 cells suppressed; p-ratio: 1 cells suppressed). This is because the dataset has a lot of missing values (4946). That is why we thought to have the checking for missing value as False as a default and if the TRE really want to check for it then change it to True.

OK, keeping it False makes sense. Still need a test though?

You can try adding utils to the import at the end of this line:
https://github.com/AI-SDC/ACRO/blob/f2e57baa998365d56a17fba7fc7459f8a3e5b050/test/test_initial.py#L9
and then setting the value at the start of the test function:
https://github.com/AI-SDC/ACRO/blob/ca5ca652888ef728477c36fe52cc404ec1d4ebea/test/test_initial.py#L292
utils.CHECK_MISSING_VALUES = True
For some reason my system is throwing up loads of json decode errors when I try to run the tests locally, but that's probably something wrong on my end because the CI seems to be running fine...

@rpreen

do we want to actually suppress the missing cells or leave them like for negative values?
I think that is a really good question and one to ask the TREs / WP1 people.
For now, I am content to have the functionality in there as a (non default) option and let them decide. May be on a case by case basis.

We don't currently provide an option for negatives; the cells are flagged in the outcome and the summary is set to "review" but no cells are actually suppressed.
So do we want to make this PR for missing values the same as that and then have a new PR which makes it an option for both? If so, then this PR needs to modify apply_suppression() to make it handle missing values the same as negatives?


Isolating private data from coordinator

I did not try the project myself, but I noticed in the code methods to send the mnemonic to the coordinator device.
I think it would be a good idea to change the workflow and remove these methods to avoid leaking any of wallet's private data to the coordinator, the PC/browser. Leaking the mnemonic to the device defeats one of the purposes of hardware wallets, which is to keep private data out of reach of the coordinator.

The communication between the browser and the hardware device is encrypted.
How would you restore the mnemonic on the device if there are not methods to do so?