text:
[BUG] Parallel Provisioning of Harvester VMs Sees Each VM Get The Same IPV4

Describe the bug
Given the scenario of a user has:

3 separate terraform projects
3 separate respective state files
3 separate VMs w/ NICs, etc.
Each NIC on each VM is assigned a unique MAC Address

User opens 3 separate terminals.
User fires off:
TF_LOG=TRACE terraform apply -var-file="env/local.tfvars" -auto-approve

All VMs come up online with the same IPv4 address.
To Reproduce
Steps to reproduce the behavior:

Build 3 different small terraform projects, w/ 3 corresponding state files, for 3 separate VMs ( each having a NIC that has a different MAC address )
Run TF Apply
All VMs come up online with the same IPv4 address

Expected behavior
To have parallel provisioning of resources in Harvester, the VMs that get created, not encounter issues where each VM's IP Address is the same as the next.
Environment

Harvester ISO version: v1.2.1
Underlying Infrastructure: HP-DL360

Additional context

What's the UUID of each created VM? Please check the output of command dmidecode -t system | grep UUID on each VM.

Could you run systemctl status systemd-networkd on 3 VMs? It will show timestamp information and I wondering if they directly issue DHCPREQUEST at the same time w/o DHCPDISCOVER phase.

I'm pretty sure that's sort of what's happening - I was trying a few workarounds with something like in the cloud-init something like:
      bootcmd:
        - /usr/bin/sleep $(/usr/bin/shuf -i 1-100 -n 1)

But realized the cloud-img I'm leveraging doesn't by default have the  shuf from GNU core-utils  - so I'd need to rebuild the cloud-img with that baked in.
Additionally, thinking something like a rc.local file could be implemented:
#!/bin/sh
# add your commands
# call your scripts here

/usr/bin/sleep $(/usr/bin/shuf -i 1-100 -n 1)
/usr/sbin/ip link set enp1s0 up
/usr/sbin/dhclient -v enp1s0
# last line must be exit 0
exit 0

A VM still with 5 others provisioning at the same time, they do have a non-zero chance of hitting the "same" random number on sleeping... I guess the thought would be is creating that space of time would allow for some VMs to come up, making the DHCP calls before others do...
But perhaps a time gap can be created in provisioning them like:
VM1: 0 Min Delay
VM2: 3 Min Delay
VM3: 6 Min Delay
VM4: 9 Min Delay
VM5: 12 Min Delay
VM6: 15 Min Delay
versus trying to stand all of them up at once.
@mingshuoqiu  do you have any suggestions to handling multiple VMs trying to issue the same DHCP calls at the same time?  Are there some built in mechanisms for them to cycle talking to the DHCP server that's native to the network, waiting / asking / re-asking?
Maybe looping something like:
/usr/sbin/dhclient -v enp1s0

Over a few times?
Perhaps parallel provisioning isn't needed in my current use-case as well.
Thanks again for the insight!
I'll cross-validate that they're issuing the DHCP calls at the same time, I beleive they are.

Actually, I believe it's pretty much the DHCP server's fault to assign the same address even it the renewal happen almost at the same time. So that's why I need to see the systemd-networkd's log to see what happens. I assume all of 3 get the same IP with the same lease in the very beginning. When the lease time hit 50% (T1), they should
VM1  --> unicast DHCP request  --> receive DHCP ack  --> get IP1
VM2 --> unicast DHCP request  --> expect a DHCP NACK here since IP1 allocated  --> broadcast DHCP discover --> get IP2
VM3 --> should follow the same path with VM2
It this case, DHCP server seems never NACK the DHCP request for IP1, so the VM2/3 will never broadcast DHCP discover to get new IP from the DHCP server.
Maybe you can try dhclient -r to release before a normal dhclient. dhclien -r will release the current IP so the next request from VM will be broadcast DHCP DISCOVERY to ask for a new IP instead of DHCP REQUST for simply renewal.
If they're still the same...We may need to know what the DHCP server is and check  how it works.

@mingshuoqiu  - thanks so much for that mention - it was more on the infrastructure side than anything else :smile:  :+1: - I'm going to go ahead and close this out. Thanks again for the help on this :+1: :smile: :100:

authors: irishgordo mingshuoqiu


text:
Fix DeprecationWarning in Python 3.7

...while preserving backward-compatibility with previous versions of Python.
The warning message is:

Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
class _SelectorMapping(collections.Mapping):

I fixed this slightly differently in #111 (since I'm dropping support for old pythons anyway)

source: gharchive/pull-request

authors: harvimt stevenwinfield

repo: harvimt/quamash

license_type: permissive

license_source: github-api


text:
merge from fork bitte-ein-bit/IQOption-Api

Hi harwee,
sure. go ahead and take the code over. Buying is working on forex. I do still have some trouble finding the correct current percentage of win/loss for a position. It's also most likely not python 2 compatible any more.
Sorry I had to update the master. It's the same commits as before but squashed into one, because with your message I realised I used the wrong git user/email.

I will look at the code in detail and fork it, but I would also like to keep Python 2 compatibility, I may pull your code and make some modifications to it before merging it.

Hi @bitte-ein-bit ,
i use your repo, but buy forex don't work for me... can you help me?
Ty

source: gharchive/issue

authors: bitte-ein-bit harwee luidelia

repo: harwee/IQOption-Api


text:
committee sessions data

/committee_sessions?knesset_num=KNESSET_NUM
select * from committees_kns_committeesession where "KnessetNum"=KNESSET_NUM

/committee?committee_id=COMMITTEE_ID
select * from committees_kns_committee where "CommitteeID" = COMMITTEE_ID

/committee_sessions/documents?committee_session_id=COMMITTEE_SESSION_ID
select * from committees_kns_documentcommitteesession where "CommitteeSessionID" = COMMITTEE_SESSION_ID

fixed in #8

repo: hasadna/open-knesset-backend

license: MIT


text:
Where is the backup patch?

Hi, in the README it states that you include "Minor OS changes made to allow backing up any app" for Seedvault but I wasn't able to find the patch(es) for it. Could you give me a pointer?

I reintroduce it in an not yet merged PR. See https://github.com/ypid/os/blob/machine-abstraction/config/patches/platform/ignore-allowbackup-false.patch. This PR has not yet been updated to Android 11.

authors: Atemu ypid

repo: hashbang/os


text:
Helidon doesn't resolve configuration properly

Currently application is trying to use application.yaml for configuration, this results in error when trying to start the block-node.
WARNING: Configuration file application.yaml is on classpath, yet there is no parser configured for it
Exception in thread "main" io.helidon.config.MissingValueException: Requested value for configuration key 'blocknode.storage.root.path' is not present in the configuration.
	at io.helidon.config@4.0.11/io.helidon.config.MissingValueException.create(MissingValueException.java:44)
	at io.helidon.config@4.0.11/io.helidon.config.ConfigValue.lambda$get$0(ConfigValue.java:93)
	at java.base/java.util.Optional.orElseThrow(Optional.java:403)
	at io.helidon.config@4.0.11/io.helidon.config.ConfigValue.get(ConfigValue.java:93)
	at com.hedera.block.server/com.hedera.block.server.persistence.storage.write.BlockAsDirWriterBuilder.<init>(BlockAsDirWriterBuilder.java:55)
	at com.hedera.block.server/com.hedera.block.server.persistence.storage.write.BlockAsDirWriterBuilder.newBuilder(BlockAsDirWriterBuilder.java:73)
	at com.hedera.block.server/com.hedera.block.server.Server.main(Server.java:72)

We'd need to fix the configurator to start using app.properties files for configuration variables.

Note, If we prefer to keep the yaml format, we could also look into preventing Helidon from trying to read the file; and ensure platform SDK config can read the file.

repo: hashgraph/hedera-block-node


text:
2755 hbar operator fees

Cherry pick #2755
Description:

Related issue(s):
Fixes #
Notes for reviewer:

Checklist

[ ] Documented (Code comments, README, etc.)
[ ] Tested (unit, integration, etc.)

Replaced by: #2781

repo: hashgraph/hedera-json-rpc-relay


text:
Add support for additional Hedera protobuf changes

Problem
Updates were made to the protobufs tied to the 0.26 mainnet release. We will need to make sure we add support for those changes.
Hedera Protbufs

[ ] https://github.com/hashgraph/hedera-protobufs/pull/190

Solution
Add support for the changes
Alternatives
No response

On it!

authors: SimiHunjan easpaas

repo: hashgraph/hedera-sdk-js


text:
PBJ Hardening

Harden PBJ
### Tasks
- [ ] #114
- [ ] #104
- [ ] #106
- [ ] #118
- [ ] #125
- [ ] #68
- [ ] #103
- [ ] https://github.com/hashgraph/pbj/issues/181

All tasks are complete. Resolving.

authors: anthony-swirldslabs poulok

repo: hashgraph/pbj


text:
Add our standard version maintenance idiom

_version.py in root package
referenced from setup.py

Done on the 🤡 master 🤡 branch


text:
Rename "Core" to "Minimal"

When I view https://www.haskell.org/platform/#linux-generic, I see that I can download the "Core" Haskell Platform. This should be renamed to Minimal to be consistent with terminology used elsewhere.

We went the other way 'round and renamed "minimal" to core as per the discussion here https://github.com/haskell/haskell-platform/issues/250
If anything we should probably update other terminology to use "core" -- luckily minimal/core is still relatively new (since 8.0.1) so this is a decent time to shift the name.

Yes, since posting, I've seen Core elsewhere. But not exclusively. I'm not opinionated about which it should be, but being consistent would be an improvement. Thanks!

closing as fixed. feel free to reopen and comment if there's still old language we missed fixing.

Actually, i note that the infamous downloads page still uses minimal rather than core, reoopening

fixed in the new repo

authors: gbaz goldfirere

repo: haskell-infra/hl

license_source: bigquery


text:
Disable highlighting of (other occurences of) thing at point

For context, I'm using ghcide HEAD with Emacs 28 and eglot 20200830.1254.
This is the behaviour I'm talking about:

I find this hugely distracting and so I would like to disable it.  I guess the more general question here is "is it possible to disable features and, if yes, is this the responsibility of ghcide itself or whatever LSP client one is using?"

Does this occur with other languages? And plain text files? I see the same behaviour with VS Code, but I see it on plain text files too, so I might be nothing to do with Ghcide.

This is a feature of LSP, but I think vscode does its own dumb version too, just on word match.
The feature is Document Highlights Request, and the LSP version uses the actual scope, so is not confused by name shadowing etc. It also highlights differently for where the value is set, vs read.
Personally I like it, but have set the color scheme in my emacs to be unobtrusive, the default is too in your face

I think this is probably the responsibility of elglot. And, indeed, it looks like it provides a mechanism for customizing this, with document highlighting as an example: https://github.com/joaotavora/eglot/blob/master/eglot.el#L1191

On Fri, Oct 09 2020 08:06, Michael Peyton Jones wrote:

I think this is probably the responsibility of elglot. And, indeed, it
looks like it provides a mechanism for customizing this, with document
highlighting as an example:
https://github.com/joaotavora/eglot/blob/master/eglot.el#L1191

That worked perfectly, thanks!  Even obvious things like this can be
really hard to find when you're not exactly sure what you're looking
for...

Yeah, I think we still need to say more about configuration in the readme.

authors: alanz michaelpj ndmitchell slotThe

repo: haskell/ghcide


text:
Collation customization: How is it exposed in text-icu?

It appears that ICU provides mechanisms for customizing collation (described at http://userguide.icu-project.org/collation/customization).
I’d be grateful for a pointer as to if, and if so, how this is exposed in the haskell text-icu package.

In order to customize collations, we need ucol_openRules() and ucol_getRules()/ucol_getRulesEx() to be exposed.  If no one is going to add support of them, let me do that.

repo: haskell/text-icu


text:
Processing services are translated

closes #56

PR ning sarlavhasi va commit message ga alohida e'tibor bering. Hozir tarjima qilingan tekstga fikrimni yozib qoldiraman. Sizdan iltimos:

Kerakli o'zgarishlarni qilib.
Yangi Branch ochib

authors: ElbekDeveloper mirzohidsobirjonov

repo: hassanhabib/The-Standard-Uzbek


text:
Unable to add targets

Created a alderson.yml file under the targets dir, but the target does not get picked up
---
job_name: 'alderson'
honor_timestamps: true
scrape_interval: 15s
scrape_timeout: 10s
metrics_path: /metrics
scheme: http
static_configs:
- targets:
  - 192.168.88.48:9100

Any idea why it's not picking it up? The logs don't give any errors

Fixed by renaming to *.yaml

repo: hassio-addons/addon-prometheus


text:
🛑 Analytics Server is down

In b8c94ea, Analytics Server (https://analytics.arash-hatami.ir) was down:

HTTP code: 504
Response time: 15485 ms

Resolved: Analytics Server is back up in ba5f15a after 41 minutes.


text:
Added new Feature component (Download App Links)

Also added a baseUrl and paths in tsconfig.json so we can import our components using @components/... instead of ../../../../components/...
Here's how the new component looks like:

@hauptrolle check this out. I've added a new component, but also made some changes in the imports. I've added path aliases so we can import our components easily like @/components/ResizableFrame instead of jumping to it ../../../components/ResizableFrame. Also added a jest.config.json file to hook everything up. Check it out!

@hauptrolle check this out. I've added a new component, but also made some changes in the imports. I've added path aliases so we can import our components easily like @/components/ResizableFrame instead of jumping to it ../../../components/ResizableFrame. Also added a jest.config.json file to hook everything up. Check it out!

One more thing. I would categorize the new component inside hero instead of features.

One more thing. I would categorize the new component inside hero instead of features.

One more thing. I would categorize the new component inside hero instead of features.

You think so? I was imaging it being used as a feature, below the fold. I'd redesign it if it's being used as a hero. Actually, I can make a hero version of it and then we'd have two 😄

One more thing. I would categorize the new component inside hero instead of features.

You think so? I was imaging it being used as a feature, below the fold. I'd redesign it if it's being used as a hero. Actually, I can make a hero version of it and then we'd have two 😄

I just merged #17  😁  So some of the files need to be changed.

I'll check that out tomorrow 🙌

I just merged #17  😁  So some of the files need to be changed.

I'll check that out tomorrow 🙌

One more thing. I would categorize the new component inside hero instead of features.

You think so? I was imaging it being used as a feature, below the fold. I'd redesign it if it's being used as a hero. Actually, I can make a hero version of it and then we'd have two 😄

Sounds good to me! Than we have 2! 😂

One more thing. I would categorize the new component inside hero instead of features.

You think so? I was imaging it being used as a feature, below the fold. I'd redesign it if it's being used as a hero. Actually, I can make a hero version of it and then we'd have two 😄

Sounds good to me! Than we have 2! 😂

@hauptrolle check out my latest changes now. I've moved the Jest config into its own file, I guess it's more predictable that way. Also I left the new component in the Features category, but I'll create a new version of it more suitable for Hero placement.

@hauptrolle check out my latest changes now. I've moved the Jest config into its own file, I guess it's more predictable that way. Also I left the new component in the Features category, but I'll create a new version of it more suitable for Hero placement.

repo: hauptrolle/chakra-templates


text:
Add coefficient of variation.

This also adds the missing aliases for kurtosis and skewness.
Closes. #18

Coverage decreased (-5.3%) to 94.737% when pulling 33fd935c86851998233d5c0c6dd9545829326ab7 on 18-add-coeff-varaiation into 0d7560fbbf7362d831f811018f42a341e2587e1d on master.

Coverage remained the same at 100.0% when pulling b1f5775a87bd775d71bdd77c7c0c9adbc4d9ecc7 on 18-add-coeff-varaiation into 0d7560fbbf7362d831f811018f42a341e2587e1d on master.

authors: coveralls crertel

repo: hawthornehaus/statisaur

license: unlicense


text:
[HAXdesktop] File submenu item should publish HAX sites to a remote git repo

This would involve...

Going into the main.js file within the HAXdesktop repo
Adding some lines of code within the click function for the submenu item labeled "Publish"
My approach involved having this code essentially build a shell script using node-powershell with system commands and git commands which would be invoked on click and then its output would be console.logged in case an error occurs
Consider that there is no variable in the script tracking the currently "Opened" directory; might need to be added
Consider also that there is no variable storing a path/URL to any remote repo; also probably should exist for these purposes
Update the comments I left related to this issue also

https://haxtheweb.org/site.json the JSON Outline Schema spec has publishing info in it. I'd suggest firing up haxcms https://github.com/elmsln/haxcms using ddev or docker.

publishing works on command line, desktop app should add things like this but currently it completely aligns /w rest of projects so really, we need nodejs to allow publishing via UI and then move from there

authors: btopro whatsacomputertho

repo: haxtheweb/issues


text:
#3 サイドバーの作成

サイドバーを作成する
要素：

ユーザー情報
カレンダー
検索
and more...

方法：

css?
django的にはブートストラップでやれればうれしいけど

必要性の薄さより、優先順位低

サイドバーという形式では実装しない。
タスク管理パネルを画面右側に配置、またナビゲーションバーを画面上部に配置

license: mit


text:
No scopes memebers visible in the Inspector

ok, I've noticed that 1 in about 3 sessions it does kinda work. For example now I have Object:Window but this intermediate Block (which should be the global script's scope) is empty, despite having one variable.

This is due to Firefox bug 1249962. In the new release an error message is shown when an object can't be inspected due to this bug.

authors: Spown hbenl

repo: hbenl/vscode-firefox-debug


text:
Switch to the Test activity automatically when a run test command is invoked

It would be useful to show the test tree when tests are started to avoid having to switch to the Test activity  manually. Almost every time I need to run tests (either via a hot-key assigned to the "Run all tests" command or via the hyperlink in the code), I like to see how the test run is progressing by looking at the test tree.
BTW, it looks like vscode API supports this via the reveal method on the view:

I have added the testExplorer.showOnRun configuration property to version 2.7.0.

Thanks, works well!

repo: hbenl/vscode-test-explorer


text:
Added logging support for directory analysis

Changes

Fixed small typo in error.py
Replaced print() statement in generic processor with logging event
Logged any error encountered when processing directories
Logged each file path when processing directories
Added logging_demo.ipynb to demonstrate logging capabilities

Refer to issue #146, #91

There was only 1 print() statement to convert to logging and I was unsure where else to place logging events as the numerous try... catch... handlers are already quite explicit about the error (ie. they already point at the file causing the error)
Any recommendations are appreciated

Oops, I'll add it now

repo: hc-sc-ocdo-bdpd/file-processing-tools


text:
🛑 stagin-env is down

In 22323ef, stagin-env (https://staging.lessonpal.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: stagin-env is back up in 3ff7b5e after 33 minutes.

repo: heIsThePirate/upptime-lessonpal


text:
🛑 stagin-env is down

In 7f342dd, stagin-env (https://staging.lessonpal.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: stagin-env is back up in 51411b7.


text:
reduced country list on map page

https://redpen.io/mn9c5f1f7edc6c579d

@markherringer already fix and push staging

authors: markherringer meomancer

repo: healthsites/healthsites


text:
I couldn't pass the validation when add Model.

Hi, I'd like to test the label studio backend so I installed MM detection on my Mac with docker-compose.
The mmdetection server run very well but I couldn't use it in my label studio project.
The server log is below.
**(labelstudio) (base) midi79@Cheolkyuui-iMac mmdetection % docker-compose up
redis is up-to-date
server is up-to-date
Attaching to redis, server
server    | 2022-06-27 13:05:51,845 CRIT Supervisor is running as root.  Privileges were not dropped because no user is specified in the config file.  If you intend to run as root, you can set user=root in the config file to avoid this message.
server    | 2022-06-27 13:05:51,852 INFO RPC interface 'supervisor' initialized
server    | 2022-06-27 13:05:51,852 CRIT Server 'inet_http_server' running without any HTTP authentication checking
server    | 2022-06-27 13:05:51,852 INFO supervisord started with pid 1
server    | 2022-06-27 13:05:52,858 INFO spawned: 'rq_00' with pid 10
server    | 2022-06-27 13:05:52,861 INFO spawned: 'wsgi' with pid 11
server    | 2022-06-27 13:05:53,951 INFO success: rq_00 entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
server    | 2022-06-27 13:05:53,951 INFO success: wsgi entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
redis     | 1:C 27 Jun 2022 13:05:51.427 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
redis     | 1:C 27 Jun 2022 13:05:51.427 # Redis version=7.0.2, bits=64, commit=00000000, modified=0, pid=1, just started
redis     | 1:C 27 Jun 2022 13:05:51.427 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
redis     | 1:M 27 Jun 2022 13:05:51.428 * monotonic clock: POSIX clock_gettime
redis     | 1:M 27 Jun 2022 13:05:51.428 * Running mode=standalone, port=6379.
redis     | 1:M 27 Jun 2022 13:05:51.428 # Server initialized
redis     | 1:M 27 Jun 2022 13:05:51.428 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
redis     | 1:M 27 Jun 2022 13:05:51.429 * Ready to accept connections

As you can see upper image, a validation error has occurred.
How can I pass this validation?
The server was running as below image.

I will wait for your help.
Thank you!

It works when I run on the python directly as below.
"pip install -U label-studio"
"label-studio"

However, I don't know how to use "Auto-annotation" when I use the labeling function.
Can you show me any instructions or guides?

@midi79 https://labelstud.io/guide/ml.html#Get-interactive-preannotations check this article please.

First, I really appreciate your reply.
However, despite I have set a "smart=true" option in the Label interface like below, it didn't work.
<View>
  <Image name="image" value="$image"/>
  <RectangleLabels name="label" toName="image" smart="true">
  <Label value="Dog" predicted_values="dog" background="#FFA39E"/></RectangleLabels>
</View>

And then I could see the error log at the label studio console like below.
[2022-06-30 13:31:26,214] [ml.models::interactive_annotating::278] [WARNING] Prediction not created for project  (id=1, url=http://localhost:9090): 500 Server Error: INTERNAL SERVER ERROR for url: http://localhost:9090/predict [30/Jun/2022 13:31:26] "POST /api/ml/1/interactive-annotating HTTP/1.1" 200 93 [2022-06-30 13:31:26,251] [ml.models::interactive_annotating::278] [WARNING] Prediction not created for project  (id=1, url=http://localhost:9090): 500 Server Error: INTERNAL SERVER ERROR for url: http://localhost:9090/predict [30/Jun/2022 13:31:26] "POST /api/ml/1/interactive-annotating HTTP/1.1" 200 93
I also saw uwsgi.log as below in the "mmdetection" backend server.
`
[2022-06-30 13:38:31,466] [ERROR] [label_studio_ml.exceptions::exception_f::53] Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/urllib3/connection.py", line 175, in _new_conn
(self._dns_host, self.port), self.timeout, **extra_kw
File "/usr/local/lib/python3.7/site-packages/urllib3/util/connection.py", line 95, in create_connection
raise err
File "/usr/local/lib/python3.7/site-packages/urllib3/util/connection.py", line 85, in create_connection
sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py", line 710, in urlopen
chunked=chunked,
File "/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py", line 398, in _make_request
conn.request(method, url, **httplib_request_kw)
File "/usr/local/lib/python3.7/site-packages/urllib3/connection.py", line 239, in request
super(HTTPConnection, self).request(method, url, body=body, headers=headers)
File "/usr/local/lib/python3.7/http/client.py", line 1281, in request
self._send_request(method, url, body, headers, encode_chunked)
File "/usr/local/lib/python3.7/http/client.py", line 1327, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
File "/usr/local/lib/python3.7/http/client.py", line 1276, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
File "/usr/local/lib/python3.7/http/client.py", line 1036, in _send_output
self.send(msg)
File "/usr/local/lib/python3.7/http/client.py", line 976, in send
self.connect()
File "/usr/local/lib/python3.7/site-packages/urllib3/connection.py", line 205, in connect
conn = self._new_conn()
File "/usr/local/lib/python3.7/site-packages/urllib3/connection.py", line 187, in _new_conn
self, "Failed to establish a new connection: %s" % e
urllib3.exceptions.NewConnectionError: <urllib3.connection.HTTPConnection object at 0x7f384d153a50>: Failed to establish a new connection: [Errno 111] Connection refused
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/requests/adapters.py", line 499, in send
timeout=timeout,
File "/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py", line 786, in urlopen
method, url, error=e, _pool=self, _stacktrace=sys.exc_info()[2]
File "/usr/local/lib/python3.7/site-packages/urllib3/util/retry.py", line 592, in increment
raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPConnectionPool(host='localhost', port=8080): Max retries exceeded with url: /data/upload/1/c1d71d61-pexels-brixiv-6527933.jpg (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f384d153a50>: Failed to establish a new connection: [Errno 111] Connection refused'))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/label_studio_ml/exceptions.py", line 39, in exception_f
return f(*args, **kwargs)
File "/usr/local/lib/python3.7/site-packages/label_studio_ml/api.py", line 32, in _predict
predictions, model = _manager.predict(tasks, project, label_config, force_reload, try_fetch, **params)
File "/usr/local/lib/python3.7/site-packages/label_studio_ml/model.py", line 582, in predict
predictions = m.model.predict(tasks, **kwargs)
File "./mmdetection.py", line 92, in predict
image_path = self.get_local_path(image_url)
File "/usr/local/lib/python3.7/site-packages/label_studio_ml/model.py", line 322, in get_local_path
return get_local_path(url, project_dir=project_dir, hostname=self.hostname, access_token=self.access_token)
File "/usr/local/lib/python3.7/site-packages/label_studio_tools/core/utils/io.py", line 91, in get_local_path
r = requests.get(url, stream=True, headers=headers)
File "/usr/local/lib/python3.7/site-packages/requests/api.py", line 73, in get
return request("get", url, params=params, **kwargs)
File "/usr/local/lib/python3.7/site-packages/requests/api.py", line 59, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/local/lib/python3.7/site-packages/requests/sessions.py", line 587, in request
resp = self.send(prep, **send_kwargs)
File "/usr/local/lib/python3.7/site-packages/requests/sessions.py", line 701, in send
r = adapter.send(request, **kwargs)
File "/usr/local/lib/python3.7/site-packages/requests/adapters.py", line 565, in send
raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPConnectionPool(host='localhost', port=8080): Max retries exceeded with url: /data/upload/1/c1d71d61-pexels-brixiv-6527933.jpg (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f384d153a50>: Failed to establish a new connection: [Errno 111] Connection refused'))
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/urllib3/connection.py", line 175, in _new_conn
(self._dns_host, self.port), self.timeout, **extra_kw
File "/usr/local/lib/python3.7/site-packages/urllib3/util/connection.py", line 95, in create_connection
raise err
File "/usr/local/lib/python3.7/site-packages/urllib3/util/connection.py", line 85, in create_connection
sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py", line 710, in urlopen
chunked=chunked,
File "/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py", line 398, in _make_request
conn.request(method, url, **httplib_request_kw)
File "/usr/local/lib/python3.7/site-packages/urllib3/connection.py", line 239, in request
super(HTTPConnection, self).request(method, url, body=body, headers=headers)
File "/usr/local/lib/python3.7/http/client.py", line 1281, in request
self._send_request(method, url, body, headers, encode_chunked)
File "/usr/local/lib/python3.7/http/client.py", line 1327, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
File "/usr/local/lib/python3.7/http/client.py", line 1276, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
File "/usr/local/lib/python3.7/http/client.py", line 1036, in _send_output
self.send(msg)
File "/usr/local/lib/python3.7/http/client.py", line 976, in send
self.connect()
File "/usr/local/lib/python3.7/site-packages/urllib3/connection.py", line 205, in connect
conn = self._new_conn()
File "/usr/local/lib/python3.7/site-packages/urllib3/connection.py", line 187, in _new_conn
self, "Failed to establish a new connection: %s" % e
urllib3.exceptions.NewConnectionError: <urllib3.connection.HTTPConnection object at 0x7f384d153a50>: Failed to establish a new connection: [Errno 111] Connection refused
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/requests/adapters.py", line 499, in send
timeout=timeout,
File "/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py", line 786, in urlopen
method, url, error=e, _pool=self, _stacktrace=sys.exc_info()[2]
File "/usr/local/lib/python3.7/site-packages/urllib3/util/retry.py", line 592, in increment
raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPConnectionPool(host='localhost', port=8080): Max retries exceeded with url: /data/upload/1/c1d71d61-pexels-brixiv-6527933.jpg (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f384d153a50>: Failed to establish a new connection: [Errno 111] Connection refused'))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/label_studio_ml/exceptions.py", line 39, in exception_f
return f(*args, **kwargs)
File "/usr/local/lib/python3.7/site-packages/label_studio_ml/api.py", line 32, in _predict
predictions, model = _manager.predict(tasks, project, label_config, force_reload, try_fetch, **params)
File "/usr/local/lib/python3.7/site-packages/label_studio_ml/model.py", line 582, in predict
predictions = m.model.predict(tasks, **kwargs)
File "./mmdetection.py", line 92, in predict
image_path = self.get_local_path(image_url)
File "/usr/local/lib/python3.7/site-packages/label_studio_ml/model.py", line 322, in get_local_path
return get_local_path(url, project_dir=project_dir, hostname=self.hostname, access_token=self.access_token)
File "/usr/local/lib/python3.7/site-packages/label_studio_tools/core/utils/io.py", line 91, in get_local_path
r = requests.get(url, stream=True, headers=headers)
File "/usr/local/lib/python3.7/site-packages/requests/api.py", line 73, in get
return request("get", url, params=params, **kwargs)
File "/usr/local/lib/python3.7/site-packages/requests/api.py", line 59, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/local/lib/python3.7/site-packages/requests/sessions.py", line 587, in request
resp = self.send(prep, **send_kwargs)
File "/usr/local/lib/python3.7/site-packages/requests/sessions.py", line 701, in send
r = adapter.send(request, **kwargs)
File "/usr/local/lib/python3.7/site-packages/requests/adapters.py", line 565, in send
raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPConnectionPool(host='localhost', port=8080): Max retries exceeded with url: /data/upload/1/c1d71d61-pexels-brixiv-6527933.jpg (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f384d153a50>: Failed to establish a new connection: [Errno 111] Connection refused'))
[pid: 25|app: 0|req: 120/120] 172.20.0.1 () {34 vars in 471 bytes} [Thu Jun 30 13:38:31 2022] POST /predict => generated 5523 bytes in 6 msecs (HTTP/1.1 500) 2 headers in 92 bytes (1 switches on core 0)
`
Could you give me some advice to fix this problem?
Thank you!

Looks like http://localhost:9090/ is not accessible on the LS side. Can you open this url in the projects - http://localhost:9090/health or http://localhost:9090/setup ?

@makseq could you kindly look here #245 I think I have the same problem. I've created a separate issue because @midi79 did not follow with docker compose solution.

authors: TrueWodzu makseq midi79

repo: heartexlabs/label-studio-ml-backend


text:
Rebased cmake-staging branch (post PRs 17, 18, 19)

This is the cmake-staging branch rebased on the recent bitcoin/master one with squashed "FIXUP" commits.
Additionally addressed https://github.com/hebasto/bitcoin/pull/18#discussion_r1324722015.

Previous linearization PRs:

https://github.com/hebasto/bitcoin/pull/16
https://github.com/hebasto/bitcoin/pull/14
https://github.com/hebasto/bitcoin/pull/11
https://github.com/hebasto/bitcoin/pull/8

A few notes regarding testing this PR on Windows:

The Chocolatey package manager can be used to install required and optional tools:

choco install python3
choco install ccache --version=4.7.5

To build and test natively on Windows, run commands as follows:

mkdir build
cd build
cmake .. -A x64 -DCMAKE_TOOLCHAIN_FILE=C:/vcpkg/scripts/buildsystems/vcpkg.cmake -DVCPKG_TARGET_TRIPLET=x64-windows-static
cmake --build . --config Release
ctest -C Release

Run functional tests as follows:

set BITCOIND=src\Release\bitcoind.exe
set BITCOINCLI=src\Release\bitcoin-cli.exe
set BITCOINUTIL=src\Release\bitcoin-util.exe
set BITCOINWALLET=src\Release\bitcoin-wallet.exe
py -3 test\functional\test_runner.py

The bench_bitcoin.exe fails due to a bug, For more details, please see https://github.com/bitcoin/bitcoin/pull/28486.

KNOWN ISSUES:

https://github.com/hebasto/bitcoin/pull/31#issuecomment-1722530069

@vasild @TheCharlatan @theStack @stickies-v @Sjors @sipsorcery @theuni @willcl-ark
Ready for extensive testing :)
The next meaningful PR with new commits is going to be based on this branch and will be submitted shortly.

In this comment I'm going to post tested configurations on particular systems.

Debian 10 (buster). The system's CMake version 3.13.4.

system packages:

mkdir build
cd build
cmake -S .. -DCMAKE_C_COMPILER=clang-13 -DCMAKE_CXX_COMPILER='clang++-13;-stdlib=libc++' -DWITH_BDB=OFF
cmake --build . -j $(nproc)
ctest -j $(nproc)

Fixed a couple of compatibility issues found during testing on a range of platforms.

I found a bug: it fails to find sys/sdt.h in depends. Going to fix it in a follow-up.

Another couple of minor issues have been found during testing and fixed.
The list of the tested platforms and configurations has been updated as well.

The next meaningful PR with new commits is going to be based on this branch and will be submitted shortly.

Fellow reviewers, I'm going to suggest you hardening and shared libraries :)
Any other suggestions?
And good news! After that, only two steps remain until switching Guix to CMake: Qt and Guix scripts themselves.

Tested on Intel macOS 13.5.2 (Ventura).
The "configure" step took 53 seconds the first time, 34 seconds the second time (after a git clean -dfx, it caches?). Compared to 18 + 40 seconds for ./autogen && ./configure.
The warning when UPNC dependencies are not present is a bit verbose, but fine for now:
-- Could NOT find MiniUPnPc (missing: MiniUPnPc_LIBRARY MiniUPnPc_INCLUDE_DIR MiniUPnPc_API_VERSION_OK)
CMake Warning at cmake/optional.cmake:62 (message):
  libminiupnpc not found, disabling.

  To skip libminiupnpc check, use "-DWITH_MINIUPNPC=OFF".

Call Stack (most recent call first):
  CMakeLists.txt:240 (include)

I don't see a similar warning for USDT. Since UPNC is disabled by default, we should probably not complain if it's missing unless the user asked for it.
cmake --build . -j 2 (after wiping ccache) takes 8:03 minutes, vs.  5:30 for make -j17  (I wiped ccache and waited a bit for the machine to cool down). But that's not a fair comparison because this PR doesn't build the GUI and fuzz tests (will try again later).
(haven't tested the binaries and test suite yet)

I'm away on holiday until the 2nd, but will pick this up asap when I return.

Just given this a quick test run, and was also interested in comparing against autotools...
One thing I noticed up front was that with cmake the BDB wallet is built where I would need to pass --with-incompatible-bdb with autotools, e.g. when using system BDB. You do get a clear warning, but still a change in behaviour, I think:
-- Found BerkeleyDB: /usr/lib/x86_64-linux-gnu/libdb_cxx.so (found suitable version "5.3", minimum required is "4.8")
CMake Warning at cmake/optional.cmake:148 (message):
  Found Berkeley DB (BDB) other than 4.8.
Call Stack (most recent call first):
  CMakeLists.txt:240 (include)

CMake Warning at cmake/optional.cmake:150 (message):
  BDB (legacy) wallets opened by this build would not be portable!

Will come back to this to review the new code and test hardening/shared libraries later in the week.
  If this is intended, pass "-DWARN_INCOMPATIBLE_BDB=OFF".

  Passing "-DWITH_BDB=OFF" will suppress this warning.

Call Stack (most recent call first):
  CMakeLists.txt:240 (include)

These are the results I got building with various combinations of cmake, cmake + ninja and autotools:

cmake:

cmake_script
#!/usr/bin/env fish

ccache --clear

mkdir build
cd build

set start_time (date +%s)

# configure
# use CMake to generate and clang as compiler
cmake -S .. -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCCACHE=OFF

set configure_time (date +%s)
set configure_interval (math "$configure_time - $start_time")

# build
cmake --build . -j (nproc)

set build_time (date +%s)
set build_interval (math "$build_time - $configure_time")

# test
# use CTest
ctest -j (nproc)

set end_time (date +%s)
set test_interval (math "$end_time - $build_time")
set total_time (math "$end_time - $start_time")

echo "Time taken for configuration: $configure_interval seconds"
echo "Time taken for build: $build_interval seconds"
echo "Time taken for testing: $test_interval seconds"
echo "Total time: $total_time seconds"

Time taken for configuration: 16 seconds
Time taken for build: 168 seconds
Time taken for testing: 12 seconds
Total time: 196 seconds

cmake + ninja:

cmake_ninja_script
#!/usr/bin/env fish

ccache --clear

mkdir build
cd build

set start_time (date +%s)

# configure
# use CMake to generate, specify Ninja as generator and clang as compiler
# cmake -G Ninja -S .. -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCCACHE=OFF
cmake -S .. -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCCACHE=OFF

set configure_time (date +%s)
set configure_interval (math "$configure_time - $start_time")

# build
# ninja -j (nproc)
cmake --build . -j (nproc)

set build_time (date +%s)
set build_interval (math "$build_time - $configure_time")

# test
# use CTest
ctest -j (nproc)

set end_time (date +%s)
set test_interval (math "$end_time - $build_time")
set total_time (math "$end_time - $start_time")

echo "Time taken for configuration: $configure_interval seconds"
echo "Time taken for build: $build_interval seconds"
echo "Time taken for testing: $test_interval seconds"
echo "Total time: $total_time seconds"

Time taken for configuration: 17 seconds
Time taken for build: 150 seconds
Time taken for testing: 12 seconds
Total time: 179 seconds

autotools:

autotools_script
#!/usr/bin/env fish

ccache --clear

set start_time (date +%s)

# configure
./configure --without-gui --with-incompatible-bdb

set configure_time (date +%s)
set configure_interval (math "$configure_time - $start_time")

# build
make -j(nproc) -C src bitcoind bitcoin-cli bitcoin-tx bitcoin-util bitcoin-wallet test/test_bitcoin

set build_time (date +%s)
set build_interval (math "$build_time - $configure_time")

# test
set -l test_suites addrman_tests allocator_tests amount_tests argsman_tests arith_uint256_tests banman_tests base32_tests base58_tests base64_tests bech32_tests bip32_tests blockchain_tests blockencodings_tests blockfilter_index_tests blockfilter_tests blockmanager_tests bloom_tests bswap_tests checkqueue_tests coins_tests coinstatsindex_tests compilerbug_tests compress_tests crypto_tests cuckoocache_tests dbwrapper_tests denialofservice_tests descriptor_tests flatfile_tests fs_tests getarg_tests hash_tests headers_sync_chainwork_tests httpserver_tests i2p_tests interfaces_tests key_io_tests key_tests logging_tests mempool_tests merkle_tests merkleblock_tests miner_tests miniscript_tests minisketch_tests multisig_tests net_peer_eviction_tests net_tests netbase_tests orphanage_tests pmt_tests policy_fee_tests policyestimator_tests pow_tests prevector_tests raii_event_tests random_tests rbf_tests rest_tests result_tests reverselock_tests rpc_tests sanity_tests scheduler_tests script_p2sh_tests script_parse_tests script_segwit_tests script_standard_tests script_tests scriptnum_tests serfloat_tests serialize_tests settings_tests sighash_tests sigopcount_tests skiplist_tests sock_tests streams_tests sync_tests system_tests timedata_tests torcontrol_tests transaction_tests translation_tests txindex_tests txpackage_tests txreconciliation_tests txrequest_tests txvalidation_tests txvalidationcache_tests uint256_tests util_tests util_threadnames_tests validation_block_tests validation_chainstate_tests validation_chainstatemanager_tests validation_flush_tests validation_tests validationinterface_tests versionbits_tests xoroshiro128plusplus_tests
echo $test_suites | tr ' ' '\n' | parallel -j (nproc) './src/test/test_bitcoin -t {}'

set end_time (date +%s)
set test_interval (math "$end_time - $build_time")
set total_time (math "$end_time - $start_time")

echo "Time taken for configuration: $configure_interval seconds"
echo "Time taken for build: $build_interval seconds"
echo "Time taken for testing: $test_interval seconds"
echo "Total time: $total_time seconds"

Time taken for configuration: 28 seconds
Time taken for build: 130 seconds
Time taken for testing: 7 seconds
Total time: 165 seconds

I only ran these twice each (and took the best result of two runs). I also used parallel to run the tests in the autotools run (as not all of them are run via ctest yet), which appears to be more efficient than having ctest run them :)

@willcl-ark

Just given this a quick test run, and was also interested in comparing against autotools...

Thank you for testing!
I'd like to add a few points as follows.

To configure Autotools to build the same set of binaries as this branch, one should run:

./configure --without-gui --without-libs --with-incompatible-bdb --disable-fuzz-binary

Both ctest and Autotools make check runs the same 119 tests from the src/test and src/wallet/test directories plus 3 additional tests:

test/util/test_runner.py
test/util/rpcauth-test.py
bench/bench_bitcoin -sanity-check -priority-level=high

However, Autotools make check runs for minsketch, secp256k1 and univalue subtrees.
Do we actually need to test code in subtrees?

I'd like to add a few points as follows.
1. To configure Autotools to build the same set of binaries as this branch, one should run:

./configure --without-gui --without-libs --with-incompatible-bdb --disable-fuzz-binary

Thanks, I missed --without-libs --disable-fuzz-binary. This config yielded these results per my updated script (best of 2 runs):
Time taken for configuration: 22 seconds
Time taken for build: 130 seconds
Time taken for testing: 6 seconds
Total time: 158 seconds

However, Autotools make check runs for minsketch, secp256k1 and univalue subtrees as well.
Do we actually need to test code in subtrees?

Yes this is what I was trying to correct for, as it makes quite some difference, not that I expected there to be any runtime difference in particular.
I think I'd agree that subtrees don't need to be run, although I think it'd be good practice to run them after any update to the subtree, if there was a convenient mechanism to do so...
FYI I scratched out a basic CMakePresets.json file to make for faster building which is quite nice. I think packaging some presets (besides the defaults?) could be a nice improvement for us?

CMakePresets.json
{
  "version": 6,
  "configurePresets": [
    {
      "name": "debug",
      "description": "Debug configuration with verbose output.",
      "binaryDir": "${sourceDir}/build/debug",
      "cacheVariables": {
        "CMAKE_BUILD_TYPE": "Debug",
        "CMAKE_VERBOSE_MAKEFILE": "ON"
      }
    },
    {
      "name": "debug-ninja",
      "description": "Debug configuration with ninja.",
      "binaryDir": "${sourceDir}/build/debug",
      "cacheVariables": {
        "CMAKE_BUILD_TYPE": "Debug",
        "CMAKE_VERBOSE_MAKEFILE": "ON"
      },
      "generator": "Ninja"
    },
    {
      "name": "release",
      "description": "Release configuration.",
      "binaryDir": "${sourceDir}/build/release",
      "cacheVariables": {
        "CMAKE_BUILD_TYPE": "Release"
      }
    }
  ],
  "buildPresets": [
    {
      "name": "debug",
      "configurePreset": "debug",
      "description": "Build using the debug configuration."
    },
    {
      "name": "debug-ninja",
      "configurePreset": "debug-ninja",
      "description": "Build the debug configuration using ninja."
    },
    {
      "name": "release",
      "configurePreset": "release",
      "description": "Build using the release configuration."
    }
  ],
  "testPresets": [
    {
      "name": "all",
      "description": "Run all tests.",
      "configurePreset": "debug"
    }
  ],
  "workflowPresets": [
    {
      "name": "debug-ninja",
      "description": "Configure and build all in debug mode using ninja (auto nproc).",
      "steps": [
        {
          "type": "configure",
          "name": "debug-ninja"
        },
        {
          "type": "build",
          "name": "debug-ninja"
        }
      ]
    }
  ]
}

You can use like:
# configure preset
cmake --preset debug-ninja

# build preset
cmake --build --preset debug-ninja

# configure and run preset
cmake --workflow --preset debug-ninja

It should be possible to also add test steps to the workflow preset, but I haven't done it yet...

You do get a clear warning, but still a change in behaviour, I think:

We definitely should not be reverting to building the BDB wallet by default, without the additional flags.

On macOS (Xcode 15.0), the linker emits warnings:
[....] Linking CXX executable test_bitcoin
ld: warning: ignoring duplicate libraries: '../../libleveldb.a', '../libbitcoin_common.a', '../univalue/libunivalue.a', '../util/libbitcoin_util.a'

[....] Linking CXX executable bench_bitcoin
ld: warning: ignoring duplicate libraries: '../../libleveldb.a', '../univalue/libunivalue.a', '../wallet/libbitcoin_wallet.a'

I'm going to tackle with them in follow-ups.

@TheCharlatan @theuni
Do you reckon we can move further with this rebasing PR and update the staging branch?

This branch has been force pushed into the https://github.com/hebasto/bitcoin/tree/cmake-staging.
Closing.

On macOS (Xcode 15.0), the linker emits warnings:
[....] Linking CXX executable test_bitcoin
ld: warning: ignoring duplicate libraries: '../../libleveldb.a', '../libbitcoin_common.a', '../univalue/libunivalue.a', '../util/libbitcoin_util.a'

[....] Linking CXX executable bench_bitcoin
ld: warning: ignoring duplicate libraries: '../../libleveldb.a', '../univalue/libunivalue.a', '../wallet/libbitcoin_wallet.a'

I'm going to tackle with them in follow-ups.

Fixed in https://github.com/hebasto/bitcoin/pull/34.

I found a bug: it fails to find sys/sdt.h in depends. Going to fix it in a follow-up.

Fixed in https://github.com/hebasto/bitcoin/pull/37.

authors: Sjors fanquake hebasto theuni willcl-ark

repo: hebasto/bitcoin


text:
feat: toggle unescape strings

Hey, thanks for putting this great tool together. I often run into logs that have some escaped string, like "This is a newline\n". When these strings get long, it's very hard to read, and sometimes they can be multiple levels of escape being nested. I've ran into bugs that I could've solved a lot earlier if I could easily inspect escaped logs.
It would be great if there is a toggle to escape one level (with support for escaping more than one level).
I unfortunately don't have time to contribute atm but leaving a request here in case any one else also has similar needs. Happy to come back and contribute this feature when I have some time.

Hi! Thank you for the issue.
Let's take the following logs:
{"message": "123123123123\n123123123123123\n123123123123123"}
{"message": "123123123123\n123123123123123\n123123123123123"}
{"message": "123123123123\n123123123123123\n123123123123123"}
{"message": "123123123123\n123123123123123\n123123123123123"}
{"message": "123123123123\n123123123123123\n123123123123123"}
{"message": "123123123123\n123123123123123\n123123123123123"}
{"message": "123123123123\n123123123123123\n123123123123123"}
{"message": "123123123123\n123123123123123\n123123123123123"}

They look as on the picture:

How do you want to see this?

Naively, I think just escaping the sequences as is would work. The important thing is changing a long piece of text that's practically unreadable into something that at least has structure. The lack of indentation would be a bit weird, but this is also how Python triple quote strings work so it least has precedance.

Alternatively, something like this might make sense, but I realize this is probably straying a bit far from any JSON conventions

what about expanding such strings on click?
and probably this issue should go to https://github.com/antonmedv/fx (this widget is reused in json-log-viewer).

I think that would be a good UX. Let me post to the fx repo. Thanks :)

authors: WesleyYue hedhyw

repo: hedhyw/json-log-viewer


text:
Update precache_binder.yml

I think this is ready to work @MichalChromcak can we try it?

@hamelsmu Thanks for the hard work! Trying now.

authors: MichalChromcak hamelsmu

repo: heidelbergcement/hcrystalball


text:
Upgrades OCI to 2.41.0 on helidon-3.x

Signed-off-by: Laird Nelson laird.nelson@oracle.com

@barchetta If you could take a look I'd appreciate it.  Although the OCI BOM contents will not (should not) influence anything on this branch, I feel that they need to be there to ensure backwards compatibility.

@ljnelson I suppose this is OK (keeping in the ugly BOM workaround even though we don't need it). Can you update to latest OCI SDK and take out of draft?

Roger

authors: barchetta ljnelson

repo: helidon-io/helidon


text:
Use Hamcrest assertions instead of JUnit in  examples/quickstarts/helidon-standalone-quickstart-se - backport 2.x (#1749)

Part of #1749
Original PR

/oca-checked

/trigger


text:
Archetype - Remove unused files

See #279

@tvallin Can you check if this needs to be port to 4.x, thanks.

Sure, see #7253

authors: romain-grecourt tvallin


text:
[Removal]: Request Removal from Denylist

Hotspot Name
Soft Gunmetal Shell
Hotspot b58 Address
11WtA7eTpeSzdMQVr3hueHnvwnhUMXL8A853Zuao2htzyjXDhhj
Discord Handle
No response
Hotspot Manufacturer
Heltec Automation
Removal Reason
My hot spot is on the denylist. Now they have been adjusted, corrected previous mistakes, and redeployed on the spot. Hope to be removed from the denylist. Thank you very much!
Modifications
No
Extra forwarders
No
Extra antennas
No
Additional Information

We have taken into account this removal request in the next iteration of the denylist. It may take some time before it's processed. This is an automated comment due to the volume of addition and removal requests. A future tool is in the works to provide more insight into the analysis approach made by the Helium team and community members that maintain this list.

repo: helium/denylist


text:
[Removal]: Scrawny Wintergreen Troll

Hotspot Name
scrawny-wintergreen-troll
Hotspot b58 Address
112MfKD9TMvgwtfV3ZVHg3UbrnJ7RLaTpLReWJi552qehdsQCSHr
Discord Handle
No response
Hotspot Manufacturer
Bobcat
Removal Reason
No idea how this ended up on the list.
Modifications
No
Extra forwarders
No
Extra antennas
No
Additional Information

Hi @ashwinvandijk
Can you please tell me which of the following hotspots belongs to you?
111QcCCGMRnDyLDPTgR1atFbWu7qZh5J6dbFPPGfsoydTsak1qz
1122KVGPUyuKNkT3nKuWNs1fU8x1uGVg2WPGrSBRfPRLxwqRjpx8
1122mi1ZCibrX6NLjbesdS1dt3Q4cJkpyL2TcwWQMU9pNeFR3MDi
1123zFMedeUxzmKjiU3F3iJNvr7tuaJrzh1ZsoZZJwLk7FaNPyA
1125iywX4Sg8bSkEeJEoB8xxwdvi6BzbY2py5f5Xhyaw34Z7QT5g
1125qq4RG7NxZDKf6WBQ2gQuaH2C6PpymZqWj5mbSeF7f7BWShC
11266M4uDGWRr4sEH6aaV8WYTN8n9RDe4MSbP5wzC6Zdyct8ExvM
1126pX3GysyzQPEc1m4uUevgkuGNjGCUmuSYExYQNnLn9gjVLD15
1128H55ex9TJu5UnEJxAXDL8jU6maYxRkKVE1akMVKZW78KxVQsw
1128Jr1ydhwW3YjwabqZnixLBvQuoufAGuXVGxpbk9vT1Ke93r5n
1128YZ3iBVDWo68ioqqX4v4Xg2k9BMwQb7VE9FkrRKE3wNGgGyn6
11294J1S4nvabjAGMZAK62h5sHNCfGjFi1uUteZaPLNDkgGfQNke
1129tJGsxQXaNpZeQxYEbVeMKKnnsVnHb779PiqyVqsPtTHkaQmA
112adp8pqGJtvTBV4rdDynwvDgMbvrau4S66gCPoT6tDkNiNHSfu
112AE9dqZgVY67N75gq7Qv7Cz1ao9pRCGVDQHteM7jFTTnJ7zKdf
112ALVvvpgXoPLi6ypLdfbbUTtHATVy4jMqViKEnGmKCqRgmc62i
112ANvyhkaVmgzjVVcHNmT2Vk6s5ftEHnHxcvfpLMqooGRmA7YCg
112BAp9mhUTzLEieYVimF91MTPB9tBVsNWihwtGhfiE23aXEtrxh
112BbenDouWN4G3kUSreMVYBvhSEfS2H9bekZfXdvmmSUyrnzt37
112BfwACerCkhocHwjFFRKfHjBD5VRpFYo2QaDuGDdaakos3vzCk
112Chi2qxsUy5acMa9RwvQvYmBLU91cRcptpNYJyucCCxR1FfNYW
112CsawENTHDaQg8o1skxh7ixR2P5MgT6xme6TEZAwLta6MSovEM
112CYsosqcM3d9srpNjvEA2f7oWoRo5mz2cjQc5g7dhSDV6m1MLB
112cZUuLYZMT8zr8UUgTXG4FTUCGKPNRG9qo8whq3RrfyHTMatYW
112Ee35eDs9nd1bxqijj2qiQUrYRVLMfKaLQfzeRpPu86zVUSjoN
112Eg5dv3vrqDV6qCTjX9jWA1XUK3WaWzo3zFia3hbFpRs7SfZhv
112EJLUwiVxAVZb3MRMARB1fob8Ge38XzE5oat8J8d7KaX54XeMP
112EUxpVzdk6Cx624acMezvBjT862xUUVPcYrwvPXpXf8qBBCcBk
112eymLqEHHgmdKVVs7xcRnEgAUMuK1Ep2ruRj5KRMYZUiMDqie9
112FGowfrH7hhVPJrTWpR2sWzNXMy84c55KFZMJEZrt1WqJ1oHU4
112G5PHtPCpg9sxLKAWbcXJtHqHeT51s2kvoqe9ydVpCw4gTMGsJ
112g9cdEGYZyhXv63h6zK3rnmcNeVmHwf3aeumv5qMF8E7BcrHQc
112GfVDnjcA1LxDNtwX379webp86fGGSKNFHDfM5n1RAK9LoyAVS
112gQrLVwPagNhbYzLYQdqDYYVJWxMgZLrKAKQV9fkKLSbSF2pXj
112GT66vHaypPTfk85tsCBcrSbNE8Cq78vw9wwc9YG5ZnLkEvm2j
112GTrKiSq5hu7fnhusWB6vTGRwsLs1Rcf5wLgz49U3EAPiweyqd
112hPaKgWTsZrZPooozZMAtWb73aJ9ByCKqV1j8XEiioBUKtJevi
112Hz1aTDjpo65SLut2UcBkKfUYjV3MK27GSzWmQ3w8aTrAMuvvf
112kU9RTtkQ3ukhDjsZmuEjEd9UMC1iNSg6vKZKwqE5tmX3fMefZ
112KY4uzpGTnnF4agmZbBYb4BMtKCS9N5v5dyDHR5izRjVeQ1kqH
112m1WaCPcCoESuR5D6qVDe3i1i8QbTmpLQCaPukoH5jKUS9Cr7N
112MbKBoKNWTgacHMCrWQuXcdkHZVTjusF3kq149CmGzRzHSzym8
112mEp9ERv7F4oyNZW6XNNqoETQvPfvtmFaSPU1Heci1G2UdSkch
112mFUm7TgTrouYWaPs69Vu4YpqFtZ3fS16sqTLvAcrkXFKaYtfn
112NCSrNV49sRFn4TGNoNrN6W9n9TKewQFmB4DgtwDwWf8vyD8Wo
112nr2WnkiUDVAKXNLrN7B87HFe6AB56UKmReutoS4LeWguFaCyw
112NVfNBdBM4sQB6u264aQfPZi2EWuvgi49MFLHmMCJWEU23FoLH
112nyhUjFU4f5irLWcqYQauXTdNRFMzXGJFfdvUfe9x7VfMjxpTC
112oHcKboDrHfpKtu5GE5PbTm7qbREUrrucUeXxk3shjRhzSaKhK
112ooDao2FMbwY3wsDS2wvjgP9NEmyjxf2w84opaynSaoj5urhhY
112ptHzFhYDpZ5ZknYzFWgPCzjGvv1UWTuH8fcfViFkCUpijTTvD
112pXnJnx26419kiifb77caHjB35xqzQPGhQjUHsxBRmDAtEEMim
112RgWGMmCHFMXuK7MpqVSXLVJ7ZypCQJuMsFEaEhd18kvi4fn3y
112sYxLaujAvhkEriBnwurv2cMq2QDxp9BBRwMxJHWoersVnfV8X
112tawTtSoJkCvTvHxgChuiK5fTD3UM7P4pQx5hcPKPmusAKqLTp
112Tn1Hu2P9rkKxQsdBCrsunDiVwtspncPzKrZNt3QmYgunjbx4q
112Tsga9iv7iqrtCZHg1gCnxFHxWx1rPVAwn7rAndbWDw3kffPgS
112UC6Pv1Rs4KnxqEraiveFJiCwMu23qVAtSi3gRDkzXN9L5G4Wz
112UD5SYGEd5Nh5iTzKfMk9tiWKD4aHBAdj4mwrcvm68RQgnfAvj
112Uub9827Cudq5frKczzpbXtengHrh3GcmC7QzMBVgRdJHZd7nx
112UX3ehQxa53PLNDdSYJrjtMdszn1LS9KcNTcGVZuMYMcvd73Qc
112vnwhyDG91Cz3X2VFGV1vzZEKFJbqeUrdx7bFmstQE8d1DVEXS
112VvHEybas2thSZYkegrkcx3LfktitRBfgNQA1KNY5NNpWpuLJw
112wFM9K4y3ncx9ZKnbyxmYLWLDVLTF2ZiySDJFetttgmhRBz1Ht
112WKwAcaGQWs7VNiSTwAiWFTw5gFGJLFQKPPY6wCi3r4cLf3qkh
112ZeHC1AFSug8hLdNs5s67KsCEGkDjPCNdJNERVqFGwiDFX9dwF
112ZEhcWemGF8ZogNhH4yXYGGouFFzji9tpwKtQHA1kv2PjdYQxK
112Ztp8NE5ddr3kW2a3CcJsXnMmHLGH53VgpBWNcorprrLW5t3vS
113ddjbfssgDhkK4bHhNXVwmDQ8Duf55KjvpvoYPyATegbXxoFS
113KmkcXSxA2cdUt39YNy36PfomXA2be7ov7432K7zGRYDXD4xe
114h6pJiLGSMSQgTwD6eZp89nqSKoarXBouSrRaJW8D9LLsb5j2
115HhuhFdSqciN1kGZdAChXT5xURqcHbT8BKJnHftUn1T2KERvf
115ZSbXrpVVdieEzxHmtBJcPHQvufpDEnbL4w4b9MQdp6dDL1GJ
116stfCRZELqh49uKwu4JhTbGwsS5XNWjRnD1SAAZedREviBC3P
117nmZU3sd83dS1HZh5CZRoWU5hDHwd5PxEPZAzppkbo9TQa1Nz
117VgDdsJGepVodQ32oHNYs2bUEGNVRzuQYhsaYHZXnvBt27q6Z
117ypXD7GJiU6J1jJMdHfdMjgsA9kTLKXgtXWEedKzP7Hry3voY
1189fZNG5TktmRwPcTk5PWeuc2N827cv2X1d9sVkqx2SAkjRFpM
119EX75NyiKGTn6moVLKqAvuzxXqiFHuamkmdfNPbf19JomqgFt
11AADUigLorjYQxi8ejBmiuyjBoDZc2FadgtdSuNqyJzqKTWKe5
11AEVdZ8TCxaXe6WJd5TiKzysNEZiZCyTXTeAwGB3SVNWv4Z8PE
11auNpBo1J8Ep4C4zqUxfqYgWJWWL16KwnBsEU4CiJU1e59QWaC
11bJhj8WmhnoUvhNSTT4fpNvdJgyQZFiUmcd6LTnfL6gTT9b1et
11Bo8MwZZfies6jga3WrZKwUn215j3dmZ6EC5ynkSwefN28iCvN
11d4jQ6YXJqy82zHVtThYgTvZm22xEoDzhNxzFLF5RdjtH3J1RK
11d8MkdfoVeA9q5xMjkimE9JnMCSPde8drj31Snc2SvT8xJR7Gw
11eBiT9He3seZXxmPDJ3y8ZQnLsh7QLj46hv9xawreH5F4nRW9u
11emwhtFypyDpCX1MckvYk4xf8BTUsH62WQhQaq9KZamNXHbQJS
11EUgfkFyDWPdc4iejZA9zv7f2JLD8n7TaNYv5TxzvYy78xCkxY
11fgMsCbgMrjtziVJGst8itpCgJm6F2B5hfuA23ET3K5Tp1c6rm
11FYntHK8dZJpDJSVtWJuD5wYZDyTrSuXtbirjadm8Dw61k6uw3
11gLTK2LDKCfYjYxyKd5vNV3ZF9rjhsH3czqoQi38wLzP7nYA1P
11GSBo1X8L3Dj6QZwWMc6G9Amv7yz8PGhQZJ61mXapJxJsRvENr
11gsd5n23BZZ4k26oR6do89ayfj8faCryBUiTEJ6hLjYcunk65c
11guXbty2fmvys7XYPduVdg73eUnHyTGQ6NUfRcLEHDyqzZRorH
11gvtnxnYq936WKVXwPyb3JvhUbJGPg4TUNYTyVthX9N6rjVRy5
11gz3cEhCpLb6BFtkKmro91fKFpiJYTNdimLNV61pS4dKWJo6j
11hc56LBbv4BbvPd2uPTYif6Uh6J1CKw72yyudyRBxmns1GxApW
11HEqUUAJLq39hBeYbsAyA1rk47Sub9eXrLqXSYai3JhsirdEGe
11HFB6ZYgF6uAzA9K4Q7THwfkS6QvfFW5NhZ3SsU5Dcd7inhfei

11HJEit84xxJJ1uYQfjPcjf3TN8mGFmDw9daugJhMiWtussySkM
11Jf9AdyBf1FiEWE6RaLXkXK8aMmShFmkz9SbpBJXemYDqT2k3r
11jFCwqwy1Zxy6iiHkrZzJGTey2ZwSxLPSFV2ikiMEQX47Pe6Rk
11JGcZsc5Rw5j3RZ9mpibZDWoXqED94xdoR8v8addcrHc5uKKaw
11JHHtYUmNGZJr6z4xGoTRLatsdg7FbLtiZSsoC4y1FLcesTayp
11jYNs9xi1DbugFVmRMp9Asx4GqcMsRR58cmWvGRSALAtL81qn
11LqVRA59mDP9teb9RGYp1n8jFTyRPUmsoQPfPkLqsT3v6ptzYn
11LTqgHYYgWc6HuSbLkDxWCduGo5PVp3uHSFJE8xn3vxBNxh6Jv
11LzMhFdzLjBD26fHyp2xfK9PufAsbrRL9yJf7QGppT5ssLrzpf
11MEX5P3uRVzCgywHxiJ1m8ufMnXxau3zUeKGFyWvhaJDLuixmv
11MLt2pDS4a8x5HG6CjAvULA92XAqAgWvF5KFWU8VESEBVNPvXo
11MutaWwgVe5PD6m8t2htK74XvdQGWK5YR97C5LDcuhe1EhqD8H
11nFzpbu3A9MnaWiKkmzBMWc3HevVLbD8w3aS59qCtgfx6Drir
11NUcWhnv81bfUTLiCRaYkQr8QbZW2L3kBWH7KZFoRCmjaFHRJZ
11P7FMf2rYsuJVw9BqAhCPu1qNxKs1BF8tAq3LPmpuX9Jvu9nSw
11pZBXHeMC21NJAYQipXgnrReC5SwM5ZPRXqi2ucrJScAnguFaY
11qQ8YFSmPQPghdeeBpmYHq9ubi2RVa9B15UWrSfQyV2j7EEyVT
11reB6jm631qyaAGJ3rsiChHLw47EUMPgf6LXtARAePzRjSnsmP
11RN2LaMFowb8S56PZnv98s57KD8zUy5X8EZi3dmKdxFSCi1kiJ
11TAExi2FGBTnJxVDN1pejx2dBZybJBmFUXKxEUmrDZ6gmi6hXf
11tCKasEWiUt7NJsF8QYNKWQnS92t37tjwfD73E9BC8tkk6R9hn
11tHGZ3rZZbUaJBphA8euPMPehkRYT21ZT9R6iq3zWtxjUVY78k
11UR4uEMkcTuAeyK9i2h3TgBt8hALTiPYJBcXV6UW5GbhrBVdn9
11uv3NDULLsoESL4h1qdzbBrJV26psM6Qcjsixy4wdVfnNGDioQ
11vd7AUKsuqMiRGFxv8gWZz2mcviJcZ9JzysxG56scHTjY177XG
11VeCNnBguVVcpqWDxEjKnknRxD9Te5dkRYHrKqxdvT92BAamny
11Vkopb5K7PQYBWyjYWchkPSY5K7GYU2rfYmodwVPdptybWH8xH
11WFCRhScnw87oLVTnypzmxSVrX16Y6s18YeBvo7BjqnNyPLcSn
11wL4bzfHLMQDMxxq7Pqkec9VY2yyEn7tAwBgXTz44wP3AtFR9M
11xrWMuz5NiMAgxramMnmaGoUbAkMGpgrFfKb4eWspJWHVEmbby
11xyNnEbACsuZsw7BJkAF4yPttcr2ywdqXwv58L91ExZh4nCprY
11Y9mMMTgN796BFefJR5TXv6WJL8c2KpPELWGq6rMxPxKKkCwg3
11YAy7evB8za5EVB9nZhTDDfL5PKbusKn8ZRMpuwySWDbtwTPF4
11ZKfmEAkWdY7DT97jSAjpsERbKJk9YmM8q2Uvy8pC8QEjd2aFW
11Zxe2SQgAsrJkvHzMk5QpLAs2qF18wRVXMNEgbBeAQ2P46S5AU

Please be honest because I am trying to help to prove you are not cheating.

Most of them are, see the list below. We mostly install hotspots at regular people, for which they get paid a share of the profits. We also had an external partner who installed these hotspots for us with the same agreement. They however did install amplifiers and did other things they still not want to tell us. The hotspots are still our property, so that's why they are in our wallet(s). We've been in contact with them, and all these hotspots are now taken offline . The hotspot in this issue was installed at one of our own customers, where I can assure you nothing but a Bobcat and a regular 5.8dbi antenna was installed. I'm not complaining about these hotspots, but the one in this issue has nothing to do with that except being in the same wallet.
1122KVGPUyuKNkT3nKuWNs1fU8x1uGVg2WPGrSBRfPRLxwqRjpx8 - YES
111QcCCGMRnDyLDPTgR1atFbWu7qZh5J6dbFPPGfsoydTsak1qz - YES
11266M4uDGWRr4sEH6aaV8WYTN8n9RDe4MSbP5wzC6Zdyct8ExvM - YES
1125qq4RG7NxZDKf6WBQ2gQuaH2C6PpymZqWj5mbSeF7f7BWShC - YES
1128H55ex9TJu5UnEJxAXDL8jU6maYxRkKVE1akMVKZW78KxVQsw - NO
1125iywX4Sg8bSkEeJEoB8xxwdvi6BzbY2py5f5Xhyaw34Z7QT5g - YES
1126pX3GysyzQPEc1m4uUevgkuGNjGCUmuSYExYQNnLn9gjVLD15 - YES
1122mi1ZCibrX6NLjbesdS1dt3Q4cJkpyL2TcwWQMU9pNeFR3MDi - YES
1123zFMedeUxzmKjiU3F3iJNvr7tuaJrzh1ZsoZZJwLk7FaNPyA - YES
1128Jr1ydhwW3YjwabqZnixLBvQuoufAGuXVGxpbk9vT1Ke93r5n - NO
1128YZ3iBVDWo68ioqqX4v4Xg2k9BMwQb7VE9FkrRKE3wNGgGyn6 - YES
11294J1S4nvabjAGMZAK62h5sHNCfGjFi1uUteZaPLNDkgGfQNke - YES
1129tJGsxQXaNpZeQxYEbVeMKKnnsVnHb779PiqyVqsPtTHkaQmA - NO
112adp8pqGJtvTBV4rdDynwvDgMbvrau4S66gCPoT6tDkNiNHSfu - YES
112ANvyhkaVmgzjVVcHNmT2Vk6s5ftEHnHxcvfpLMqooGRmA7YCg - YES
112ALVvvpgXoPLi6ypLdfbbUTtHATVy4jMqViKEnGmKCqRgmc62i - NO
112AE9dqZgVY67N75gq7Qv7Cz1ao9pRCGVDQHteM7jFTTnJ7zKdf - YES
112BbenDouWN4G3kUSreMVYBvhSEfS2H9bekZfXdvmmSUyrnzt37 - YES
112BfwACerCkhocHwjFFRKfHjBD5VRpFYo2QaDuGDdaakos3vzCk - YES
112BAp9mhUTzLEieYVimF91MTPB9tBVsNWihwtGhfiE23aXEtrxh - YES
112CsawENTHDaQg8o1skxh7ixR2P5MgT6xme6TEZAwLta6MSovEM - NO
112Chi2qxsUy5acMa9RwvQvYmBLU91cRcptpNYJyucCCxR1FfNYW - YES
112CYsosqcM3d9srpNjvEA2f7oWoRo5mz2cjQc5g7dhSDV6m1MLB - YES
112Ee35eDs9nd1bxqijj2qiQUrYRVLMfKaLQfzeRpPu86zVUSjoN - NO
112EUxpVzdk6Cx624acMezvBjT862xUUVPcYrwvPXpXf8qBBCcBk - YES
112cZUuLYZMT8zr8UUgTXG4FTUCGKPNRG9qo8whq3RrfyHTMatYW - YES
112Eg5dv3vrqDV6qCTjX9jWA1XUK3WaWzo3zFia3hbFpRs7SfZhv - YES
112EJLUwiVxAVZb3MRMARB1fob8Ge38XzE5oat8J8d7KaX54XeMP - YES
112eymLqEHHgmdKVVs7xcRnEgAUMuK1Ep2ruRj5KRMYZUiMDqie9 - NO
112FGowfrH7hhVPJrTWpR2sWzNXMy84c55KFZMJEZrt1WqJ1oHU4 - YES
112G5PHtPCpg9sxLKAWbcXJtHqHeT51s2kvoqe9ydVpCw4gTMGsJ - NO
112g9cdEGYZyhXv63h6zK3rnmcNeVmHwf3aeumv5qMF8E7BcrHQc - YES
112GfVDnjcA1LxDNtwX379webp86fGGSKNFHDfM5n1RAK9LoyAVS - YES
112gQrLVwPagNhbYzLYQdqDYYVJWxMgZLrKAKQV9fkKLSbSF2pXj - YES
112GT66vHaypPTfk85tsCBcrSbNE8Cq78vw9wwc9YG5ZnLkEvm2j - NO
112GTrKiSq5hu7fnhusWB6vTGRwsLs1Rcf5wLgz49U3EAPiweyqd - YES
112Hz1aTDjpo65SLut2UcBkKfUYjV3MK27GSzWmQ3w8aTrAMuvvf - NO
112hPaKgWTsZrZPooozZMAtWb73aJ9ByCKqV1j8XEiioBUKtJevi - NO
112kU9RTtkQ3ukhDjsZmuEjEd9UMC1iNSg6vKZKwqE5tmX3fMefZ - YES
112KY4uzpGTnnF4agmZbBYb4BMtKCS9N5v5dyDHR5izRjVeQ1kqH - YES
112MbKBoKNWTgacHMCrWQuXcdkHZVTjusF3kq149CmGzRzHSzym8 - NO
112mEp9ERv7F4oyNZW6XNNqoETQvPfvtmFaSPU1Heci1G2UdSkch - NO
112m1WaCPcCoESuR5D6qVDe3i1i8QbTmpLQCaPukoH5jKUS9Cr7N - YES
112NVfNBdBM4sQB6u264aQfPZi2EWuvgi49MFLHmMCJWEU23FoLH - NO
112mFUm7TgTrouYWaPs69Vu4YpqFtZ3fS16sqTLvAcrkXFKaYtfn - YES
112NCSrNV49sRFn4TGNoNrN6W9n9TKewQFmB4DgtwDwWf8vyD8Wo - YES
112nr2WnkiUDVAKXNLrN7B87HFe6AB56UKmReutoS4LeWguFaCyw - YES
112nyhUjFU4f5irLWcqYQauXTdNRFMzXGJFfdvUfe9x7VfMjxpTC - NO
112oHcKboDrHfpKtu5GE5PbTm7qbREUrrucUeXxk3shjRhzSaKhK - YES
112ooDao2FMbwY3wsDS2wvjgP9NEmyjxf2w84opaynSaoj5urhhY - YES
112ptHzFhYDpZ5ZknYzFWgPCzjGvv1UWTuH8fcfViFkCUpijTTvD - YES
112pXnJnx26419kiifb77caHjB35xqzQPGhQjUHsxBRmDAtEEMim - YES
112sYxLaujAvhkEriBnwurv2cMq2QDxp9BBRwMxJHWoersVnfV8X - YES
112tawTtSoJkCvTvHxgChuiK5fTD3UM7P4pQx5hcPKPmusAKqLTp - NO
112RgWGMmCHFMXuK7MpqVSXLVJ7ZypCQJuMsFEaEhd18kvi4fn3y - NO
112Tn1Hu2P9rkKxQsdBCrsunDiVwtspncPzKrZNt3QmYgunjbx4q - YES
112UC6Pv1Rs4KnxqEraiveFJiCwMu23qVAtSi3gRDkzXN9L5G4Wz - YES
112Tsga9iv7iqrtCZHg1gCnxFHxWx1rPVAwn7rAndbWDw3kffPgS - NO
112UD5SYGEd5Nh5iTzKfMk9tiWKD4aHBAdj4mwrcvm68RQgnfAvj - YES
112Uub9827Cudq5frKczzpbXtengHrh3GcmC7QzMBVgRdJHZd7nx - NO
112UX3ehQxa53PLNDdSYJrjtMdszn1LS9KcNTcGVZuMYMcvd73Qc - YES
112vnwhyDG91Cz3X2VFGV1vzZEKFJbqeUrdx7bFmstQE8d1DVEXS - YES
112VvHEybas2thSZYkegrkcx3LfktitRBfgNQA1KNY5NNpWpuLJw - YES
112wFM9K4y3ncx9ZKnbyxmYLWLDVLTF2ZiySDJFetttgmhRBz1Ht - NO
112WKwAcaGQWs7VNiSTwAiWFTw5gFGJLFQKPPY6wCi3r4cLf3qkh - NO
112ZeHC1AFSug8hLdNs5s67KsCEGkDjPCNdJNERVqFGwiDFX9dwF - YES
112ZEhcWemGF8ZogNhH4yXYGGouFFzji9tpwKtQHA1kv2PjdYQxK - NO
112Ztp8NE5ddr3kW2a3CcJsXnMmHLGH53VgpBWNcorprrLW5t3vS - YES
113ddjbfssgDhkK4bHhNXVwmDQ8Duf55KjvpvoYPyATegbXxoFS - NO
113KmkcXSxA2cdUt39YNy36PfomXA2be7ov7432K7zGRYDXD4xe - YES
114h6pJiLGSMSQgTwD6eZp89nqSKoarXBouSrRaJW8D9LLsb5j2 - YES
115HhuhFdSqciN1kGZdAChXT5xURqcHbT8BKJnHftUn1T2KERvf - YES
115ZSbXrpVVdieEzxHmtBJcPHQvufpDEnbL4w4b9MQdp6dDL1GJ - NO
117nmZU3sd83dS1HZh5CZRoWU5hDHwd5PxEPZAzppkbo9TQa1Nz - YES
117VgDdsJGepVodQ32oHNYs2bUEGNVRzuQYhsaYHZXnvBt27q6Z - NO
116stfCRZELqh49uKwu4JhTbGwsS5XNWjRnD1SAAZedREviBC3P - YES
1189fZNG5TktmRwPcTk5PWeuc2N827cv2X1d9sVkqx2SAkjRFpM - NO
117ypXD7GJiU6J1jJMdHfdMjgsA9kTLKXgtXWEedKzP7Hry3voY - NO
119EX75NyiKGTn6moVLKqAvuzxXqiFHuamkmdfNPbf19JomqgFt - YES
11AEVdZ8TCxaXe6WJd5TiKzysNEZiZCyTXTeAwGB3SVNWv4Z8PE - YES
11AADUigLorjYQxi8ejBmiuyjBoDZc2FadgtdSuNqyJzqKTWKe5 - YES
11auNpBo1J8Ep4C4zqUxfqYgWJWWL16KwnBsEU4CiJU1e59QWaC - NO
11bJhj8WmhnoUvhNSTT4fpNvdJgyQZFiUmcd6LTnfL6gTT9b1et - NO
11Bo8MwZZfies6jga3WrZKwUn215j3dmZ6EC5ynkSwefN28iCvN - YES
11d4jQ6YXJqy82zHVtThYgTvZm22xEoDzhNxzFLF5RdjtH3J1RK - NO
11emwhtFypyDpCX1MckvYk4xf8BTUsH62WQhQaq9KZamNXHbQJS - NO
11d8MkdfoVeA9q5xMjkimE9JnMCSPde8drj31Snc2SvT8xJR7Gw - YES
11eBiT9He3seZXxmPDJ3y8ZQnLsh7QLj46hv9xawreH5F4nRW9u - NO
11EUgfkFyDWPdc4iejZA9zv7f2JLD8n7TaNYv5TxzvYy78xCkxY - NO
11fgMsCbgMrjtziVJGst8itpCgJm6F2B5hfuA23ET3K5Tp1c6rm - YES
11FYntHK8dZJpDJSVtWJuD5wYZDyTrSuXtbirjadm8Dw61k6uw3 - NO
11gLTK2LDKCfYjYxyKd5vNV3ZF9rjhsH3czqoQi38wLzP7nYA1P - NO
11gsd5n23BZZ4k26oR6do89ayfj8faCryBUiTEJ6hLjYcunk65c - YES
11gz3cEhCpLb6BFtkKmro91fKFpiJYTNdimLNV61pS4dKWJo6j - NO
11hc56LBbv4BbvPd2uPTYif6Uh6J1CKw72yyudyRBxmns1GxApW - YES
11GSBo1X8L3Dj6QZwWMc6G9Amv7yz8PGhQZJ61mXapJxJsRvENr - YES
11gvtnxnYq936WKVXwPyb3JvhUbJGPg4TUNYTyVthX9N6rjVRy5 - YES
11guXbty2fmvys7XYPduVdg73eUnHyTGQ6NUfRcLEHDyqzZRorH - YES
11HEqUUAJLq39hBeYbsAyA1rk47Sub9eXrLqXSYai3JhsirdEGe - YES
11HFB6ZYgF6uAzA9K4Q7THwfkS6QvfFW5NhZ3SsU5Dcd7inhfei - YES
11HJEit84xxJJ1uYQfjPcjf3TN8mGFmDw9daugJhMiWtussySkM - NO
11Jf9AdyBf1FiEWE6RaLXkXK8aMmShFmkz9SbpBJXemYDqT2k3r - YES
11JGcZsc5Rw5j3RZ9mpibZDWoXqED94xdoR8v8addcrHc5uKKaw - NO
11jFCwqwy1Zxy6iiHkrZzJGTey2ZwSxLPSFV2ikiMEQX47Pe6Rk - NO
11LqVRA59mDP9teb9RGYp1n8jFTyRPUmsoQPfPkLqsT3v6ptzYn - NO
11jYNs9xi1DbugFVmRMp9Asx4GqcMsRR58cmWvGRSALAtL81qn - NO
11JHHtYUmNGZJr6z4xGoTRLatsdg7FbLtiZSsoC4y1FLcesTayp - NO
11LTqgHYYgWc6HuSbLkDxWCduGo5PVp3uHSFJE8xn3vxBNxh6Jv - NO
11LzMhFdzLjBD26fHyp2xfK9PufAsbrRL9yJf7QGppT5ssLrzpf - YES
11MEX5P3uRVzCgywHxiJ1m8ufMnXxau3zUeKGFyWvhaJDLuixmv - YES
11MLt2pDS4a8x5HG6CjAvULA92XAqAgWvF5KFWU8VESEBVNPvXo - NO
11MutaWwgVe5PD6m8t2htK74XvdQGWK5YR97C5LDcuhe1EhqD8H - YES
11nFzpbu3A9MnaWiKkmzBMWc3HevVLbD8w3aS59qCtgfx6Drir - YES
11pZBXHeMC21NJAYQipXgnrReC5SwM5ZPRXqi2ucrJScAnguFaY - NO
11qQ8YFSmPQPghdeeBpmYHq9ubi2RVa9B15UWrSfQyV2j7EEyVT - NO
11P7FMf2rYsuJVw9BqAhCPu1qNxKs1BF8tAq3LPmpuX9Jvu9nSw - NO
11reB6jm631qyaAGJ3rsiChHLw47EUMPgf6LXtARAePzRjSnsmP - YES
11NUcWhnv81bfUTLiCRaYkQr8QbZW2L3kBWH7KZFoRCmjaFHRJZ - NO
11TAExi2FGBTnJxVDN1pejx2dBZybJBmFUXKxEUmrDZ6gmi6hXf - NO
11tCKasEWiUt7NJsF8QYNKWQnS92t37tjwfD73E9BC8tkk6R9hn - NO
11tHGZ3rZZbUaJBphA8euPMPehkRYT21ZT9R6iq3zWtxjUVY78k - YES
11RN2LaMFowb8S56PZnv98s57KD8zUy5X8EZi3dmKdxFSCi1kiJ - YES
11UR4uEMkcTuAeyK9i2h3TgBt8hALTiPYJBcXV6UW5GbhrBVdn9 - YES
11Vkopb5K7PQYBWyjYWchkPSY5K7GYU2rfYmodwVPdptybWH8xH - YES
11uv3NDULLsoESL4h1qdzbBrJV26psM6Qcjsixy4wdVfnNGDioQ - NO
11vd7AUKsuqMiRGFxv8gWZz2mcviJcZ9JzysxG56scHTjY177XG - YES
11VeCNnBguVVcpqWDxEjKnknRxD9Te5dkRYHrKqxdvT92BAamny - NO
11WFCRhScnw87oLVTnypzmxSVrX16Y6s18YeBvo7BjqnNyPLcSn - YES
11xyNnEbACsuZsw7BJkAF4yPttcr2ywdqXwv58L91ExZh4nCprY - YES
11wL4bzfHLMQDMxxq7Pqkec9VY2yyEn7tAwBgXTz44wP3AtFR9M - YES
11xrWMuz5NiMAgxramMnmaGoUbAkMGpgrFfKb4eWspJWHVEmbby - YES
11Y9mMMTgN796BFefJR5TXv6WJL8c2KpPELWGq6rMxPxKKkCwg3 - YES
11YAy7evB8za5EVB9nZhTDDfL5PKbusKn8ZRMpuwySWDbtwTPF4 - NO
11ZKfmEAkWdY7DT97jSAjpsERbKJk9YmM8q2Uvy8pC8QEjd2aFW - NO
11Zxe2SQgAsrJkvHzMk5QpLAs2qF18wRVXMNEgbBeAQ2P46S5AU - YES


text:
[Addition]: 316 HS in selfwitnessing only clusters (TW)

Hotspot b58 Addresses
113vcwGXUXZxR4rLn9XjSuZwLPjs6ZLgnPd8bbVFT15AW1omD3s
11Hr2f7ZFrmqSG4faGpkmgqmmHgBrCzqeKUcXEmRqUUkzKKKE2q
11C7VMpBk7t4q1eR7CERSUk4m5Eoq4ZcMsN1K2jF2ZLZeBQn28H
11TkwWBmTJsb7ZXrvwqhFXZXZqQDvX8TwdkPe5PR9idxghcyaBV
112Y3izww8t9kPXW8GXjACJxNwDkm7aCSFn4PoHDDV7d7zQLQm7J
11KXWYpHDWysRem8Mm2B9DYA9opKo11cbn6BLBUph4H9MiFrZKw
112KMBaE7izhYeSMyuXXZxrGS3ZeQ5TFjM2xgRdvbtFDP8cpGm1R
11AUARaGmwmxkBQ63VjbcpVkvjjm8qJuyuRJonhX4R8pZazYtAx
112urmJ3ToLCsCGtS9zjmYNqJxnvqdrTs6RdyBLpRPPMdNsvDtuX
112pueri86J6jwmvdW6Hsd6CABmjBX6rMpkR5X8LSqXcJZTzGLY5
112EJFAHsSjq1UB3zo6pPSUgZjXAwase4U2UcLpwFZPMsET3b4rB
112RVzDxG3BrHrgmX8kMLU5v2VjtAvuX9MXnCC6BPpPCdewQ9QnY
1129TuJ5dKs6vCMZR15LQxnitP65BytV4zK7YSbh4RhWzah5kbAi
11sVA8E9fuPSKykfvCgKhjmTqYov3QjSsoChMWEMcj1TmYQHvck
112rE6Wf199m7VahG1zTA33tjtA9k1R2TuNFczj4z5jsMK4RHAaT
112LiQzJbdCRYX79puTrQwgyHKmSFS93dfmbLqNsup288uAAbw6a
116Xh17gqG1bLhcyha9EcRpBEzRAUpcr6AxhNsXX5nL3UwU4Hen
112BMDEgEbE1bMBMsxvKCWDgLxoo9PHcNo7Pie7QCWzWFg8U9xHK
11Vwdhgb3PT7otM99LeYRT32hrZE9VZ7C4LrpAxMs2BNxLUXUai
11Y8i2cB9JjZWHSwuTEcjkMHENFxqojZ916zsJSVUU6NHWC7nQn
112KgNqeWMid1qDHg6PeB3KGjCSFEc2fj1zVPh8KVvAnzXMxJ1qg
11AKbCqqqBiPEicu2JqgmgYGMdrQXg5FtKTMF4ssYMKrbNqizU5
112rSJEDrm9PyEwDj378N9wF6bhUdEYZ1sZ7CGuCyP1d3ukbXKWz
11H6kMe3jVRVcgTZA5S79gvEjWKVst88erDHLefrnmrLoAdEWRk
112CbvEHVBSiu1pPguMCCBJrvgZwHkhu7YPucGnNBrUfik9VVZP2
112Ffn2qRfGrSWWiEqSxJsj3Sie5XzKjq1Vk1byc136F9iatj7SP
11y1KEZskm5eevVDWnWcdFBxh2QYus1S5vP4WwSMyv8gEEFhsXJ
1128WhWjnYnMXBnfhyWTzh2WG7uVptkXrHaJLty78Nx6hWPieEuS
112nd4KxviGp3ve7bHECvZK4FfvWKcHsaC6ZMMnF9okpYzmUXBK4
112b8AXm26Sw7Lc2kQsiW1L6g6EkVMVLD53PBJBJ9Si9WWCmbZRY
11Vp1H7jXos89TL8yxBFPothJLAyV5nV4YzCVMyye455pJxvg5D
112YsiRseSywWQ7n8g9q8hTGi8B6YWyM8TZ5rLQkPenwXrCRVySv
112Jie2p6L32LCBzszN4hQ6Dfzt4fMqafzREm9sMJ8ZsRNccJUgz
112WifRKpHXun1pR65yRx4YUWgurJmjeeFm1BCSEWKBMq8sogG4m
11F5mpP9wFHvPEhbVt9UPcdY1V6iKqbLKtXT64PPBsvgVEF6d5U
112HLAzjsrEEn9WMccx89c14rNb8qX5NENtJQszJ5eQgaWjaEmi5
11dnGgE6FeTqZCim15zW78PBfutxYiTrk7p4rLhxq8Yfkgwc8zb
11pk5ki3vuVnmRfNpAtRkYrshNAUQAx9EK4ivFz6XTjjM1oyB4d
112WLuG7priMyowmxGM4LNUSioPQ3c6SjUgA1M7iKUU2iVPgvhF6
11SyEFV8nswcdhDVmx9WBwv287841FPxSHsVgz2aNd8rLdzWwM6
112Rc8BZ658ARBHwCJbCN4k56usM8qrASSghk16BSWZ38BqPjxnF
11ypTd9nqkTHbKy2b3RFbAwfYmpKA8Vi2T7zx4vUst8NnmXqXTS
11RoWnis2ioxqNyvRvVfGGxyAf4f3jZxshrinWRTXqiG9ajskBi
11Pp3khYH2tQLE3mNgC4SbZrZSMWK7ymxvkofEK8U9CHhTCU3fG
112LyqQzPYg5QaecRyT2U5cTiM96wZoaNiuMCvkzTpquAy544WNp
11u8SqM2ykfGLPzEHcLU6M51fP29MAs2qNc5sDodyA973sfLKUG
112Eh7Hsw5nng4bnhA2HZwYMYWFtAowKmbH21Hpqjtk1C1joRG1v
112ZikhKpttzUdv9TrWfMvkogQN3kER3ukvHiqgymboK3ULDrw45
112Xq7W6HhfsbVTq4rFRkWHsEouRBVZgKWuxvRRoYrRSYSDAKdga
11ct2NSBfttZanXhVWpW7RzFHgBcHMd8zFiKboeX6poa7qtwTSi
112sAtgjbdBtRjNw4nwWKrHa8xwqLAFfetQLtBn4s6VLH1HBy8Qz
11YnNoBwYv8FnJ6Zjz4MUxczS7VfAZUhwPRSXRgS81z8aZFsE9u
11FDUzCTya5kVTZkjRRKBFQkRHEMTmeno2yE3iScMjHgBCM77c9
112Y9mknddWg97bp9ZikpsbDYDiYQ2B9knBEYVC5zSrsFUSA975u
112tC8VyM48mTP8pNfedk3WbHKgotjNUwjHNRTvkmUUL9SESq2tn
1122o8vG7tVc8mygaeqM1Bw9UQCy17KU34oDU7GnMxkDgqPDdBC9
11XaheAvpFRGJVF4tKTtfVrbYE865GfhayZUMaGAQ96xasSy3px
113ADjiCLuRHBGx3zcWQt4rG71pnEBU48Petqf9iaciWPNn9CZj
11E3UUvPYZRNzgeb7bSk8Y1v1LzoHW94smmgBxPNbvkDREDcrG6
112qKXWBiFNZhC2t8BQL1odyiZGgP46zXufRZ3PnkNn2tnuiJqXx
112BysVWdnadyg9gtfW9tchqWVmnrSqFmn9b7vfUiGXjEAXjqi5o
11YLs8moqc3fQxaTayiHK1bdB9bDwrVXQ2bXn6yu8TioDRBLxKL
11iLMzmfdSJLrcBTRMjmuGH5sxCqRW1DuwiVJEPqnwo842f3SmD
11zpzLrS7e68z1LP6P19eLAKGBgvVz8RspEWnAWLHB6SrtE52E5
11wsH1vmVYAgjU8g6fuqKAFoSifpPBsdkmKpcctszdidhdPXXwM
112ctV2KuX1rZVbaoLV8kAoqcSDLQZkdS2PJ8rnrkgLoyPZUHNu4
112PXvE6E6XFu5LEjwDSVXS37CUTdQZHCmvUPcU9hu8JZhqqAX2f
112CE9VZQt7NxY7UghPFKFRCVS9huc7GBz8rkmNkQRFvaA3cUiJw
11qCg5M7CVwGYr8cxGfTnXd5NQtXgJ59VGVRdytDKREmwKMzVV5
112PrEoPpymw354ZqW1SVzJWqQFrB8uMh6avMdTwr12GqnzkajAm
11rbHz8uDYnbQafbF37y6spu7eoxTuMH82J9y8CmnV1gpEhUrCP
11fwXSNxDRSgBENQYPpXqBFVdheAh1cYyX3BcBWQ7RsPLDB1uQi
113CFST5Fcz2yvCkXJ7UbwQ1qP23JuvVXcQfsNYc8mN5JW5t9T1
112fHTc3wJaBhgUxY6tchVagHCiK4FpKGWQs1uYM4Bfty7SWvb5A
112LwxAn9QoRnHKif9g6vYxnnN4sJmoWg5CWJ53Q8csKKjdodSLw
113Qv2MVSjMoMokk2791nkoniKQ3kGZh4LUqhz1fbzQbEgrV4pw
11ixdDEdbBt1sDYEwtueXMY4pfi4f1x6debkD9ZEnfX4gsiLBtU
11DeYbSvhRBCF2Ub7nBjPk3FXM5toPLuo75Xb5xVT8aZqgzXET5
1124ZHqmGnnpMZqX3ZufTkvyZcbAAA4rHyUJ8CGHnSFijTPKHHBo
116KzUT95G5VCtcw2EhTPnvcpkDu8yLLKEfQqhxMGeGLyRxaCpB
112F21iyp116F4JXizzBuqUCRa4oJenGnVbd6ufxinBRUofpGU8k
112XSascGjEwyZPh6wmVnBfhyoLRWRbFJYRGa3aEwgNM1up5D6p9
112FxvAD5Vd4x8PaZMXjJSm7vS3zKdNMdfyL7zWnmCHMrL3sP6SG
112HddCbrYsfdtrNJix2rB8LJZ7x7fsuiTMvP1czPmJMCZjvnVgN
112mFZyLeAesdHu4HENrJRHfnuvkYvGfL3ZxSK6X7Ai7YYYgXLMf
112eMfmokSmbZA2JN3cjS2g7mdA2Aydcsi6ZeaYKnmASXXEB3pc2
112vTHeguKUxLFwrzskhUc46dZjeNzLXPZFABzQLTvmPh8r4fxkH
11Yo3jGwZfpgR8d5s3MaZ8oqTfpYMe1jbJmyScqMg19QkZVUZhV
112dytktDDNxoAxp2ppwY2GqhjtGjQ4oZFrRd68FkmdJwUyuESjk
11P8uKYVqdjqA3wJiCPQ6sPW5kEcUADq2pXbNefu1Wdt8egagNi
11e8WqwY7KnBzoEZXeTHAb62Eu4TerHsEWB1JMpR549hqEaeAjx
11bN6AxPoE5CcueQ5A3UFJ4moKEYCX5JA1aVF3TtmmgrpSzfpZc
11FqBxpuLgTMkiGu1TWSPru63Qnm5Whn7Tr7ND1WdfJ5cg3bEud
112K44tAAUiXtarzLNvhWfWKMcnxCSBvUHBk2MZMPXWVenDytYLT
11iUwqWsDS8nEUKpZ2wKFgiBNJbmCrD1JVhaty9Es6T9US7p1Tw
112dPKxuNMSWewWaBp4AGRyzJssShhDcwfPa16rG1iQn11T3n1Hc
11huJXTdDgrkva6tdxH5PKJ6wHAqqrHwHmyaVWbj6wFkSnXXvSG
11bjm3xwGo62phoW66vQSQTH9Jzjw8XNu8k48aCbvaapf9ckMjz
11anfpoW7BPH1eav31jXjqNini1DwX8ibdPRFEmqu4RhfjrMCU7
1121T7rxz443Xi5rxijtoyLTTRSC5VXTZTmD3KPD9uSjqLbevKqk
11mx3aB2pcAiyKEhrMjWRkFU6zN2BNkyAhWi8w6TWCtSrrct7nz
11hgfNzwV3jojwGrEPL44ucsfihzen5eWcG4hiY7jSArexaAwoE
11jUTd8siHoT2HTcivwqxt8EewoxYw5AGwDEUPSt1uPc1ubrzyy
112UAv66crqRPxJEvxjhEH3j2Ut7yopAuZWNVjUrvjigP4cihiRi
11tkSjt3D6P5XwVnoCsqhH59x6SZNfUq1jaMJxsNYRoYAcRDseA
112PyZac4zrnqSHKc6PYGcQuVJk2QdJ8g1xcVKxYbPZJ5D2BFrvv
1129L4r2Ffu9hVc5QHmrZiB54QDw1BjpEDJdV8BMQYsPSQVgoqmm
11t9MoQVai1tJgmji6s67m6dkmTYYMdqfPokcE8JTTMvzveiV3i
112whdEipySLREej1fPDdxbWJ2G1y8a5ohUCd1fZ2o9G9N694JQL
112kVJP23tLdhLppPLWnWMpPGFwD6hgF9TPRhAhqbj5GdX1yzsYV
11NVrKjfKtY6S1qd7stWvo4ZcW36AADEJccC9gE1dnNC77CjDg3
11YMFUXNFEgj7vNCwJnwdDbbckiyAjwaeZx49BpxApLsTxeRXx6
112nPo9Cm5MZ6ntpNdguxNzrDvGv4ZPAxWiu1pFzcQ1xL1CQ2TYh
112FNYF1tEEAAzFXtGwdaBPsx7UxPqFpAZYKsThNofNrnVb9jMCd
112c1V78tGAJetRtYqSgzaJKsJgnZxjzWDGUq43TS9xsGUX31Qnr
112FB4pK5rQQr6EZvSGnZRBHb3ZSsrn28RyAJfniMaX6UcYanWN
112DaPTfbBvXERhYC3d7UtbXisAW4YkXS8uWKCuFoeeTodfJpmtn
11DU7rbbQLbviFnjnQ5bZfU4NakQvJrLdhEAQE9RVi2EPbxLW4Q
1183kw9MiMYeSQpvnHtSkeQcHL4gjvVeooJSGLvs4UxjySgE5a6
112gQ8Z5ReuFpo4joFHLTkqXai88mLem9Dy6nT36LTqXYmcCFdPV
117WccU5ESQVMk4MJmo7GN3sP1XKDW7Vuz5jti6t7oo3rLvekzA
112Wp3pbNzPwJJ8CNrxQrrT2762TmGXwksvk1rsBsK2LpPRu5vza
11ppaoUYLRNA595YBCCUsnqTux8fRBMA5rPN5ZaLkW1NEkD2BVq
11N3odcfU92UurngaBYHzboPXetoXtf6wzQzXwf1B79hjT8kkvK
11dB8uW6f4TWw3G1ZEthf1qgYDcbxaaFiLBgUnzWKpxzKkKDc6R
112AmTLMHiQ7vneKjuirykfsePnTexDmi7wGXsaiKTJ24GUnMfp
112fLvBaedsEi7cC57Xac5FCyyAQrkbGt5bXiHoZsjAxXvBrLKhW
112UHFddDbDW6DrfwAgY4TCp4NGzN7wxYRf6fc3E3DacSeaUnMmj
112LP3XZYmJP41exrvVnBN5MqPdmNkiDLmGQ6Sjgz6CGWtWK3Rbu
11MHAt7HMSrd423K7vYLcuAdqgSkPgkVBKKLnp4wJFSfsAs93y5
11jkg3FAW5jogKqvjGorHWDwDfnBX8dPnuHxHWewJd4zdwvnMQX
112fEq6SXxZnKHNmTb1JRmVZJNbjZYowzeQ9fXhF9KmZaarNFpFP
118D3VJwRS1RY95gvafVWfymSS96hCgrkEYcPyzUgSpcni6cmHp
11VFyXZfTFHFAB6ypBGku9Y8etc6h8TNhqehwZ9EEYYBVoPia1E
11zykswuMfFFSDgPQGa5JSUc2JarpvmNfJ4tWptXTTZNJ8W8m79
11Nzdx9vtbbpt79XxDVAKpr9sDUKtmecXp4PoFZXupoRA6p4Njr
11y7fguhMpZ358Qp4dqgPtoRcNiR3hmPWfKiFdRRa6GePfJywFv
115QQ8mrp1mfNU7owjgyqQ6dkQrRsZT8N3fkbyU58CcJZSFh4ow
11AriePVkJVgHtRmoiQDHSYS8JTYmpjcKr2u8k6P5LtyCMZR3UN
11nRrQpkSwdasyN6EajM5okAvqtV3DnygAuu43YAata5HfKMkiR
11HRt527dySX1WVxqfEtuZBy9vTZzLzqY4DNzJo7NCbf2rr8jfL
116rVT2beRiZDN41GERDxH6RV1XKMUjD8aSRw1x9qK5EcEcQFHB
118yGbcYKLmpEebbiVNguw6f8tegohqKa2T1VpgNABHzb3H8VGx
11rzhgDXHp36jFCPY7FEgaom29uzGbb4Y5dqskhMRdSMEwJdUBr
1121aE4bmfUpqhRfQdTAGkmXQFW2ZTpMmMLxPBBNFAgMpLvXW3bH
112afEdQdXKibmyYVg8op5ieANa32YbXg3DbA3wn2pxz3hDqmkK
112GTjb8njhciHEx189em7LVafSriN9vYtetuPmw9ycxdFWTzzs8
112qu6QLzCaMLjVcZQLVf9adHgBvdKoQo7MB3aKQuQeAshjBgD3o
1125kBuNznHLDrNUUkGGkfDc5f7Xz7UVPiq1aPYxr7WhRUeyqrsx
112j4ffMoP3NuFNfWohdhPAfhWQ8YrhRBDg924eCrceMUauakXGU
11XzW7CzEkqNpAVUVsbExXexVkaAMTs6kDaiXrEweC49iBhPLis
112QHipcXpxgEXo69fLZACr7ryfmQLgYPJmdeNFG3JFKwCrXfPMy
112sH53xqYi1RDzQyFbqH1Lw9qqD1KVMADuUTFhgVN8bbPyQDXHS
112XjRpnw2FSPYGynTFsea66g9PU7wcKk79hPsqfAqP1Purh8P9G
112WbUT5VqLiu7i8CG7GcLLXE55x43W62ujwhcYeLoREWSm1iF1f
112ho7MXajnMCR3ectbyD4EXp2iNJ3HMsA6yrbQgMDNGhE41E5DN
112PYPjpbeoT8sKAWKRgC8rFewySjpiVRCLi4eTPpHk83PNmw4kG
11wGxy1LVSw8QVjKCBuZzrS1LecHkRaqea5f2au8uFrUQXnzmMQ
11xWVhFuM6b9JGBEqHgVeiWoQ5mRWGi3xgy3KKmuWpsDudvP9Ks
112Lfmyo6SYiKtXN2kk9om3yKYsCTc45WwTVBpc4X1qbUiEE8UQF
112hMm3KQCAesKNaVSb7o4RyReUou6mEqakyDMpZKmCwphzdGVRo
11vqPZGFuLCnkC7i9sm3bn3f9w9xjVs2wyegfgronRomNz6rTCe
112Fz5z3cFKVW96i3xeKQREGtsDiJUFsrC9YCcHXKuQudyA35TNN
11226FGfkQCsnFmphJrDQyoNNmHkKL57hmF58EaJGdvtF8Ev6ECk
112aSKMdgiAfjUxgDNy8sVay7F8puXAn9s8Z8bHr9qzQzjjJwDfv
11TSdYF1YiztRya5ny8fvFRq8wx9bcuXnDw7ixp8qSYYVf1DJNL
112B5ZN4gURyTTJhAY6S7kPMt1t9sUPk8sEfgbFtYzr3mWNgVaDE
112ezmyNt97yUoLSKQXkkXjXNQzUYy2zGEDZU2GsaXUyRbodeDps
112QAVAmMSAsUhUUeeqBrXQ1z2TrgvVuK8X8ukM6oB3Bp4rgtCDb
11F3Lbu532i4jHXmYWjLgjaQB33TE7S1Ybhgrw7m88YbmfXEVsp
1124uSgvy8auAFVWHHbdPo3iuKymF5ArHm9fg1E4JGcLyJi7UcD4
112YWKbhXyZ2EV52F842pM3YvvtFFXzaALMNfFcRqV1KoAVufm7Y
11kzZSu3586H8tVSDGAva1sFKknfMX4fBLXqTzkna8uMTRcta6G
11ymPBmdS9LL7W3f7wzXXFUoqx3RBSA8KqAsABmLkDahuSJeCu7
11wQ1W83tUhhGX4wCBtFKkBVCBUweif2Eo12dJM6VhRggHuDhMd
112sC4v7Y6w5JrhvNSJWV3zJizVcoYhuvgNnEssepzddpUekrgkk
11eehCCAxRHqXMdfQ1aCEwNWPvuDVT54ZufrSks1BgzRo3xCD82
112knDyVGs85sLhVfiGW9Hanuj6CSW5TE1QLjQSve1nU63vnoj5j
11rCpnnRY52FWvf13tsYfRQssap8QUxn7WB3zZ1wKV8jsnVbbRY
112TzoDmyN9YhmE7VLLVcfk9b1ZaMBYXM1jXsDimHj3CWJhro7Go
112Yec5pmRJu1DxjNz2kVrjFRrgfuyw5P8wko76Jvwur7nWHYtys
112hvwZvj4DK1492WxLgiv5akS8raRDyz5YB7e32PC4gumVn5Jks
112HepjiFbBY7S7VufJTGaJajNgZ95DDYsYwA2ykX1pnu6vAZssH
11NpgiYnVS8R1fyNoQjMgkkDfvwYFDd6ASNN65mZhbJLfeJzK34
11wyBNiqvmumgZnn7DqApyEPkXbUJepFaCCZYZ3on9Bvg7d8Tse
11PCa8mwTUGoCMsZptD9h2grKDCSz21WUXUJiXCVCdgTUFyZSc3
11CQ25EiypvrzGMmj8Vio6J6jdXaJuvX1J3NsdYxi3eE5JGf2Jg
112L6U3HFxBHeSrnG3civ4GZwtc49m61VCULv8R85kBv6Lbt88Et
112VmHZggGZyR5q1dwYdypMYjRWxWCcC7mv6A5JZK6EBGddAeJ4z
11cHcTB44w28bBTAeNVC7JmGrAfps7q7NgLPR7jS3A4nsNxmPZk
11DXTTcHTG9TU5igvCX3VVrz2aBRwgNH6HjPA7f4eDB5JQszDar
112VXdGSWvSWQXqiH6QkaVHrkieUeXVcqHNZP4YRwPgbjqekz2ZA
11tbuu3MnEaf8yeVhWPEycgRAGhcXRRqbWa9AG7DwWHhqZXWEem
11VhvzdgL1AtuZbnDhhwQoPLUrQoB693kmEYNxZhQbZoDhKBvwx
11ndcQikisX18PGeKeeb16MesQXPhQ2us1GWSEQ1PTaXdPRAooN
112m1T975q3E8vRkzdwY68jTk8yDZe7bsfhSHskHVSxZ4QXXTDQh
11hPEh2Naybw4jwcyfqcSsxPdbG9uacmPMdmoAttLppfTeWwU6K
112rNnyUPk1A2kfFcPevthf24MJY9bphHqqWZCsEpbioEirPEiWv
11zp1Hop6gRE49YLrGCLYQQoej79jMcZJWz7htT8jnL1AoTvn4D
1134QBXN6xDxWLBPf28gtcXbdz6Zpss1fDPQawqFv8XeYF6t4W4
11MLRWCbXgJkRuPfWCqiimGZwJcPRyw3tUxr1ZFV23FABXGoDe4
112fsWB6r1HaHipXtwQwHwNtjEzU8FT7VVz6wtYGF6wEYKb9fc81
112vN1W8zH2Jx9FzjCvHEtDEgWQfATWmRowXCv2zgoDunA3tuyCo
112gR2o3LUT7StSwQP6DqNNmDneJWfCKLsiSYnKemW9vyj3dZ3cH
11b3TAgDAokqMH9ZQzd9vh461y8GbagJLzayomCke5B1HSwvxQk
11cCoxd91bJoS6tqdEyN9GE4GqR3ACFrv8dvix6ZDmDkWhaJSZY
11x9Xn2cETuFvimX9psNm1herEHfUg4NpSnZHj6RCQYwcFSTemZ
11oycafwPYqPWN8AhHCBAoHFYZ2PTPwtHirxoQRxCBSRDwJc7ug
11CnjdJZ1TFPsXKVdyAzqC3u8fZwZdBf3x5ib8oe1kZyJ9g8eoX
112LCthoJZHRhdizdqAqRDvMThd98EXt3oNBzASDVq3hw1EhzGnD
112JbCLRJg47xHULiUYiJMZSEYf1XtEy1zHTqDGbMahyYLaW4p3S
112PUdwzqZdnkkxJbCo5YE4DnQDtnkjxqMBP4Yos9m2V4B4ZL8xR
11WgMae4VzxvGd2MkpQL1mfVkyVcyTA2Hz7j96b7NgrWWddMhpV
112uZeGKkbd2fZokdFHY2WVt68de5FJmACPvddshGL6knSrxKJPD
112ETUeVQo4nD29AitkCErT2cGhneiaDGcbufRvZjeNXsef7HcK6
118bCjSizKheCgMTU6sjPxbP3mZMQq69MEMd4CM1n5ZknWAuqt8
1128zx4T6PpPx756y9qPTV72zvv16kedZR8daD3WWyGxw23zf3UK
11QV4AEnZHDmX6NMKTscz9pdRZ5cQaXR1M6tjtUehmyNbuuhJ4D
11tyMFQ91Aa2837zehBZnMNDi2QSn26jYV6d1AU1YFtQQYAgFAf
112nJthwcx3J1aTL3ggRnjXAJfBWVfcbX4LNGrrDhyNsvVDXNGJz
11eznUUxntBzrrfReqroF9EdsEK8NKcSnNtvqujscX85AN4himd
112ecDroMaq6WrDpG95U1beNJ3Biqx2HGTuQYNbFG4yNFhXkkWyt
112scAZrAQAmsN5ZgECwqNj61Df63492SYh4rQrzL7KCE3Upg2ZF
112RgKpEKTj6yB2GReaqYfDHfbFNTAn4bRcvV65hSL6sabsN9qqw
112vyDnT1bYZHiGyoeRSpmYuNNXBAsqA8gT15SFJUzxKTmwjpBkz
11bx589EsF25emxrjhULq6cK6hdE78o7KZJeQfiTR5uC3r5r7T7
119udjQUcDcT5gKtKxqN1JM7VMmJx66APE1VZ6G1XiSUJTTR63g
11U47xozJPGYgnqPSEyEgyy7GxckjAGsz3cmodE15DKTW9UwdDM
11kiNE2YuVQw1y7sv6FMtMopAFBbXxTj4tyL6e18tDkMeUbbgi
11jX34fyyBFZvwvxpSFSoRWM16uT4sXaZd1KHTUSPogmZ1Rkzza
11ZextDETEtEjRd72Nfko6s5AQa5ETnxE3aywDGQkSvZe1bWtNa
11A3Dii965bxzpK9Vv9UYxszKZzqUpM1Pm4WohS96kzzp4JPSXr
112oYDvoMoKP5zCyugBjodaBN1aBerESvduAjsfctdP7jkoBr3sk
11J9Gbj9nmBkVRyyasqA6b1WxLLkPLzpvxW4QmMq2ybfFH2i8st
11Vstvwf6n8urTWAizRa5y7w8VY9PAMyXHkGsbNdmbZyf2DcUgS
112nXGFRUWXFbj2oBgwPoJPDGxsyAK5zfiS7kGxwdmEJWPwWiHFa
11yTfyfGdZKCXCY6mzPuRLrCmghMzkGRAuTCwhHid38nkxz7g2k
112RsLCdP4p1YUoa1hmMj6BjXbezbLUudA44uu8da4XNyervp3rm
112npyYcfnnYAgoDodNcxsUYtChAZ4KFCbrbbRzUX2erNQi4iDDs
112nCoGpoQMeW3HCbVFHuLWVr9jvDmNht5WUdhNCWcgScBeiZZGV
112GAvFEUY8eCihGPi4pEDyj6cMbZtC38mQ19zergtH8Kk4JQFw5
117wPNwDFxEZBEUnfzFcLefxQxydPPYMFL1QidPj6XJ6cJGu8jQ
112aGasAjhP8k59BFGeDPWCUyBPowxMu2VTfFNWq5E9FHsGJD3E8
112w8QTAojvjH9bU2MfRtqfXUgfg5HwFpDzHREzpJH2aM9vMXmGo
11QDBVzUXYP3UqEKuZgnibYcHgjm4sB8J5khfHWdeKWsgigukMi
112RMKyGDoEFMxuMme1JGjvaTA3K97AXwrNKxjQ6C799bjdFx25i
11seGF7aZSSjZd4v2fboSATtd6QkfQimFtsqHjobDaV67neVLwY
11fqMNTy6BzxzNFC4KdE4Hi5q4JaNsV1UAYXhAXwKy6DWnmTZQE
112cjCMSPTiN2VBr8FhVbRdAeLCprLjwLeZCcTsS3NoX3RjJg6og
11ioiUa3ryjSXmGh9ebYyVQiu2yQ6kYmje9kxRf84A7aR2cpbKr
11B6ttCvWv1JDMNEJPfBbTzf4dBMdUpRSiMKxZTLmiZ1UGQY82M
11SgUMqkXLHfRQiicAedfGZmHmbxXn429tdZZyTPfipptS64Riu
113UNL9cHz7WCaMSWapB9cs9DaY2Kj22Z893UEpCViSiD8WNY2A
11TbnLQPvex6qiRFTVaKg2gVGUvnCunibm5P8NC1AuqmPCNvvuj
112DAib6WAMikMjS8yufsL8t1wSSLG2nWKqG61vMj45uT3JRmcX2
112Q2tCF3eux4FoNBFUF4m819JftKfMyKEeWgDbQ8ynmWto2Vwfb
11NEhViDuwSRqAZCUCVvG8xhCtFSt8edUUmXkzpnKVJDk5dJrqo
11215zvbj8LKUuqpaPVEpH7nb87WFrE9wfArLsDtwn3SqTPRszDd
11gB3toBaDyyRHWsiHhhWTNBPKsAo1R76Jgb7w6uAV9rdUCiiHH
11AAg5h7y3HweF1BpZLCnHdznHCfEW5Y2wrSvk6WPkCf3ipkQMb
11bqrCPL7WLLVhj9FoMmdfVjj1YoqeebbMsa4wEShez1EgBUafR
11wyNox74n3f9639TBqD9y9WjH1tGSZmbobRK5yPMtK6Mw616g8
1128uw3eq5cpTHqhCH6xHYmUzqBCjhHtgp7BGQ5cVPueMFRKhtAM
112TmTQZF1PJLnVkfDis4jzRFah1mYzKTxBaBKTULxnmsZtcuXdc
11BGjbcqT474WP8HnMDcXzbwqpvMDkfoMo19xqTQKBCApRXBbG4
112S7ky1FtUrhWEcf95RYSNjUh7m5tm9RC32deytRdMAy4ZsPh96
114tteRAgJNgDKPJcwmvSJqRbYsC2xXDJa9LnQpx4vg3tSZt6NL
11iBBnuxoNbYLbygEWC4HNL6K9ptD2USW7YGj9eLutPtmGt3qdV
11241u9XwHhFfDBidnPPLfzSddTV9HA5XKQE3uNASJkRKtTo4iRE
1123FouKMiyoEPpNWDWNPLMQmXxYK9TRHEopsSnES8j5xaYGjcSi
11yzsZwXFSZB7dKZWuGMkTGDVJUA5hAXW9P9if9QvK2o9wwkA2E
112wi4dAxyAcFcFAkS7p3N57iMKmNKMXTtrE3PqFb9FiyQfGphcm
112d2qyjCFNC5dmWRcWR7QNNdHiXVSFjMDAv8JEP7qQxtktAT7Rk
115PN27epeLd1BBvZHAvA3aLozd1C1PWHs1g8BADSFgvHLxpVXb
112shPgzBiRhzxgjzSwzGjqB6VK3S1caot4bnFjioEnVUUEjWffy
112QULpLbZ3q29RXF8xmTH2pStctBDjxzceAyyvgPzNRxLkD8mmX
11tGxF1xSNQqrjRGiKuH7UyNcw6GCmC8oozVgW6rdxr1UaerPKe
11XpVjbZm2yUxdMa2eCqjS5RgQHAv6bXfkkSV4yPhXxAsY7QPi9
11LkukXZKXPBTsfsjA1j8s3s3E3Xd8L47L5QTnEi4f2TcpcWXZd
112ccRmC1SKVMNJjj69cVCy5UuQfsBoKXfAypAQnxBdgdoJ2WPdz
112qA4pGeBfoRPu7q2U4FwGUpZLp1MWLQo3YRkGUGdJfHkTgkQhw
112J2mAbaF3jBAw3m3Lty1N8GDa28FnU2Mafv1M7AvgfB1ahncSq
11wEyXvayykHr5826GsgXe1ezCZEEZZgcRqKVqEDfZVd632f6x3
11mEd6Rj6BAAF7icrxk1oDVJSi1fJFRNgNLF9HPVvjn7kMrUHoP
112wF56fRbdjtDsjV3CJmHHShGws7zfLUp17p4j7YheyAjMxyQyy
112YS6cDt4btT1EZAVCwvo5bGfgpi9iV6fpmypuwJKBYa6UhZybx
11MMcUAWcw8QpvsK7NPGt2MVBosEZ2xCMxmSJJrxoKcD3qhLQvy
112mvzntg88LSF1VPQQLZCdwRYB23qd1NmD9p4SP4ZojfXLoQWhv
112fRHnkgjoZWYTjYwAqsUKUmm4HiDQczZUXZENRiDmyats1Eu3D
112W2nmzkSahfKHq8mAyvFEfe87gC19fnhABdRrbP4Cvqsedyfb3
11264NCuPShRtRM43Vui4GxnFWeEsUNQRtJsz8cqgwPxEqFvjLCY
11qarNDPzSnbqKiTQfJWC1bfbRgdrrmmkcULcqmfAt5hbuqY4z4
112etDtc3c8to6QhorrWxKm8C11pLSU6Mj99sX49Ezf7ojmdXmd1
1126jrprRjoQaRKXKpv4dj5zGvTCyctnRYtCQ4Vj2wAqaFsVURCP
112bM7niJwf2Q4nB6ZCDZ3gmm4A4Fh8AKEtEaX3M5Xk76jJahiei
11tsV96tDvawuH8wPEkXjDtGqp3LmSqxkqzeTXZ3DXg7J1VKxfb
11kdaMW28Jv35U3211HdhtoPvoFwv5k3QToaEWFi9u4hkhy7v3Y
11CYKB5yBW9dyExXQM2hQu1htGbATxM2WLBjJUKq4EniJGy4eps
11jX5NByyRCa9YQstitT1aEHKoqmNvTjQ5KdZLuRNnEijyKaG54
118hvtm4yp1quGso2WFUudHQgC234LvaeAWQB6W4H9KmXmpi3vx
11penPuemyxMd66CkgBsRQAuZuwktFinYMCjq1zE1oYSTL1b24M
11GfjLRSSwzkH9EaGXxnZwWS4TySdbusz6T7W1R7TDTGHiPPMsM
11BtV5SBrV49rbF3YtaMCpf7FdCdTsENxo12qLBp7gDtAdsmQ5K
11PsQTv54d2WrG359B84tiBT4eM1DQd7EXjgpNgvUkHduzUNpaG
112a6kRRYDq697jMzZ7jrZdcXkD3NymMQYGk4KwQrus3YvLGZv9Y
112Cc5wtCXv8hSQF3cEUeM1CaGZieNUnb54wwLKUPz8dwwF8F1rZ
11SbrHUAnGcGo5VwdAE4EgvUiqsG5xQRYp1N8NtWR6pbv6ST3Ca
112h31fdZfdaeXG64UHiCXXj92W9ZjuSTG34ZM8b9gC6TEEshP2P
11Tw9uNcX6EkxwTK5EVM6m9HSLfTJnwqmE5h56fy9qQwubYwdsm
112RyNtzyT1BDHHKrdc8e7MjVfyTd4mGnJTwt3qtZUuX7X82tVqY
11xAw31sXWvPyFdVUjzxpkxgHKa3ErQtMpvtZM2jYccGQ3WB1Rb
11pWdKvDwZYf52epq41cCmXnr8bEBrXVnsVUvgFGgYFrrihgxPh
112EA2k6Q4hsHENC3Qkthj2cGpkpVdTciLb4etQUXm3R65xBKU8M
11eXxJyWp94mW3vaZjC7jq6FDYpPtTC1kfuSgL9aQBhSe3uvPKP
11gw2wWXKScWWPfS1c5UuDfZg1hG2d1A844mXTbun4ZRGhtYwUv
112iJ8RRaE9W2J79A7vfarHpdfdzuFUT11Ex7hu5kvo7ph7JTqMX
Discord Handle
No response
Reason(s)
Hereby a number of HS clusters which are ony witnessing themselfes. They also all have the same properties within each cluster (same brand, height, antenna dbi, IP range). All locations are clearly spoofed (some are inserted in an impossible area), and every cluster itself appeared in the same time span. Below are some examples of such clusters.

There are so many innocent hotspots in your list.
Below is just one sample from your report
Please check this one: 11PCnwNSAPKrfTAceSuqtodGB5p5EeYZmUuAHcm5kv9WgMQqKdm with IP: 124.218.133.142
What's your reason? You just search it by similar "IP range"? IP is not the reason, VPN is also not the reason.
If you want to report, please check one by one, don't inlcude so many innocent hotspots.
We are against Gamers, We ARE AGAINST ABUSING denylist more!
Hopefully Helium team or community could review these hotspot carefully. There are so many innocent hotspot inside, IP Address or VPN is NOT the reason!


text:
Show derived speedtest data on the Explorer

Based on the data received from MOBILE PoC Oracle, show

Passed | Failed | No Data | Not Enough Data Speed Test Status
"Upload Speed" | "Download Speed" | "Latency" values that were used for determining Passed/Failed status or last measured in case of Not Enough Data
Informational copy.

Screens

Thanks,
This will be a very helpful new metric on explorer.
I do have a question about the test's. I have a ticket in with FF about not finding any speed test results in my magma logs. I think someone else in discord had this issue too, but did not see if it was resolved. Did see an attempt in the FF logs, but apparently that had an expired license?
I really want to make sure all is in order for the next stage of genesis, so any guidance would be appreciated.
Also, any time-line on when this will go live?
Thanks again
Jim

Duplicate of https://github.com/helium/explorer/issues/1063

authors: TurnpikeJim meowshka

repo: helium/explorer


text:
Add node exporter to router

Provide more visibility for router internals.

Completed with https://github.com/helium/router/pull/480

authors: jdgemm michaeldjeffrey

repo: helium/router


text:
global-css.js 的变量似乎没有全部 CSS Variables 化

比如 quark-fontSizeBase、quark-textSecondaryColor
:host .quark-actionsheet-title {
  color: quark-textSecondaryColor;
  font-size: quark-fontSizeBase;
  display: flex;
  height: 60px;
  width: 100%;
  justify-content: center;
  align-items: center;
  border-bottom: 0.5px solid #ebedf0;
  text-align: center;
}

请问是有意的还是遗漏? 遗漏的话我发个PR补上来.

具体什么意思还没太明白，你是指0.5px, #ebedf0 这种没有 Variable 吗？ 我们目前只针对通用性的做了Variable，个性化的都直接写具体的值了

比如上面示例的font-size: quark-fontSizeBase;, 是不是应该var一个变量? font-size: var(--xxxxxxx. quark-fontSizeBase); 这个意思.

所有使用 global-css.js 里值的地方

是不是也应该var一个变量? font-size: var(--xxxxxxx. quark-fontSizeBase); 这个意思.

这个要看具体的需求，有些是故意不暴露变量的，因为有些样式是统一的，不给修改的

那是否可以理解为, 并不存在“没有全部 CSS Variables 化”的问题, 没有写var的就都是故意的不可定制的位置?

那是否可以理解为, 并不存在“没有全部 CSS Variables 化”的问题, 没有写var的就都是故意的不可定制的位置?

可以这么理解

感谢回复!


text:
Change extension for exported txt file

When exporting with the "Export JSON format", the file is appropriately named freeotp-backup.json. When exporting with "Export key URI format", the file is named freeotp-backup.txt.json. I suspect this is because the code says:
createFile("application/json", "freeotp-backup.txt", WRITE_KEY_URI_REQUEST_CODE)

Note the 'application/json' for what is essentially a text file. Perhaps creating this file as 'text/plain' or similar would remedy this needless 'json' extension?

Yes, this is definitely a bug and needs to be fixed using text/plain mime type.

The issue is fixed in https://github.com/helloworld1/FreeOTPPlus/commit/5918c90cd449f55c774842cbaf1e1728fda333b6


text:
[stable/datadog] unable to set valueFrom in extra env variables

Describe the bug
Previously I was setting values like this to enable cluster check advanced dispatching:
clusterChecksRunner:
  enabled: true
  env:
    - name: DD_CLC_RUNNER_ENABLED
      value: "true"
    - name: DD_CLC_RUNNER_HOST
      valueFrom:
        fieldRef:
          fieldPath: status.podIP

But after https://github.com/helm/charts/pull/22006 landed to fix https://github.com/helm/charts/issues/21853 it will only render env variables that have a value and not valueFrom. This caused an env variable with a name and no value and the pods to crash loop.
Version of Helm and Kubernetes:
Helm 3.2.0, Kubernetes 1.16
Which chart:
stable/datadog
What happened:
After upgrading the chart to the latest version the value of the DD_CLC_RUNNER_HOST did not render and the pods went into a crash loop.
What you expected to happen:
That any type of environment variable could be set.
It would be great to restore the ability to use any environment variable value type needed.
/cc @clamoriniere

Shameless bump!

Bump @clamoriniere @L3n41c @lucasreed

Fixed by #23080
At least on my end :smile_cat:

Good catch @josefschabasser! Latest version of the chart fixes my issue as well, I think this can be closed.

authors: gajus josefschabasser zlangbert

repo: helm/charts


text:
Allow ingress without host rule

What this PR does / why we need it:
Addresses the desire to create an ingress without a host rule
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #11770

Special notes for your reviewer:
My version change may be wrong considering this probably is a breaking change...perhaps the top level if statement in the ingress template could tolerate the new boolean OR the HostPath being set for backwards compatibility?
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x ] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md

Follow the DCO Details link to see how to solve it

Follow the DCO Details link to see how to solve it

Thanks, was just being lazy and trying to keep all edits online, sorted now ;)

/assign
I think that there are some changes to be done in config.yaml
And a new PR was just merged, so you would need to resolve the conflict in Chart.yaml
Thanks!

/assign
I think that there are some changes to be done in config.yaml
And a new PR was just merged, so you would need to resolve the conflict in Chart.yaml
Thanks!

Ah, so now I see why HostName was outside the Ingress block...it has an independent purpose. You sure it still makes sense to move it within the ingress context? I'll make the config.yaml changes accordingly once confirmed.

I think it still makes sense, I saw this before we started this PR.
Do you think we should add a note to NOTES to let users know that this chart is undergoing breaking changes?

I'll make the config.yaml changes to keep in line with the rest so, as for NOTES I have no opinion on managing this repo so I'll let you or another make that call :D

I will be happy to see such a note. Will you be willing to add it?

I can add anything you want but it might be best for an owner to dictate the contents and positioning within that file ;) Also, and again this is just coming from an outsider with little context to managing these charts, why would we be talking about notes around breaking changes but not updating the versioning to reflect a breaking change with a major version bump (again I'm assuming a style of versioning perhaps from my own experiences!)

We are still within major version 0, so lets stick to a minor bump. And don't worry about the note, I'll take care of it at a later time.
Appeeciate your cooperation :)

/ok-to-test
This is an awesome set of changes.
If we can get the last few small commets sorted, we'll get this merged! :)

/approve
/lgtm
Thanks for your contribution! Looking forward to seeing more from you in the future ;)

@maorfr

We are still within major version 0, so lets stick to a minor bump. And don't worry about the note, I'll take care of it at a later time.

I'm too late to this being merged, but I think that changing Master.Ingress to Master.ingress (and removing Master.HostName) is a pretty significant breaking change. The structure of the values changing should have been a major version bump.
Going from 0 -> 1 is just a normal change in major version and isn't life changing. Major changes require major version updates.

I both agree and disagree at the same time :)
going from n -> n+1 is normal. going from 0 -> 1 a declaration.
just for the record - https://semver.org/#spec-item-4
this chart is one of the first, and as such, was created before best practices were much of a thing. the major version 0 is a reminder for that.
on the other hand - this chart is a part of the "stable" repo, so this is definitely confusing.
moving forward - we are going for a chart version 1.0 that will follow best practices as we know them. this will probably include many breaking changes. we have thought about it, but could not reach a solution that will preserve support for the old values while creating new ones. if you have thoughts about this - please let me know!
in any case, i apologize if this has caused any problems on your end. we have tried to be as explicit as we can through the NOTES.
again, if you have any thoughts on how we can make this transition better - let me know!
i can also be reached on k8s slack if you prefer!

Would be great to not break backward compatibility.
After update with default values, helm removed ingress and tls configuration.
So, update is not so straight forward. Could you revert that change?
Or at least prepare upgrade instruction for those who use ingress?
Also I would suggest to bump major version number for changes that breaks compatibility.

@mrdunski please see #12935.
Instructions are present in NOTES.txt.

@maorfr
#### This chart is undergoing work which may result in breaking changes. ####
#### Please consult the following table and the README ####

Master.HostName --> Master.ingress.hostName
New value - Master.ingress.enabled
Master.Ingress.ApiVersion --> Master.ingress.apiVersion
Master.Ingress.Annotations --> Master.ingress.annotations
Master.Ingress.Labels --> Master.ingress.labels
Master.Ingress.Path --> Master.ingress.path
Master.Ingress.TLS --> Master.ingress.tls
Master.OwnSshKey, a bool, has been replaced with Master.AdminSshKey, which is expected to be a string containing the actual key

Do you mean this? I've noticed them but it seems to be a bit too laconic, so I haven't realize those are migration instructions. Also NOTES.txt meant to be shown after you do the upgrade.
IMO it would be better to move it to the README.

as stated in #12935, we are going to create a copy of the chart in incubator and work on it there (pending maintainers approval). sorry for any inconvenience that may have been caused!

authors: admoriarty jeff-knurek maorfr mrdunski


text:
Fix bug with no annotations field

Signed-off-by: Ian Hoegen ianhoegen@gmail.com

What this PR does / why we need it:
#12046 identified a bug in the chart
Which issue this PR fixes

fixes #12046

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md

/assign @integrii
/assign @lolimjake

/lgtm

/lgtm

authors: ihoegen integrii


text:
[stable/ghost] Change regex looking for rolling tags

What this PR does / why we need it:
Fix tag interpreted as float instead of string and support sha256 as an immutable tag
Which issue this PR fixes

Fixes https://github.com/helm/charts/pull/14199#issuecomment-496883321

Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[X] DCO signed
[X] Chart Version bumped
[X] Variables are documented in the README.md
[X] Title of the PR starts with chart name (e.g. [stable/chart])

/lgtm

authors: carrodher cpanato


text:
[stable/magento] Add javsalgar to the list of OWNERS

Signed-off-by: Javier Salmeron Garcia jsalmeron@vmware.com

What this PR does / why we need it:
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ ] DCO signed
[ ] Chart Version bumped
[ ] Variables are documented in the README.md
[ ] Title of the PR starts with chart name (e.g. [stable/chart])

/ok-to-test
/lgtm

authors: carrodher javsalgar