text:
[DOC-3397] Delegate 799xx release notes

Delegate 799xx release notes
For reviewers, previews are available.
NG
FG
What Type of PR is This?

[ ] Issue
[ ] Feature
[x] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

Issue(s)

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[x] Tested Locally
[ ] Optional Screen Shoot.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

authors: bot-gitexp-user brian-f-harness


text:
Update terraform-cloud-deployments.md

Harness Developer Pull Request
Thanks for helping us make the Developer Hub better. The PR will be looked at
by the maintainers.
What Type of PR is This?
Update terraform-cloud-deployments.md
Removed FF from docs.

[ ] Issue
[ ] Feature
[ ] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

Issue(s)

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[ ] Tested Locally
[ ] Optional Screen Shoot.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

source: gharchive/pull-request

authors: bot-gitexp-user tmacari-harness

repo: harness/developer-hub

license: MIT

license_type: permissive

license_source: github-api


text:
added STO Features Promoted to GA section to Early Access topic STO-6711

Preview: STO features promoted to GA

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://6564a30525e1944d23f47ea2--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://6564a809593b1156199a5023--harness-developer.netlify.app

Closing this ticket due to local merge/rebase issues, opened a new PR https://github.com/harness/developer-hub/pull/4319

authors: bot-gitexp-user douglas-j-bothwell


text:
FAQs: [CDS-97807]: FAQs addition for AIDA

Thanks for contributing to the Harness Developer Hub! Our code owners will review your submission.
Description

Please describe your changes: __________________________________
Jira/GitHub Issue numbers (if any): ______________________________
Preview links/images (Internal contributors only): __________________

PR lifecycle
We aim to merge PRs within one week or less, but delays happen sometimes.
If your PR is open longer than two weeks without any human activity, please tag a code owner in a comment.
PRs must meet these requirements to be merged:

[ ] Successful preview build.
[ ] Code owner review.
[ ] No merge conflicts.
[ ] Release notes/new features docs: Feature/version released to at least one prod environment.

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

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66711ec3a5c142ba7a41e733--harness-developer.netlify.app


text:
Ci release notes 1.42

Thanks for contributing to the Harness Developer Hub! Our code owners will review your submission.
Description
Version 1.42

Fixed issues

The Intelligence Baseline popup was re-running the pipeline even when the close button was clicked. This has been fixed so that the close button now dismisses the popup as expected. (CI-13779, ZD-68120)

On pipeline failure at init step entire pod yaml/object was being logged as error log for debugging as a result if any environment variables in a container referencing secrets present were also getting logged in delegate logs. Issue is resolved by changing the log type from error to debug type to remove visibility and added an extra log without logging entire object. (CI-13785)

PR lifecycle
We aim to merge PRs within one week or less, but delays happen sometimes.
If your PR is open longer than two weeks without any human activity, please tag a code owner in a comment.
PRs must meet these requirements to be merged:

[ ] Successful preview build.
[ ] Code owner review.
[ ] No merge conflicts.
[ ] Release notes/new features docs: Feature/version released to at least one prod environment.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66bfec4a2e7977d89ce44de7--harness-developer.netlify.app

Please update the file front matter date.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66c3a2276a73762f3f1a0b00--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66c3a25f8ec78128c21892d5--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66c3b5898ec7813eaa18941f--harness-developer.netlify.app

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: lkilpatrick-harness:x: nofarblueYou have signed the CLA already but the status is still pending? Let us recheck it.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66c409ab603491973bd4eee8--harness-developer.netlify.app

authors: CLAassistant bot-gitexp-user dewan-ahmed lkilpatrick-harness


text:
Clarifying wording on delegate pre-reqs

What Type of PR is This?

[ ] Issue
[ ] Feature
[x] Maintenance/Chore

Wording is confusing, cleaning up some small bits

Preview environment: https://ci.pr.harness.io/pr-805

Preview environment: https://hdh.pr.harness.io/pr-805

authors: bot-gitexp-user chrisjws-harness


text:
Update continuous-integration-faqs.md

Thanks for contributing to the Harness Developer Hub! Our code owners will review your submission.
Description

Please describe your changes: \

This pull request has been automatically closed due to 30 days of inactivity. If you believe this was done in error, please feel free to reopen the PR or reach out to the BT team for further assistance. Thank you for your contributions!


text:
Add case-insensitive and substring filtering

This addresses #9 by adding an exact_match argument to the search_title_filtered and search_title_filtered methods. I also adjusted some minor parts of the class structure and used black to format the code. I updated the README with additional information on partial / case-insensitive filtering.

Wow thank you! I'll check this out and then either merge it in, or come back here and we can discuss some adjustments.
Thanks again.

Thanks Harrison, I'm sure I've probably missed a few things, happy to contribute. Great project you have.

@calmoo merged it in, thanks for that! I really appreciate you contributing. I also added you to the readme under 'contributors' as a way to recognize your efforts.

authors: calmoo harrison-broadbent

repo: harrison-broadbent/libgen-api


text:
2015/05/15/django-startup

Django 搭建过程记录 - Harttle Land
http://harttle.land/2015/05/15/django-startup.html

小编！  这称呼太蠢了！！！！！！！！！
By Meriky (71829016@qq.com) 2015-10-14T08:35:17Z

source: gharchive/issue


text:
How to add LTI to Canvas

This is just a question that seems to be missing from the docs, but after getting an app built, what is the launch endpoint and secret / secret combo that one would use for adding it as an app in Canvas? Thanks!

This is a great question! I'll respond here and then take some time to add this info to the docs.
There are two key/secret pairs that Canvas needs. We call them installationCredentials and developerCredentials.
installationCredentials – You just make these up. The consumer_key and consumer_secret can be anything. When you install your LTI app into Canvas, you'll be asked for the consumer_key and consumer_secret. To add those values to your app, edit config/installationCredentials.js
developerCredentials – You need these credentials if your app accesses the Canvas API. If you don't need to access the Canvas API, set disableClientSideAPI: true and disableServerSideAPI: true when initializing CACCL. To get these developerCredentials (client_id and client_secret), you need to generate a new developer key following these directions:
https://community.canvaslms.com/docs/DOC-12657-4214441833
Once you've created the new developer key, you'll find the client_id in plain text under the "details" column. The client_secret will be shown if you click the "Show Key" button right under the client_id.
Then, add the client_id and client_secret to config/developerCredentials.js
Does this answer your question?

Now that I am looking, those original instructions couldn't have been clearer in the docs! Thanks for your patience. Do I place the disableClientSideAPI: true and disableServerSideAPI: true directives in one of the files in the config dir? Again, thanks so much for your help.

Also, another completely noob question. Once I have run npm run build, can I then just deploy the contents of the build dir to my production server? That is, without the other files for the dev server etc?

Thank you for these insightful followup questions. You're highlighting giant holes in my documentation.  I've updated the documentation (see https://github.com/harvard-edtech/caccl#adding-your-app-to-canvas specifically) for a hopefully better written answer to your questions. I hopefully answer your first follow-up question there.
I added more info to the https://github.com/harvard-edtech/caccl#production-mode docs as well to answer your second question. Specifically, see the "FAQ: What do I upload to my production server?" section. TLDR: it's easiest to upload the entire project, but you can save space by deleting everything in the /client folder except for /client/build.
Thank you for your valuable questions! Keep em coming you have them.

Thanks so much for your help and for this great tool!

authors: adamtyoung gabeabrams

repo: harvard-edtech/caccl


text:
[BUG] VM Backup fails when ceph volume is attached

Describe the bug
Taking a VM backup does not work when a VM has a Ceph volume attached.
To Reproduce
Steps to reproduce the behavior:

Use the custom harvester config

os:
  persistentStatePaths:
    - /var/lib/rook
  modules:
    - rbd
    - nbd

Deploy rook-ceph and rook-ceph-cluster charts directly to the harvester cluster from https://github.com/rook/rook/tree/v1.14.2/deploy/charts (our cluster override values file: https://gist.github.com/nistei/aa20a1ee9c3d740f32cb9be970f5abb2)
Add the CSI driver at /dashboard/harvester/c/local/harvesterhci.io.setting/csi-driver-config

Create a VM with a 2nd volume using the storage class ceph-block
Wait for it to be ready
Create a VM backup
Check the VM backup in /dashboard/harvester/c/local/harvesterhci.io.virtualmachinebackup
Edit the YAML of the VM backup to add an empty status, otherwise Harvester keeps crashing (#5805)
Error message appears

Expected behavior
The backup is successful and both volumes are backed up.
Support bundle
https://drive.google.com/file/d/1BAYLvvKv2sQUnT-IZBoKXzlLW2yyNo1t/view?usp=sharing
Environment

Harvester ISO version: v1.3
Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630): Baremetal

Additional context
Add any other context about the problem here.

This issue also occurs with Harvester 1.3.1. The exact same issue also occurs if you use HPE CSI plugin.

I'm also seeing the same issue on our Harvester cluster after upgrading to v1.3.1. We are using ceph-csi-rbd (v3.9.0) CSI plugin was installed and configured.
Backing up and restoring VMs with a volume backed by Ceph RBD worked flawlessly when running Harvester v1.2.0. I'm unable to verify at what version backups stopped worked as we did the upgrades to v1.2.1, v1.2.2, and v1.3.1 in quick succession.

Hi @rsjostrand-hpe a support bundle when you run into this issue would be really appreciated

authors: hbxx ibrokethecloud nistei rsjostrand-hpe

repo: harvester/harvester


text:
adding support for multi gpu and nasnet

NasNet is a new architecture achieving SOTA on ImageNet, I added support for it as a feature extractions
I have added support for mutli_gpu based on Keras existing utility

@harvitronix I think that add multi-gpu support and NasNet can be a useful for the community, what needs to be done to merge those into the main fork?

Thanks for this, @ikvision! I will take a look ASAP.

authors: harvitronix ikvision

license: mit

license_source: bigquery


text:
Moved statink_uploader.py from ikalog/outputs to ikalog/utils

This is one of PR requests to create a command line tool to upload
a stat.ink payload to the server.
After these changes, we will be able to do 2 pass process:

analysis of the video and save a stat.ink payload file.
upload the payload file anytime.

Here's the whole changes to be requested so far.
https://github.com/hiroyuki-komatsu/IkaLog/commits/statink

Thanks!

authors: hasegaw hiroyuki-komatsu

repo: hasegaw/IkaLog


text:
Running out of funds when minting tokens - inconsistent state, no recovery path

Problem description
It is easy to run out of account funds during a minting operation of Guardian policy as users cannot always know in advance how many tokens their account would be minting. When this happens at present the following problems occur:

Guardian does not report the error clearly
Guardian policy execution appears to be left in an inconsistent state
Once the user is away of the problem, and mitigated it by replenishing the account, there is no clear 'restart' or 'recovery' path to take

Step to reproduce
See description above
Expected behavior

Guardian checks if the user has enough fund to perform the required operation, and reports to the user if this is not the case
Guardian policy execution 'pauses' at the point when it becomes clear there are insufficient funds
In the case of the error of running out of funds there is a clear and simple way for the user to 'unpause' the execution once the account has been topped-up

Screenshots
N/A

Implemented in #2905

authors: Pyatakov anvabr

repo: hashgraph/guardian


text:
Getting timeout exceeded in the sdk client even when transaction is submitted

Description
It has been noticed that an 'SDK timeout exceeded' error appears sporadically in our CI, but also on mainnet. The transaction is actually passed to the consensus node, but we get a null value from the SDK thus it is assumed the transaction is not submitted.
Steps to reproduce
Currently, not easily reproducable.
CI logs - https://github.com/hashgraph/hedera-json-rpc-relay/actions/runs/11142264400/job/30964850632
Mainnet logs - https://production.grafana.hedera-ops.com/goto/5H7WN0kNR?orgId=1
Additional context
No response
Hedera network
mainnet
Version
0.57
Operating system
None

@konstantinabl can we connect the sdk bug here?

@konstantinabl Was this got resolved?

authors: Nana-EC konstantinabl quiet-node

repo: hashgraph/hedera-json-rpc-relay


text:
[CustodialWallet] Implement the custodial wallet library

Implement the ADR described in : https://www.notion.so/swirldslabs/Custodial-Wallets-library-25670c87033843729271dc499981b83b

Factories implementation : 1 day

Factories test : 1 day

Factories documentation : 1 day

Fireblocks strategy : 3 days

DFNS strategy : 3 days

Fireblocks test : 1 days

DFNS test : 1 days

Fireblocks documentation : 1 days

DFNS documentation : 1 days

module implementation : 1days

module test : 1days

module documentation : 1days

signature implementation : 1days

signature test : 1days

signature documentation : 1days

pipeline : 1day

Pending align name of npm package with Greg

authors: AlbertoMolinaIoBuilders adovale-IOB

repo: hashgraph/stablecoin-studio


text:
Add support for server hostname checks

This adds support for enabling verify_server_hostname to true in the consul server configuration. This is a recommended setting for production consul servers to ensure that agents can't promote themselves to become a server using the client certificate key (if verify_server_hostname is false, then any certificate that is validated by the RPC CA can become a server).
See https://www.consul.io/docs/agent/options#verify_server_hostname for more info.

is this a common enough setting to add to run-consul for all users?

According to the docs, this is recommended to set to true for any cluster that is configuring RPC encryption:

If verify_server_hostname is set, then outgoing connections perform hostname verification. All servers must have a certificate valid for server.. or the client will reject the handshake. This is a new configuration as of 0.5.1, and it is used to prevent a compromised client from being able to restart in server mode and perform a MITM (Man-In-The-Middle) attack. New deployments should set this to true, and generate the proper certificates, but this is defaulted to false to avoid breaking existing deployments.

So I think this is something we should offer in the core. In fact, I originally wanted to set this to true without an opt-in flag, as a production cluster using RPC encryption should have this included. However, as the docs mention, it breaks existing clusters that don't have the proper certs, so I opted for a feature flag instead to maintain backwards compatibility.

Tests passed! Merging now.

https://github.com/hashicorp/terraform-aws-consul/releases/tag/v0.7.9

repo: hashicorp/terraform-aws-consul


text:
List of editor integration guides

In the documentation section, let's have an editor integration section.
We can list the common ways to get editor integration, and consult the relevant people for the proper way to do it for a given environment.

Emacs
Spacemacs
Vim
Sublime
Atom
etc

Going to go ahead and put this stake in the ground: don't recommend ghc-mod. It's extremely fragile, wasted a lot of time for beginners, and most would be fine with just the errors from flycheck + Stack (for Emacs anyway. There's an equiv for Vim) and a REPL for the rest.

Going to go ahead and put this stake in the ground: don't recommend ghc-mod. It's extremely fragile, wasted a lot of time for beginners

Sad, but true.

Agreed. I made flycheck-stack because I couldn't get ghc-mod to work.
On 2 May 2016 20:07, "Chris Allen" notifications@github.com wrote:

Going to go ahead and put this stake in the ground: don't recommend
ghc-mod. It's extremely fragile, wasted a lot of time for beginners, and
most would be fine with just the errors from flycheck + Stack (for Emacs
anyway. There's an equiv for Vim) and a REPL for the rest.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/haskell-lang/haskell-lang/issues/21#issuecomment-216313297

for atom, ghc-mod seems to work reasonably and it's pretty much the only way to have advanced IDE features (?);

@vincenthz ghc-mod works great but is really slow for large projects (much slower than ghci-based tools) Sadly, since ghci, intero, ghcid, ghci-ng , etc don't implement a proper "ide-server" (with proper api), it's a bit harder to develop ide plugins that use them because you have to manage the low level process interraction yourself.

for atom, hdevtools is also easy to setup, but only gives errors, and not much more. the type tooltip  provided by its companion plugin is not great.
for sublime text, sublimehaskell also works decently, but is quite slow as it is based on ghc-mod.
If you only want error messages + notifications in the gutter, you can also use ghcid -o errors-and-warnings.txt along a custom script to pares and print errors and warnings in the errors-and-warnings.txt dump file. works to some extent, but not great

My only hesitation here is that the IDE tooling story is fairly immature and I don't want to give new people the impression things "just work" here — they do not outside of perhaps ghcid and intero. I'm a bad test case for Intero as my work project forces me to restart it manually several times an hour. (I modify dependencies a lot) I think it's quite good for ordinary users, albeit only available for Emacs at the moment.
Looks like there's been some push to make intero work on neovim: https://www.reddit.com/r/haskell/comments/4n27r2/intero_for_neovim/

I also restart intero fairly often for adding dependencies. I'll add some automation around that eventually.

@chrisdone in my case, it's modifying deps rather than adding, but even covering new deps would be lovely. Most folks are more likely to be affected by addition rather than modification as well. Automation for either/or would be great :D

authors: bitemyapp chrisdone rvion vincenthz wiz

repo: haskell-lang/haskell-lang


text:
add ListT monad transformer and relevant instances

Relevant issue: #54
Don't merge yet, some unresolved questions:

Should we include the Enumerator part of the ListT API from pipes? I have not done so here.
Should we incur a dependency on exceptions to provide MonadCatch and MonadThrow instances for ListT? There seems to already be the desire to incur this dependency on exceptions in issue #52.
Should the name of this be ListT, or should it be something else?

This is very hard to review because it has a slew of formatting changes along with substantive ones. Please separate those out into another commit. One or two are fine, but when there's a huge bunch it makes things really hard.

Understandable; sorry about that. Give me a moment.

authors: chessai treeowl

repo: haskell-streaming/streaming


text:
[WIP] Hyper-V and change to Bento

Proposed Changes
In a Windows install, running Docker in Windows requires Hyper-V enabled. Running VirtualBox, on the other hand, requires Hyper-V to be disabled. As Vagrant supports Hyper-V as a provider, it would be nice to enable this.
I've started with the work, but it is not ready yet (thus the [WIP] tag, I hope that's correct). The main changes are:

Change of box from ubuntu/xenial64 to bento/ubuntu-16.04

ubuntu/xenial64 does not support hyper-v, so it would be necessary to change base box. bento boxes should not be that different, and are even referenced in the official documentation.
One difference is the default username, which will be changed from ubuntu to vagrant. On the other hand, this seems to be the recommended default for Vagrant.

Change of network interface name in provision.sh script

The network interfaces are no longer named enp0s8 and enp0s9. I believe the new names are eth0 and hassio, but need to test this more.
Hyper-V does not manage networks exactly the same way as other providers, so testing will be required to make sure that part works as intended.

Related Issues
[#7] Issue I created before making the pull request.

This PR is running stale, closing it.
Feel free to re-open if you are ready.

authors: fredrikbaberg frenck

repo: hassio-addons/hassio-vagrant


text:
🛑 Portfolio is down

In 7809608, Portfolio (https://portfolio.arash-hatami.ir) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Portfolio is back up in e235d3d.


text:
Master fixes

@lucasponce These fixes are already included in the IncomingDataManager PR.  But I put them here for better visibility, and so that we could merge them if the other PR gets blocked in review for some reason.

I have reviewed this one and it looks good.
Also tested the cluster environment and it works fine.
So I'm going to merge this one meanwhile we review/study the #246.

authors: jshaughn lucasponce

repo: hawkular/hawkular-alerts


text:
POC : Make Standard Triggers natively work like DataDriven Triggers

Marking as Do Not Merge and review is not yet necessary.  I just want travis to run and to keep in sync with the .next branch.  After other .next work is stable I'd like to talk about this work.  I spent a few days investigating this somewhat major change to trigger semantics.  In short it basically merges the data-driven group trigger feature into standard triggers.  Put another way, it lets a single trigger handle data/events from N sources.  The big difference is that it does it without using a backing group trigger.   It's not totally seamless, there are some behavioral differences, but I think the change is worth considering.

ok, let's open this topic once the .next is in a good shape, as this could be a long review and discussion session.

Here is a diagram of the approach:

@lucasponce This can wait until I get back, but just in case you want to look while I'm away, I added a diagram and rebased on next.

Closing this and re-opening against master (because the next branch has been migrated to master).


text:
Consolidate the 3 gulp build files into 1.

There are 3 very small gulp build files that makes sense to consolidate into a single gulp file since it is not very large (and eliminates the duplication amongst the files). This makes the build easier to grok in a single gulp file.

Merged #81

repo: hawkular/hawkular-ui-services


text:
Conflict ClientMessage.h with mysql-dev

I found a conflict thing.
static const uint8_t PROTOCOL_VERSION in hazelcast/client/protocol/ClientMessage.h:111
It conflict with defined Macro In mysql/mysql_version.h in mysql-dev (5.7.25)

Many thanks @skyend for raising this issue with your PR! 👏 :)

authors: burakcelebi skyend

repo: hazelcast/hazelcast-cpp-client


text:
Add ROS2 support

Alternative to: https://github.com/hbanzhaf/steering_functions/pull/23
I tried to keep a minimal delta approach. All verification is still ROS1.
ROS2 is capable of compiling pure cmake packages as long as there is a valid package.xml. Therefor most of the changes are there. The diff of the package.xml still looks a bit messy but the resulting file is quite readable imo.
Let me know what you think or if the version number needs to be any different.

@Rayman Does this PR also work for you?

@Rayman Does this PR also work for you?

Yes, it's almost the same PR with the only difference that I ported the tests also to ROS 2.

authors: Rayman Timple hbanzhaf


text:
Fix 99

Problem/Need:
fix #99
Checklist:

[x] ran cypress tests locally with npx cypress open
[x] ran lighthouse site quality test locally with yarn test-quality
[x] updated package.json version it'd bump up to if approved
[x] after this PR is approved/merged, don't forget to:

[x] have the semver version updated as needed

https://github.com/hchiam/slides/releases
https://github.com/hchiam/slides/releases/new

[x] have the live/prod site updated

Noticed this in prod:
Uncaught (in promise) SyntaxError: Unexpected token u in JSON at position 5807898
There are undefineds repeated after the end of the JSON string. This causes failure to read the big slides data.
Reopened #99

repo: hchiam/slides


text:
Add chips4makers to list

See https://github.com/hdl/awesome/issues/172#issuecomment-782895784
Added separate issue for now in order to remind me. Will think about how to best add it.
Main worry I have now is that I try to limit exposure to the repos for the moment as I still plan to rework big part if not all of the APIs and I don't see myself currently having enough bandwidth to support other people working on contributions to the repos.

@Fatsie, it's ok to add a note/warning in the description explaining that the content is "read-only" for now. Due to bandwidth, pending cleanups, whatever. IMHO, having an entry with the following refs would already be useful:

https://chips4makers.io/blog/
https://www.youtube.com/watch?v=4zNRTudEl_4
https://archive.fosdem.org/2018/schedule/event/cad_os_asic/
https://www.youtube.com/watch?v=xiBrZFaZ7hQ
https://twitter.com/Chips4Makers

Anyway, no rush at all.

authors: Fatsie umarcor

repo: hdl/awesome


text:
pnr: vtr: change location of capnp schema dir

Signed-off-by: Alessandro Comodi acomodi@antmicro.com
Location of the capnp schemas has changed in VTR upstream, and requires update in the capnp-schema-dir bash script generated during the conda build.

@acomodi I restarted the CI

CI is failing, possibly due to some conda-forge updates? seems that there are four consistent errors also in the nightly builds:

verilator-uhdm py37
verilator-uhdm py38
vtr-gui
odin-ii

I have quickly looked up the errors in CI and it seems they are related to some linking failures:
  /home/runner/work/conda-eda/conda-eda/workdir/conda-env/conda-bld/symbiflow-vtr-gui_1631056143670/_build_env/bin/../lib/gcc/x86_64-conda-linux-gnu/10.3.0/../../../../x86_64-conda-linux-gnu/bin/ld: /home/runner/work/conda-eda/conda-eda/workdir/conda-env/conda-bld/symbiflow-vtr-gui_1631056143670/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_/lib/libxml2.so.2: undefined reference to `__fdelt_chk@GLIBC_2.15'
  /home/runner/work/conda-eda/conda-eda/workdir/conda-env/conda-bld/symbiflow-vtr-gui_1631056143670/_build_env/bin/../lib/gcc/x86_64-conda-linux-gnu/10.3.0/../../../../x86_64-conda-linux-gnu/bin/ld: /home/runner/work/conda-eda/conda-eda/workdir/conda-env/conda-bld/symbiflow-vtr-gui_1631056143670/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_/lib/libxml2.so.2: undefined reference to `memcpy@GLIBC_2.14'

authors: PiotrZierhoffer acomodi

repo: hdl/conda-eda


text:
🛑 stagin-env is down

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

HTTP code: 0
Response time: 0 ms

Resolved: stagin-env is back up in 5e0f3fa after 35 minutes.

repo: heIsThePirate/upptime-lessonpal


text:
Cypress generator

A console command that generates a set of basic crud tests using known data-test attributes.
All will pass initially if using the default resources/js/Resources views..
But will offer assurances when custom views are added..
And offer a starting point to customize tests to the desired outcome

it('view list of $resourceName', () => {
    //
})

it('view single $resourceName', () => {
    //
})

it('create a $resourceName', () => {
    //
})

it('update a $resourceName', () => {
    //
})

it('delete a $resourceName', () => {
    //
})

it('restore a $resourceName', () => {
    //
})

repo: headlesslaravel/formations


text:
[LG 2022 Model] Unable to open the app due to below error

Failed to create session. An unknown server-side error occurred while processing the command. Original error: An unknown server-side error occurred while processing the command. Original error: unknown error: Runtime.executionContextCreated has invalid 'context': {"auxData":{"frameId":"FBC10E0C81A80ED6FAFD1503358A3256","isDefault":true,"type":"default"},"id":1,"name":"","origin":"file://com.movenetworks.app.bling-tv-bling-production-webos"} (Session info: content shell=)
[debug] [Chromedriver@8584] Matched '/session' to command name 'createSession'
[debug] [Chromedriver@8584] Proxying [POST /session] to [POST http://127.0.0.1:55748/session] with body: {"capabilities":{"alwaysMatch":{"goog:chromeOptions":{"debuggerAddress":"192.168.2.81:9998"},"goog:loggingPrefs":{"browser":"ALL"}}}}
[debug] [Chromedriver@8584] Webview version: ''
[Chromedriver@8584] Got response with status 500: {"value":{"error":"unknown error","message":"unknown error: Runtime.executionContextCreated has invalid 'context': {"auxData":{"frameId":"FBC10E0C81A80ED6FAFD1503358A3256","isDefault":true,"type":"default"},"id":1,"name":"","origin":"file://com.movenetworks.app.bling-tv-bling-production-webos"}\n  (Session info: content shell=)","stacktrace":"0   chromedriver_mac64_v107.0.5304.62   0x0000000100e732c8 chromedriver_mac64_v107.0.5304.62 + 4752072\n1   chromedriver_mac64_v107.0.5304.62   0x0000000100df3463 chromedriver_mac64_v107.0.5304.62 + 4228195\n2   chromedriver_mac64_v107.0.5304.62   0x0000000100a56b18 chromedriver_mac64_v107.0.5304.62 + 441112\n3   chromedriver_mac64_v107.0.5304.62   0x0000000100a47407 chromedriver_mac64_v107.0.5304.62 + 377863\n4   chromedriver_mac64_v107.0.5304.62   0x0000000100a41746 chromedriver_mac64_v107.0.5304.62 + 354118\n5   chromedriver_mac64_v107.0.5304.62   0x0000000100a41fa5 chromedriver_mac64_v107.0.5304.62 + 356261\n6   chromedriver_mac64_v107.0.5304...
[debug] [W3C] Matched W3C error code 'unknown error' to UnknownError
[debug] [Chromedriver@8584] UnknownError: An unknown server-side error occurred while processing the command. Original error: unknown error: Runtime.executionContextCreated has invalid 'context': {"auxData":{"frameId":"FBC10E0C81A80ED6FAFD1503358A3256","isDefault":true,"type":"default"},"id":1,"name":"","origin":"file://com.movenetworks.app.bling-tv-bling-production-webos"}
[debug] [Chromedriver@8584]   (Session info: content shell=)
[debug] [Chromedriver@8584]     at errorFromW3CJsonCode (/opt/homebrew/lib/node_modules/appium/node_modules/@appium/base-driver/lib/protocol/errors.js:923:25)
[debug] [Chromedriver@8584]     at ProxyRequestError.getActualError (/opt/homebrew/lib/node_modules/appium/node_modules/@appium/base-driver/lib/protocol/errors.js:798:14)
[debug] [Chromedriver@8584]     at JWProxy.command (/opt/homebrew/lib/node_modules/appium/node_modules/@appium/base-driver/lib/jsonwp-proxy/proxy.js:340:19)
[debug] [Chromedriver@8584]     at processTicksAndRejections (node:internal/process/task_queues:95:5)
[debug] [Chromedriver@8584]     at Chromedriver.startSession (/Users/raja.subudhi/.appium/node_modules/appium-lg-webos-driver/node_modules/appium-chromedriver/lib/chromedriver.js:597:5)
[debug] [Chromedriver@8584]     at Chromedriver.start (/Users/raja.subudhi/.appium/node_modules/appium-lg-webos-driver/node_modules/appium-chromedriver/lib/chromedriver.js:528:7)
[debug] [Chromedriver@8584]     at WebOSDriver.startChromedriver (/Users/raja.subudhi/.appium/node_modules/appium-lg-webos-driver/lib/driver.js:182:5)
[debug] [Chromedriver@8584]     at WebOSDriver.createSession (/Users/raja.subudhi/.appium/node_modules/appium-lg-webos-driver/lib/driver.js:153:5)
[debug] [Chromedriver@8584]     at AppiumDriver.createSession (/opt/homebrew/lib/node_modules/appium/lib/appium.js:336:35)
[Chromedriver@8584] Chromedriver exited unexpectedly with code null, signal SIGTERM
[debug] [Chromedriver@8584] Changed state to 'stopped'
[Chromedriver@8584] An unknown server-side error occurred while processing the command. Original error: unknown error: Runtime.executionContextCreated has invalid 'context': {"auxData":{"frameId":"FBC10E0C81A80ED6FAFD1503358A3256","isDefault":true,"type":"default"},"id":1,"name":"","origin":"file://com.movenetworks.app.bling-tv-bling-production-webos"}
[Chromedriver@8584]   (Session info: content shell=)
[debug] [AppiumDriver@09a1] Event 'newSessionStarted' logged at 1669295967998 (18:49:27 GMT+0530 (India Standard Time))
[debug] [AppiumDriver@09a1] Encountered internal error running command: Error: An unknown server-side error occurred while processing the command. Original error: unknown error: Runtime.executionContextCreated has invalid 'context': {"auxData":{"frameId":"FBC10E0C81A80ED6FAFD1503358A3256","isDefault":true,"type":"default"},"id":1,"name":"","origin":"file://com.movenetworks.app.bling-tv-bling-production-webos"}
[debug] [AppiumDriver@09a1]   (Session info: content shell=)
[debug] [AppiumDriver@09a1]     at Object.errorAndThrow (/opt/homebrew/lib/node_modules/appium/node_modules/@appium/support/lib/logging.js:115:34)
[debug] [AppiumDriver@09a1]     at Chromedriver.start (/Users/raja.subudhi/.appium/node_modules/appium-lg-webos-driver/node_modules/appium-chromedriver/lib/chromedriver.js:553:16)
[debug] [AppiumDriver@09a1]     at WebOSDriver.startChromedriver (/Users/raja.subudhi/.appium/node_modules/appium-lg-webos-driver/lib/driver.js:182:5)
[debug] [AppiumDriver@09a1]     at WebOSDriver.createSession (/Users/raja.subudhi/.appium/node_modules/appium-lg-webos-driver/lib/driver.js:153:5)
[debug] [AppiumDriver@09a1]     at AppiumDriver.createSession (/opt/homebrew/lib/node_modules/appium/lib/appium.js:336:35)
[HTTP] <-- POST /session 500 14622 ms - 1285
[HTTP]

@jlipps @boneskull @KazuCocoa Please help on these issues

Uploading lg2022.odt…

lg2022.txt

server logs attached.
lg2022.odt

@jlipps @boneskull @KazuCocoa
It is an important topic. issues are present in TV’s of LG.
Drivers are able to launch the app in TV with the Desired capabilities,But to inspect the app its not able to launch in appium inspector the 3 error mentioned above.
Let me know if full logs are needed.

The TV internal failed to start com.movenetworks.app.bling-tv-bling-production, no idea about the cause if the app was configured properly.
It would be helpful to find the cause since this driver is still under development as this readme.

@KazuCocoa Sure i will check with my peers regarding the app configuration and update.
can you please help what needs to be check when you mentioned >>"if the app was configured properly"
It will be helpful to highlight the correct data needed.

Afaik, the app under test should be signed developer app: https://webostv.developer.lge.com/develop/getting-started/developer-mode-app

@KazuCocoa This is resolved after setting the LG SDK path properly and in use of a signed build with chrome executable capability.
Kindly close as i not have permission to the repo.

repo: headspinio/appium-lg-webos-driver


text:
Making changes to sass styles in host project triggers full page refresh

When making styling changes prior to adding fountainhead, styles were updated without triggering full page refresh.
Am I missing a config option?

Off the top of my head I'd guess this is either to do with the way we have handled including fountainhead's CSS into a host app, or something to do with our code that triggers a reload whenever the docs are rebuilt. Docs shouldn't be rebuilt on SCSS changes but it's entirely possible that's what's going on. We will look into it and let you know!

This is happening and I think it's worth fixing.
It's happening because we hook into the preBuild hook for the addon to call generateDocs() whenever the consuming app changes. Unfortunately this hook is also called for css changes. On a CSS change, Fountainhead calls generateDocs, then new docs are generated into /public/docs. Because Ember watches the public dir, it sees files have changed and reloads the app.
I can't find any docs on unwatching folders, which is a bummer. If we can't find a way to to unwatch part of the public directory, I'm pretty sure we could fix this by generating docs to some folder other than /public (like /docs) and then using a broccoi Funnel in the postBuild hook to pull those generated docs into the build's public directory.
Let's look around a little more for a way to unwatch a directory. If we don't find anything I'll write a Funnel. (This actually might be a good route to go either way, it would probably also resolve the infinite reload issue the first time you build after pulling Fountainhead so we wouldn't have to manually change the .watchmanconfig file in the generator) The only downside is it's another root directory in a consuming app, which some people might not like... but they could just change the output path...

Fixed by #22
Scheduled for 3.0 release. Should be out within the week.
(If you need a short term fix you can set liveEdit: false in your fountainhead.js config file to turn off live rebuilding of data files that is causing the page reloads.
Thanks!

Awesome work :)

authors: DHedgecock evrowe mfeckie

repo: healthsparq/ember-fountainhead


text:
fix: LSDV-4711: CORS error accessing previously annotated data

Hi @bmartel!
This PR was created in response to a PRs in upstream repo:

https://github.com/heartexlabs/label-studio-frontend/pull/1299
https://github.com/heartexlabs/dm2/pull/169

To enable Auto Merge for this PR also merge those PRs:

https://github.com/heartexlabs/label-studio-frontend/pull/1299

repo: heartexlabs/label-studio


text:
Custom layout for parallax slides

Is there any way of using a custom layout with parallax, for example using multiple images?

You may want to take a look at the parallax implementation:
https://github.com/heinrichreimer/material-intro/tree/master/library/src/main/java/com/heinrichreimersoftware/materialintro/view/parallax
Main part of it is the Parallaxable class.

I managed to achieve what I was looking for by including custom Views into a ParallaxLinearLayout and using it in the slides.

authors: adrcotfas heinrichreimer

repo: heinrichreimer/material-intro


text:
HIP 55:  Validator Challenges

Author(s): @Vagabond,
@andymck, @abhay
Start Date: 2022-02-03
Category: Technical
Original HIP PR: https://github.com/helium/HIP/pull/359
Tracking Issue: https://github.com/helium/HIP/issues/362 (this)
Status: In Discussion

Summary
This HIP proposes a change to how Proof-of-Coverage (PoC) Challenges are
generated and submitted to the Helium blockchain to allow for further network
scalability and to lower the hardware complexity/cost of Hotspots. Specifically,
it moves the responsibility of PoC Challenge creation to Validators and
consequently proposes moving the economic reward for creating Challenges to this
group as well.
Rendered view
https://github.com/helium/HIP/blob/main/0055-validator-challenges.md

I am very excited to see this draft HIP. Moving challenge creation to validators is a huge step forward today light hotspots.
A couple thoughts to consider with regard to the load on the CG and incentives:

A challenge is going to trigger a lot of requests to the Challenge Validator, which in most cases will be an active CG member. This could add excessive load to the validators in CG. For example, all hotspots in a targeted hex must send a request to the challenge validator to see if it is the challengee. That is an average of 30 and max of >2000 hotspots in a hex. At the current poc interval, there are ~30,000 PoCs per epoch or ~700 challenges per validator. Add in witness counts per Poc and there could easily be tens of thousands of additional requests being made to in CG validators. At the same time, the rest of the validators (98%) remains relatively idle.
In this model, non-CG validators are being tasked with additional work but no additional rewards. There will be little incentive for validators to support light hotspots. I understand that this proposal leaves open future mechanisms like slashing. However, in the interim, I fear we will see validators opting out of providing the gateway service while not in CG if there is not a reward to do so.

Perhaps there could be a way to have the CG generate the challenges but assign other validators not in the CG to perform the work of notifying the challengee, collecting the witnesses, and submitting the blockchain_txn_poc_receipts_v2 transaction to the CG. The rewards from the 0.9% pool should then be given to those validators to provide incentive for them to do so.

My thought on this @anthonyra would be similar to what the authors are already proposing - have the CG pick the hex/hotspot to be challenged, but then also pick an active, non-CG validator to handle the rest of the process of notifying the challengee, collecting receipts and witnesses, and submitting the poc txn to the blockchain - same as described in the HIP. And, reward the non-CG validator doing that work with the challenge creation rewards.
I think the added complexity is that block metadata would have to include not only the target hex, but also the details of the non-CG validator selected to do the rest of the challenge work. Also, there would need to be a mechanism for the CG member to share secret information with the selected non-CG validator including the specific hotspot in the hex and the onion key. This could potentially be encrypted with the non-CG validators public key and included in the block metadata or sent via a p2p connection directly to the non-CG validator.
The last piece of this is knowing whether the non-CG validators are active AND providing the necessary gRPC service to perform the challenge role. I propose adding an optional parameter to the heartbeat transaction that includes the gRPC listen address of the validator. If this is populated and the heartbeat meets the definition of live (i.e. withing 150 blocks of current), then the validator would be eligible to be selected to handle challenges.
CC: @abhay @Vagabond

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.
Validators already have sufficient staking rewards.

I think it would be possible for the validators to create challenge information and submit them to the group (vs the group generating them itself), then the challenging validator would remain the sole holder of any private information until the receipt was published. That challenge information could flow through the block metadata as proposed in the HIP but, as noted, would not be tied to a consensus group member under this alternative.
Doing that is now interesting because non-elected validators become invested in providing validation services to the light hotspots so they can maximize their chances of doing challenges. Because the actual challengees are unknown until the block is published, validators would be unwise to favor any specific light gateway connections because they don't know who they may need to communicate with in the future.
Then, as proposed above, the challenging validator would be in charge of constructing and reporting the receipt transaction.

I would also like to make the association of a validator and a light hotspot using that validator a trackable signal on-chain that could be used in election selection criteria down the road. This would help reward strong, reliable validators with good reputations and help align incentives between hotspots and validators if the hotspot owners are given agency over which validators their hotspots are using.

So are we voting on the HIP as written or as @Vagabond described, or just the concept of moving challenge creation (and therefore the need to sync and all the related problems) away from hotspots? I'm definitely in favor of that last thing.

Another important caveat I was thinking about has to do with us shifting these rewards to the CG.
As of right now there's no incentive to have long epochs. Instead they want to have the shortest possible and most elections. If CG members were rewarded for challenges would they split the pot that was collected over the course of an epoch?
If so, that would be ~0.34 HNT per validator per epoch ideally. However, it then incentives the CG to have long epochs because sure they won't be getting the 2HNT ish per election but they can't control that. But what they can control is the length by purposely sabotaging the election. This could be unstuck with a rescue block sure, but I don't think we should provide even the chance to incentivize long epochs.
One option is to only allow challenge creation during the first 30 blocks of an election but then hotspots would get the short end of stick on a purposefully long one or an "issue" that resulted in a long block.

Yes, that's another good point for shifting things to the validator pool rather than the consensus group.

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.
Validators already have sufficient staking rewards.
Other than that, I think this will be a great improvement.

I would second third and fourth this sentiment. While this change will make for a more efficient network experience for consistency and the uptime of the hotspots, I absolutely do not believe that they should further allocate more share of the rewards to those who share an already disproportionately large portion of these rewards compared to the number of validators. The miners who make up the majority of this network should not have to pay the price for every change in this ecosystem. There really is no need to allocate an additional .9% to Validators in this network unless the message quite blatantly is suggesting that validators should not expect to do anything simply for the betterment of the network, while the regular miners should be expected to prop up the network of the pure goodness of our hearts and pay the price every time in terms of giving up our rewards. This was promoted as the people's network; this type of scenario feels all too similar to the world we already live in where the top 10-1% should benefit on top of their already lucrative advantages, while everyone else pays for them to be there.

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.
Validators already have sufficient staking rewards.
Other than that, I think this will be a great improvement.

This is spot on. Rewards are in the toilet and the last thing we humble hotspot owners need is even more of the pie being taken away. Improve the network yes, but put the rewards back in the daily pool.

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.
Validators already have sufficient staking rewards.
Other than that, I think this will be a great improvement.

This is spot on. Rewards are in the toilet and the last thing we humble hotspot owners need is even more of the pie being taken away. Improve the network yes, but put the rewards back in the daily pool.

Which ever entity of the blockchain is tasked with creating challenges should be rewarded. I highly doubt you're willing to work for free so why should the entity picked to do challenge creations work for free?

This is roughly a 17% raise for Validators - who dominate the vote, based on the way HNT weighting works.
While I support the technical aspects of this change, the large wallets typically held by Validators means they have the ability to vote themselves a raise, which calls into question whether they are voting for the change itself or the raise.

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.
Validators already have sufficient staking rewards.
Other than that, I think this will be a great improvement.

This is spot on. Rewards are in the toilet and the last thing we humble hotspot owners need is even more of the pie being taken away. Improve the network yes, but put the rewards back in the daily pool.

Which ever entity of the blockchain is tasked with creating challenges should be rewarded. I highly doubt you're willing to work for free so why should the entity picked to do challenge creations work for free?

This is roughly a 17% raise for Validators - who dominate the vote, based on the way HNT weighting works. While I support the technical aspects of this change, the large wallets typically held by Validators means they have the ability to vote themselves a raise, which calls into question whether they are voting for the change itself or the raise.

Hear hear! Very well said. It is extremely concerning.

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.
Validators already have sufficient staking rewards.
Other than that, I think this will be a great improvement.

This is spot on. Rewards are in the toilet and the last thing we humble hotspot owners need is even more of the pie being taken away. Improve the network yes, but put the rewards back in the daily pool.

Which ever entity of the blockchain is tasked with creating challenges should be rewarded. I highly doubt you're willing to work for free so why should the entity picked to do challenge creations work for free?

This is roughly a 17% raise for Validators - who dominate the vote, based on the way HNT weighting works. While I support the technical aspects of this change, the large wallets typically held by Validators means they have the ability to vote themselves a raise, which calls into question whether they are voting for the change itself or the raise.

Exactly this, Helium doesn't need to fall victim to same fault that US politicians do. An bird's eye rebalancing of the network's reward structure is definitely needed after so much development.

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.
Validators already have sufficient staking rewards.
Other than that, I think this will be a great improvement.

This is spot on. Rewards are in the toilet and the last thing we humble hotspot owners need is even more of the pie being taken away. Improve the network yes, but put the rewards back in the daily pool.

Which ever entity of the blockchain is tasked with creating challenges should be rewarded. I highly doubt you're willing to work for free so why should the entity picked to do challenge creations work for free?

This is roughly a 17% raise for Validators - who dominate the vote, based on the way HNT weighting works. While I support the technical aspects of this change, the large wallets typically held by Validators means they have the ability to vote themselves a raise, which calls into question whether they are voting for the change itself or the raise.

Where do you get 17%?

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.
Validators already have sufficient staking rewards.
Other than that, I think this will be a great improvement.

This is spot on. Rewards are in the toilet and the last thing we humble hotspot owners need is even more of the pie being taken away. Improve the network yes, but put the rewards back in the daily pool.

Which ever entity of the blockchain is tasked with creating challenges should be rewarded. I highly doubt you're willing to work for free so why should the entity picked to do challenge creations work for free?

This is roughly a 17% raise for Validators - who dominate the vote, based on the way HNT weighting works. While I support the technical aspects of this change, the large wallets typically held by Validators means they have the ability to vote themselves a raise, which calls into question whether they are voting for the change itself or the raise.

Where do you get 17%?

5.2% up to 6.1% - that is a 17% change.

Ahh okay, well the math does check out but I still think it's the better option. I'm a proponent for who ever is left in charge of this work should get rewarded. How that rewarding is done can be negotiated. But a simple 0.9% change makes the most sense to me.
The other option would be to split the 0.9% to all the hotspots and charge the hotspots per challenge created? It'd be better for the challenger though, because hotspots rewards would be affected by network size and halvenings. But the challengers would charge the same rate per challenge.

5.2% up to 6.1% - that is a 17% change.

This isn't right. Validators get 6% of network rewards. So 6% to 6.9% is 15%. The 5.1% is our APY (before costs).
Also, this doesn't mean an individual validator will earn 15% more. When you increase network rewards, more people are attracted to sign up. We'll end up back where we were with the APY, but there'll simply be more validators.

When you increase network rewards, more people are attracted to sign up. We'll end up back where we were with the APY, but there'll simply be more validators.

When the validator hip was introduced, the goal was to get to at least 100 validators. There are now 3,426 validators. To me, the fact that there are 34x more validators than needed shows that validators already are over-incentivized. So let's not increase the incentive further. Even if 90% of existing validators would drop because of the new work, the network would still be stable.

with regard to the load on the CG and incentives:

The Helium development team has made lots and lots of performance improvements to the validator code. Discovery mode was taken away, so we even have feature loss to lower the load on the validators.
The network didn't take away rewards from validators when the load was lowered, nor when disco mode was removed. Why should the network give validators more rewards now?

When the validator hip was introduced, the goal was to get to at least 100 validators. There are now 3,426 validators. To me, the fact that there are 34x more validators than needed shows that validators already are over-incentivized.

Where did you get 100 validators from? In any case, network security in proof of stake networks is better measured by looking at the percentage of supply staked, which is currently 35%. This is how other proof of stake networks compare (data taken from StakingRewards):

Solana: 75%
Ethereum: 8%
Cardano: 69%
Avalanche: 60%
Terra: 40%
Polkadot: 53%
BNB Chain: 84%
Cosmos Hub: 64%

Helium's current 35% is considerably lower than any other network except Ethereum, which is an outlier because the migration to proof of stake has not actually happened yet. Helium has to pay for miners too, which is means our funding for validators is comparatively low, so I want to rebut the notion that validators are "over incentivised". It just clearly is not the case.
Frankly, I do not really care that much about taking 0.9% more of network rewards. As I have already said, those rewards will buy more validators, they won't improve the bottom line of individual validators. However, the PoC rewards are not some frivolous expenditure that will simply disappear into a black hole of growing validator count, but rather a critical component of the game theoretic assurances that a public blockchains needs to function. That is because the 0.9% will incentivise new behaviour whereby we spread work across non-CG validators. That has to be payed for, otherwise there is no assurance that validators will opt to provide the service.
Any public blockchain must properly leverage economic incentives to remain viable and robust long term. You cannot expect self-interested, pseudonymous strangers on the internet to perform work outside of their self interest. It just won't work. This goes for any actor in any crypto network, including both validators and miners on Helium.
So I get it, you're trying to take care of you income, and that is what I would expect you to do in this scenario. However, I have an eye to the future, and am not looking at this in terms of my income, which won't be much affected in the near term, but I am looking at it in terms of my capital investment. I need Helium to succeed, I need it to attract new miners and to expand the network to improve availability for ends users. To do that, we must make it as robust and scalable as possible, and this HIP is a major component of that effort.

To be clear: I own 0 mining hotspots and 0 validators. So your assumption that I am protecting my income is partly false. I do prefer to protect my investment in the very first OUI though, which is only valuable if the Helium network provides coverage.
Yes, we can push for the Helium Network to be like any other crypto currency. Or we can let the Helium Network do what the network was built for: provide utility in the real world by providing coverage. To provide coverage, we need hotspots. To me, the way to make Helium succeed is to expand the coverage (both in terms of new geographical areas and in terms of new connection types like 5G, wifi, etc). We don't need the validators eating an even bigger share of the value produced by Helium.
So it seems like we both want Helium to succeed. We just have very different ideas of what it takes to succeed.

To provide coverage, we need hotspots

I completely agree, which is why I support this HIP. It makes hotspots much, MUCH more efficient and cheaper to run, meaning that the network can fund more of them with less. Giving validators PoC rewards is a necessary component of that because we have to incentivise the correct behaviour to make it all work.

To provide coverage, we need hotspots

I completely agree, which is why I support this HIP. It makes hotspots much, MUCH more efficient and cheaper to run, meaning that the network can fund more of them with less. Giving validators PoC rewards is a necessary component of that because we have to incentivise the correct behaviour to make it all work.

Why? its not like the validators are just going to pack up, cash in their helium and leave. They already have a huge slice of the pie for less work than they did a year ago. Now they have to take on a bit more they should be rewarded? Did they lose some of that slice when they stopped supporting discovery mode? Their workload was reduced but their slice wasn't.

Seamna la fel de mult cu, oameni care ajung sus și muncesc din ce an ce mai puțin pe bani multi.

5.2% up to 6.1% - that is a 17% change.

This isn't right. Validators get 6% of network rewards. So 6% to 6.9% is 15%. The 5.1% is our APY (before costs).
Also, this doesn't mean an individual validator will earn 15% more. When you increase network rewards, more people are attracted to sign up. We'll end up back where we were with the APY, but there'll simply be more validators.

Thank you for refining my numbers. But the point behind that thread is lost when you look at only the numbers. Let me make it again.
I support this HIP on its technical merits and what it means for Hotspots and the network at large. But I detest the idea of HNT weighted voting when part of the discussion involves rewards moving across the boundary between Hotspots and Validators. Validators will always win that vote due to their large wallets.
This HIP is only an improvement for Hotspots (performance), while also taking something away. Validators only stand to gain - or at least suffer no losses. Therefore, Validators should not have a voice in this vote, due to the their influence on the outcome by HNT weighting. Instead, this vote should be Hotspot count weighted. Then if it passes, you'd know that the Hotspot owners (as a group) fully understood the trade and elected to give the 0.9% to the Validators. In its current form, it feels like Validators are taking it and there's nothing we can do about it. If the vote gets too close, a single Validator or a single HNT whale can tip the scale.
It would be interesting to see a histogram of the raw votes by HNT weight. How many raw votes have 100 HNT, 1000, 10000, 100000, etc.?
It would also be interesting to see a histogram of Hotspot count. How many raw votes have 1, 10, 25, 50, 100, 200, etc.?

To provide coverage, we need hotspots

I completely agree, which is why I support this HIP. It makes hotspots much, MUCH more efficient and cheaper to run, meaning that the network can fund more of them with less. Giving validators PoC rewards is a necessary component of that because we have to incentivise the correct behaviour to make it all work.

Why? its not like the validators are just going to pack up, cash in their helium and leave. They already have a huge slice of the pie for less work than they did a year ago. Now they have to take on a bit more they should be rewarded? Did they lose some of that slice when they stopped supporting discovery mode? Their workload was reduced but their slice wasn't.

The validators won't pack up, however there's nothing stopping an operator of a validator from not providing challenges. I know for a fact, if this work isn't rewarded that's exactly what's going to happen. And if there's no challenges being created there's no PoC.
It gets even worse when validators can "pick" the hotspots they serve. So I'd expect challenges won't go away completely they'll just be only created for those the validators want. The counter to this is just to provide the blanketed 0.9% of rewards like today that way they aren't incentivized to play favorites. They'll just create what's needed per block.
Because as it stands, validators would rather hotspots not bother them since their primary job becomes significantly easier. We want to prevent this motive

What prevents validators from playing favorites if they do get the 0.9%?
This is starting to look more and more like a hostage situation.

Based on this morning's numbers (8AM CST on 2/19), 37% of wallets are against this HIP, but due to HNT weighting this is less than 7% against.
Additionally, the displayed 93% approval likely makes those that are against this HIP, unlikely to pay the poll tax to vote, further skewing the results.
If HNT weighting was removed, 37% against is enough to block this HIP.
Because of the huge gap due to HNT weighting and polar opposite outcome, this vote should be cancelled and redesigned.

It's all about numbers, they can still play favorites. But the target hex is based on the block hash. They can't pick challengees. But if the only challengees are those specifically cherry picked by validators that's bad.
If anything your comment here suggests that the 0.9% might not be enough to prevent this "favoritism".

In the light of yesterdays AMA discussion I'm a bit confused regarding validators and the terminology used in the HIP55: In the basic a non-staked validator (ie just running the validator software) is also a validator. So my question is; do the validators that light-hotspots connect to need to be staked?
My proposal would be to figure out a architecture where validators that light-hotspots connect to don't need to be staked. Light-hotspot operators should be able to select trust-worthy light-hotspot-serving-validators.
Additionally I think that there should be some thought around the direct-connection of light-hotspots to consensus-group members for delivering reports. I think this is a sub-optimal architecture and a way should be found to exchange those messages via gossip, removing a direct-connection requirement to CG members. It would be very easy to connection-starve a CG-member.

Additionally I think that there should be some thought around the direct-connection of light-hotspots to consensus-group members for delivering reports. I think this is a sub-optimal architecture and a way should be found to exchange those messages via gossip, removing a direct-connection requirement to CG members. It would be very easy to connection-starve a CG-member.

Agreed. @Vagabond, @PaulVMo and @anthonyra outlined a way to offload work to non-CG members above. Scroll up a bit.

So my question is; do the validators that light-hotspots connect to need to be staked?

Yes, they need to be staked.

Yes, they need to be staked. The language could be improved a bit to make the distinction between a validator and a chain-follower clearer.

I understand that there's some trust placed in light-hotspot-connecting validators, but wouldn't it be better to have non-staked or less-staked light-hotspot-serving-validators? This would make it easier to scale out the light-hotspot-serving stack while not risking performing bad and getting penalties while in the CG because you still have to serve those light-hotspots.

I agree that does sound like a pretty good idea. The 0.9% could be used to incentivise a new, small class of PoC challengers with a low stake, say 100 HNT.

but wouldn't it be better to have non-staked or less-staked light-hotspot-serving-validators?
Agree with the less-staked part.

We have to be careful to not let the system be easily gamed. IMO, there has to be "friction" to spinning up a bunch of these "hotspot serving nodes" so that gamer can't spin up too many and control challenge creation. Does that friction have to be 10,000 HNT? I don't think so, it's certainly easier to make the existing validators do this, but a new class of node with a small stake (or some other source of friction) seems like a good way to let more folks spin these up.

So what does this actually mean for people owning a miner? How much less will we get? Because I recently acquired a hotspot and my placing is good, still rewards are pretty disappointing. Now they are getting even lower? I'm starting to think I'm better off selling the thing for a profit now.
Also just checked the votes, 99.6% in favor of this? How?
Are the hotspot owners even voting?
BTW they charge HNT to vote? I barely have 2 HNT after a month of "mining" so yeah looking at these odds I rather keep it than vote for jack...

I continue to have a massive issue with the way these HIPs are developed amd then voted upon. Apart from yelling your thoughts into the forest on Github or Discord, not knowing if your ideas are even heard, the normal hotspot owner has no way of really influencing these HIPs. Then they suddenly go to take-it-or-leave-it votes with a few large wallets determining the outcome, despite many detail questions still being unanswered. This is a pseudo-democracy and a PERFECT setup for wallet-biased network development into the future.
On that note, why not allow hotspots to vote themselves into our out of the challenge creation process? Why render 500'000 mini-computers useless (plus the hundreds of thousands currently on order), especially with the current chip shortage? That's a massive waste.
If I have well-performing "heavy" hotspot with good backhaul bandwidth, I may not mind the workload and may want to share in the 0.9% HNT allocation. If I prefer to buy a cheaper hotspot or have issues with my cell backhaul data usage, I may forego that income and opt out.
Heavy hotspots that opt in should be equal to validators when it comes to challenge creation.
This gives hotspot owners a choice and helps to counteract all the centralization trends we've been seeing in the Helium network.

I continue to have a massive issue with the way these HIPs are developed amd then voted upon. Apart from yelling your thoughts into the forest on Github or Discord, not knowing if your ideas are even heard, the normal hotspot owner has no way of really influencing these HIPs. Then they suddenly go to take-it-or-leave-it votes with a few large wallets determining the outcome, despite many detail questions still being unanswered. This is a pseudo-democracy and a PERFECT setup for wallet-biased network development into the future.
On that note, why not allow hotspots to vote themselves into our out of the challenge creation process? Why render 500'000 mini-computers useless (plus the hundreds of thousands currently on order), especially with the current chip shortage? That's a massive waste.
If I have well-performing "heavy" hotspot with good backhaul bandwidth, I may not mind the workload and may want to share in the 0.9% HNT allocation. If I prefer to buy a cheaper hotspot or have issues with my cell backhaul data usage, I may forego that income and opt out.
Heavy hotspots that opt in should be equal to validators when it comes to challenge creation.
This gives hotspot owners a choice and helps to counteract all the centralization trends we've been seeing in the Helium network.

Quite a clever and fair suggestion to resolve/solve this whole .9% allocation dilemma. I can only hope that the ones responsible for this project are as reasonable when it comes re-envisioning the way we vote in this ecosystem, as well as exploring a new weighted system voting perhaps.
This idea certainly has true decentralized fairness in mind.

The HIP has been approved via heliumvote, with 96.3% voting For HIP 55.
On behalf of the DeWi, the HIP Editors, and the wider Helium community, I am marking this proposal as approved and recommending that the coredev team implement the necessary changes as soon as reasonably possible.

When will the HIP 54 and HIP 55 come in action and the hotspots will no longer be relayed @edakturk14 @hiptron

Hardware is currently active on Testnet.
For most up-to-date timelines on light hotspot rollout, please refer to https://docs.helium.com/mine-hnt/light-hotspots/#development-timelines

authors: ColonelKlinck1972 Crisatian FreekHub HackGod2000 OrmEmbaar PaulVMo Raecaug TXR72 Vagabond anthonyra bkhall cr9cristiano edakturk14 hiptron jthiller kellybyrd mfalkvidd timcooijmans

repo: helium/HIP


text:
[Bug]: 404 error at URL: https://explorer.helium.com/txns/Q9KQd_YgokXYNFK87DbAqL86BCa9wEw1dV8vjmq1BQQ

What happened?
A bug happened!
URL
https://explorer.helium.com/txns/Q9KQd_YgokXYNFK87DbAqL86BCa9wEw1dV8vjmq1BQQ
What browsers are you seeing the problem on?
Chrome
Do you see the issue on Mobile or Desktop?
Mobile
Relevant log output
No response

looks fixed now. closing.

repo: helium/explorer


text:
1.0.0-alpha.22 info error

when this command is issued:  helium_gateway info
this is returned:
Error: Service(Service(tonic::transport::Error(Transport, hyper::Error(Connect, ConnectError("tcp connect error", Os { code: 146, kind: ConnectionRefused, message: "Connection refused" })))))
does anyone know how to fix this from the ssh command line?
i found some commands in the code - "start_service", "enable", "disable","reload" but those don't appear to be useful when used after "helium_gateway".

You need to run helium_gateway start_service so that the service begins. When the service is running,
you can run helium_gateway info.

@lthiery thank you.  i really wish that would have worked, but it didn't.
instead of starting the service, this is returned:
error: Found argument 'start_service' which wasn't expected, or isn't valid in this context
some background - i am using the dragino lps8 and recently upgraded to firmware version lgw-5.4.1644990565.  i believe that during that upgrade the helium_gateway version updated from alpha.21 (which worked) to alpha.22 (not currently working).  my suspicion is that something is wrong with the dragino file(s) and / or the dragino GUI.
please note that i am not looking for dragino help - i am just looking for gateway-rs help.
that is why i am trying to bypass the dragino GUI and control the unit from putty / ssh.
i tried to downgrade the helium_gateway version from alpha.22 to alpha.21 but it wouldn't let me.
i also tried to re-install alpha.22 with this command:
opkg install /tmp/helium-gateway-v1.0.0-alpha.22-dragino.ipk
which returned:
Package helium_gateway (1.0.0-alpha.22) installed in root is up to date.
nothing noticeably changed.
thanks for your time.

same with lig16 since few hours....

I was wrong about "start_service". It's just helium_gateway server. Also, you can access the help menu by using --help to see valid commands and explanations of how specific commands work.
eg:
helium_gateway --help
helium_gateway server --help

You can ignore those JSON parsing errors but I'll reach out to Dragino about that anyway.
INFO new packet forwarder client: A8:40:41:21:D7:BC:41:50, 127.0.0.1:45093, module: gateway is not out of place. A GWMP client is only considered "connected" once it sends a PULL_DATA and it's received by the Host. What you see above that frame is PUSH_DATA status frame which was sent before the PULL_DATA frame which creations the "connection". The PULL_DATA frames are usually sent every N seconds, so it's entirely possible and not really worrisome.
This basically looks good to me. If you open another terminal window, you can interact with the server instance.

I notice those JSON parsing errors, which seem the sensor node uplink format error instead of the gateway parsing issue.  could let me know what your sensor node is?

The info you sent is log from gateway-rs. Can you also show the log for LPS8 packet_forwarder, the most properly reason is the gateway-rs parse the info from packet_frowarder wrongly. Below is what we can see from packet_forwarder of LPS8:
Looks ok.
PKTUP~ [server] JSON: {"stat":{"time":"2022-03-02 08:41:28 UTC","rxnb":5,"rxok":2,"rxfw":2,"ackr":0.0,"dwnb":0,"txnb":0,"pfrm":"SX1308","mail":"dragino-1e9674@dragino.com","desc":"Dragino LoRaWAN Gateway"}}
Wed Mar  2 08:41:28 2022 daemon.info fwd[14617]: PKTUP~ [server2] JSON: {"stat":{"time":"2022-03-02 08:41:28 UTC","rxnb":5,"rxok":2,"rxfw":2,"ackr":0.0,"dwnb":0,"txnb":0,"pfrm":"SX1308","mail":"dragino-1e9674@dragino.com","desc":"Dragino LoRaWAN Gateway"}}

@dragino This is not what is received over UDP.
The error message from dvdadie presents the entire datagram:
[
        2, 181, 81, 0, 168, 64, 65, 33, 215, 188, 65, 80, 123, 34, 115, 116, 97, 116, 34, 58, 123,
        34, 116, 105, 109, 101, 34, 58, 34, 50, 48, 50, 50, 45, 48, 50, 45, 50, 56, 32, 49, 57, 58,
        51, 56, 58, 52, 54, 32, 85, 84, 67, 34, 44, 34, 108, 97, 116, 105, 34, 58, 52, 56, 46, 56,
        53, 57, 57, 55, 44, 34, 108, 111, 110, 103, 34, 58, 45, 49, 50, 50, 46, 54, 50, 55, 56, 51,
        44, 34, 97, 108, 116, 105, 34, 58, 51, 48, 48, 44, 34, 114, 120, 110, 98, 34, 58, 48, 44,
        34, 114, 120, 111, 107, 34, 58, 48, 44, 34, 114, 120, 102, 119, 34, 58, 48, 44, 34, 97, 99,
        107, 114, 34, 58, 48, 46, 48, 44, 34, 100, 119, 110, 98, 34, 58, 48, 44, 34, 116, 120, 110,
        98, 34, 58, 48, 44, 34, 112, 102, 114, 109, 34, 58, 34, 83, 88, 49, 51, 48, 56, 34, 44, 34,
        109, 97, 105, 108, 34, 58, 34, 100, 114, 97, 103, 105, 110, 111, 45, 50, 49, 100, 55, 98,
        99, 64, 100, 114, 97, 103, 105, 110, 111, 46, 99, 111, 109, 34, 44, 34, 100, 101, 115, 99,
        125,
    ]
    ```

We can parse this by hand using [the spec](https://github.com/Lora-net/packet_forwarder/blob/master/PROTOCOL.TXT):
2 is the GWMP protocol identifier
181, 81 is the random token
0 is the PUSH_DATA identifier
168, 64, 65, 33, 215, 188, 65, 80 is the MAC

and 123 starts the JSON string:

    123, 34, 115, 116, 97, 116, 34, 58, 123,
    34, 116, 105, 109, 101, 34, 58, 34, 50, 48, 50, 50, 45, 48, 50, 45, 50, 56, 32, 49, 57, 58,
    51, 56, 58, 52, 54, 32, 85, 84, 67, 34, 44, 34, 108, 97, 116, 105, 34, 58, 52, 56, 46, 56,
    53, 57, 57, 55, 44, 34, 108, 111, 110, 103, 34, 58, 45, 49, 50, 50, 46, 54, 50, 55, 56, 51,
    44, 34, 97, 108, 116, 105, 34, 58, 51, 48, 48, 44, 34, 114, 120, 110, 98, 34, 58, 48, 44,
    34, 114, 120, 111, 107, 34, 58, 48, 44, 34, 114, 120, 102, 119, 34, 58, 48, 44, 34, 97, 99,
    107, 114, 34, 58, 48, 46, 48, 44, 34, 100, 119, 110, 98, 34, 58, 48, 44, 34, 116, 120, 110,
    98, 34, 58, 48, 44, 34, 112, 102, 114, 109, 34, 58, 34, 83, 88, 49, 51, 48, 56, 34, 44, 34,
    109, 97, 105, 108, 34, 58, 34, 100, 114, 97, 103, 105, 110, 111, 45, 50, 49, 100, 55, 98,
    99, 64, 100, 114, 97, 103, 105, 110, 111, 46, 99, 111, 109, 34, 44, 34, 100, 101, 115, 99,
    125

In Python, you can convert this to a string:

```python
>>> a = [        123, 34, 115, 116, 97, 116, 34, 58, 123,
...         34, 116, 105, 109, 101, 34, 58, 34, 50, 48, 50, 50, 45, 48, 50, 45, 50, 56, 32, 49, 57, 58,
...         51, 56, 58, 52, 54, 32, 85, 84, 67, 34, 44, 34, 108, 97, 116, 105, 34, 58, 52, 56, 46, 56,
...         53, 57, 57, 55, 44, 34, 108, 111, 110, 103, 34, 58, 45, 49, 50, 50, 46, 54, 50, 55, 56, 51,
...         44, 34, 97, 108, 116, 105, 34, 58, 51, 48, 48, 44, 34, 114, 120, 110, 98, 34, 58, 48, 44,
...         34, 114, 120, 111, 107, 34, 58, 48, 44, 34, 114, 120, 102, 119, 34, 58, 48, 44, 34, 97, 99,
...         107, 114, 34, 58, 48, 46, 48, 44, 34, 100, 119, 110, 98, 34, 58, 48, 44, 34, 116, 120, 110,
...         98, 34, 58, 48, 44, 34, 112, 102, 114, 109, 34, 58, 34, 83, 88, 49, 51, 48, 56, 34, 44, 34,
...         109, 97, 105, 108, 34, 58, 34, 100, 114, 97, 103, 105, 110, 111, 45, 50, 49, 100, 55, 98,
...         99, 64, 100, 114, 97, 103, 105, 110, 111, 46, 99, 111, 109, 34, 44, 34, 100, 101, 115, 99,
...         125]
>>> string = ""
>>> for i in a:
...     string+=chr(i)
...
>>> string
'{"stat":{"time":"2022-02-28 19:38:46 UTC","lati":48.85997,"long":-122.62783,"alti":300,"rxnb":0,"rxok":0,"rxfw":0,"ackr":0.0,"dwnb":0,"txnb":0,"pfrm":"SX1308","mail":"dragino-21d7bc@dragino.com","desc}'

You can see, why actually see the } which closes the Python object. Is your serializer behaving properly?

Note that this release https://github.com/helium/gateway-rs/releases/tag/v1.0.0-alpha.23 should fix the issue

thanks. It's working now. Only to press download and install and that's it.
Marc Berthelot
Le jeu. 3 mars 2022 à 08:26, Marc Nijdam @.***> a
écrit :

Note that this release
https://github.com/helium/gateway-rs/releases/tag/v1.0.0-alpha.23 should
fix the issue
—
Reply to this email directly, view it on GitHub
https://github.com/helium/gateway-rs/issues/202#issuecomment-1058154923,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARJXVEL3GRFRVAJIO7HAQB3U6DK2HANCNFSM5PPVZX2Q
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID:
@.***>

authors: dragino drberthol dvdadie2 lthiery madninja xiaoye-x

repo: helium/gateway-rs


text:
Add to bookmarks black screen

Describe the bug
I was in a folder and I clicked "Bookmarks > Add to bookmarks". Filer crashed and it took the desktop with it. The rest of the system was still operational. I clicked on the Filer again and it was restored. I tried clicking "Add to bookmarks" again in the same folder and it worked as intended the second time.
To Reproduce

Open Filer
Go to a folder not found in bookmarks
Click Bookmarks > Add to bookmarks

Expected behavior
The folder gets added to the bookmarks the first time without the filer and desktop crash.
Screenshots

This is a screenshot of what my desktop looked like immediately after the issue happened.
Version (please complete the following information):

Live ISO or installed system to disk: Installed system
FreeBSD version (System --> About this Computer): 13.0-RELEASE
helloSystem build (cat /.url): https://github.com/helloSystem/ISO/commit/cd9418e
Running in a virtual machine: no
Device: Hewlett-Packard HP EliteDesk 800 G1 DM

Thanks for reporting this.

authors: daniel-lemke probonopd

repo: helloSystem/ISO


text:
installation errors

Last Friday, I updated my Visual Studio Code along with the EDI Support plugin, and everything was working perfectly.
On Monday, while working remotely, everything was still functioning properly.
However, on Tuesday, when I turned on my PC, a message appeared indicating that Visual Studio Code had updated and the plugin no longer worked. A colleague tried to resolve the issue by downloading the VSIX installation file, but without success. I tried several older versions of the plugin as well as running with administrative rights, but the same message persists.

Hi gabrielCharibPolls, please update your VSCode to the latest and try again.
The minimum VSCode version that EDI Support plugin supports is 1.78.0. While your VSCode version is 1.47.3 which is out of date, the latest VSCode version now is 1.89.1.

authors: gabrielCharibPolls hellooops

repo: hellooops/vscode-edi-support


text:
srcElement is undefined

It seems that srcElement is not supported by older firefox versions which is causing the script to crash

Update: this prevent the user from exiting the modal by clicking the upper right close button which is throwing a TypeError: e.srcElement is undefined when clicked

Thanks for the flag, we'll take a look. Sorry for the late reply, I'm the primary maintainer on the project and I've been out on vacation for the last week or so :)

No worries, I can submit a pull request fixing this issue if you want, I'll be happy to contribute!

That would be great, thanks @vanwalj! Be sure to take a look at the Contributing Guidelines :)

Hello, has this issue been fixed somehow ?
This error happened twice recently on the following settings :

User 1: Windows 7 + firefox v.57
User 2: Windows XP + firefox v.52

Maybe this setup is so old you don't want to handle it. If so, please let me know :)
Thanks for the help !

Sorry for the delay! This got lost on my end. This should now be fixed in hellosign-embedded@v2.7.2. Thanks for your patience!

Honestly, I don't know why I was using evt.srcElement here. I might have been looking something up and copied it over without thinking. Swapped it out with evt.target, should work now :)

No problem, thanks for the followup ! :)

authors: nathanbuchar scottpicquerey vanwalj

repo: hellosign/hellosign-embedded


text:
[stable/redis] redis exporter not working

Describe the bug
Redis exporter crashes for unknown reason
Version of Helm and Kubernetes:
~> helm version
Client: &version.Version{SemVer:"v2.10.0", GitCommit:"9ad53aac42165a5fadc6c87be0dea6b115f93090", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.10.0", GitCommit:"9ad53aac42165a5fadc6c87be0dea6b115f93090", GitTreeState:"clean"}

~> kubectl version
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.3", GitCommit:"721bfa751924da8d1680787490c54b9179b1fed0", GitTreeState:"clean", BuildDate:"2019-02-01T20:08:12Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.5", GitCommit:"f01a2bf98249a4db383560443a59bed0c13575df", GitTreeState:"clean", BuildDate:"2018-03-19T15:50:45Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

Which chart:
redis-ha
What happened:
When deploying redis-ha with the exporter set to enabled the export will die unexpectedly
What you expected to happen:
The redis exporter will not die
How to reproduce it (as minimally and precisely as possible):
in values.yaml set exporter.enabled: true
Anything else we need to know:

Hi @ray-haggerty
This PR affects the redis-ha chart, doesn't it?
If so, please update the title to reflect the right chart [stable/redis-ha]. It's very important so the maintainers of the corresponding chart can easily identify what issues to respond.

@juan131 You are right my mistake,  title has been updated!

I'm also seeing this issue in our cluster. I've not had much chance to dig into it, but i suppect it's the redis host the export uses.
https://github.com/helm/charts/blob/839b667a710ac27c262bf35574fdd1d366796e2a/stable/redis-ha/templates/redis-ha-statefulset.yaml#L205
This should be using the address of a redis instance?

repo: helm/charts


text:
How to enable wal-e for backup and restore in Stolon helm chart?

Is this a request for help?:
Yes
If this is a FEATURE REQUEST, please:

Describe in detail the feature/behavior/change you'd like to see.

Enable backup and restore of DB using wal-e
Storage like S3 or Rook + Ceph

Version of Helm and Kubernetes:
Helm
Client: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

Kubectl
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.2", GitCommit:"5fa2db2bd46ac79e5e00a4e6ed24191080aa463b", GitTreeState:"clean", BuildDate:"2018-01-18T10:09:24Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.2", GitCommit:"5fa2db2bd46ac79e5e00a4e6ed24191080aa463b", GitTreeState:"clean", BuildDate:"2018-01-18T09:42:01Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}

Which chart:
Stolon
What happened:
Would like to setup Wal-E with Stolon. Please help.

Hi stale bot, reopen please! This is important for production use.

Yes. Please reopen. Also, if there is a doc available to do this backup and restore - please send the link here.
Thanks!

authors: candysmurf ken0x0a shishirkh


text:
[stable/odoo] Revert pull request #15437

This reverts commit 9baed0405ed320a486b44872dbf7978bfef4e9e0.
Changes in the previous commit are breaking changes when used in some configurations, for example helm upgrade doesn't work using a static IP in the loadBalancer.
According to semver:

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backward-compatible manner, and
PATCH version when you make backward-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Those changes are not backward-compatible, so we should have increased the MAJOR version instead of the PATCH one. In this PR, we are reverting the breaking changes so the current MAJOR version will continue working without issues.
In the same way, we will create a new PR adding again those changes but bumping the chart version in a MAJOR
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 javsalgar


text:
[stable/traefik]: fix service monitor scrape port

What this PR does / why we need it:
Fix the traefik ServiceMonitor scrape port
Which issue this PR fixes
Special notes for your reviewer:
As by the doc, the correct is to use the port instead of the targetPort, because the port refers to the service name created.

port | Name of the service port this endpoint refers to. Mutually exclusive with targetPort.
https://coreos.com/operators/prometheus/docs/latest/api.html#endpoint

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

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

/assign @errm

/ok-to-test

/lgtm

authors: mmatur valtlfelipe


text:
[stable/unifi] bumping docker image to 5.11.47

What this PR does / why we need it:

Bumps the unifi docker image to version 5.11.47

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])

/assign @mcronce

@mcronce can you take a look?

Well, pending merge conflicts, anyway

Looks like the image version was already bumped as part of #18052 so this is no longer necessary.

authors: billimek mcronce


text:
Adjust servicemonitor labels

Is this a new chart
No
What this PR does / why we need it:
Actual label selecting of servicemonitor is not usable. Namespace selector was missing too.

Adjusted labels and selectors to match by default.
Added possibility to add extra labels for customized prometheus setups.

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/mychartname])

/assign

/assign @davidkarlsen

/lgtm

authors: cstaud davidkarlsen


text:
[stable/graylog] extra init containers/volumes support

What this PR does / why we need it:
Adds support for extra init containers, volumes and their mounts. This is good to have for a variety of reasons, for example adding an init container that installs the GeoIP database for the server to use. It also aligns the chart with best practices having these options.
cc/ @KongZ
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/mychartname])

/assign @kongz


text:
[stable/mongodb-replicaset] Fix test race condition

Signed-off-by: Tuan Anh Nguyen tuananh.nguyen-ext@commercetools.de
Is this a new chart
No
What this PR does / why we need it:
The current test of mongodb-replicaset has an error in the logic since the ready flag doesn't reset after each loop. When helm test is run immediately after helm upgrade and the replicaset is being upgraded (for example, having response = 1 for 2 out of 3 replicas for a while), this can cause the flag value to jump over the number of replicas, making the loop to run indefinitely.
Which issue this PR fixes

fixes #20553

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] Title of the PR starts with chart name (e.g. [stable/mychartname])

/ok-to-test

/test pull-charts-e2e

authors: tuananhnguyen-ct zanhsieh