text:
Cryptic error printout from Micrometer

Environment Details

Helidon Version: 4.0.5
Helidon SE
JDK version: OpenJDK 21.0.1+12-29
OS: Ubuntu 23.10 6.5.0-17-generic

Problem Description
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running me.test.MainTest
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.48 s - in me.test.MainTest
[INFO] Running me.daniel.se.quickstart.DummyTest
2024.02.17 13:50:41.254 Unexpected discovery of unknown previously-created meter; creating wrapper for io.micrometer.core.instrument.composite.CompositeGauge@8c71f846
2024.02.17 13:50:41.262 Unexpected discovery of unknown previously-created meter; creating wrapper for io.micrometer.core.instrument.composite.CompositeGauge@763f8121
2024.02.17 13:50:41.262 Unexpected discovery of unknown previously-created meter; creating wrapper for io.micrometer.core.instrument.composite.CompositeGauge@8cb1f1f9
2024.02.17 13:50:41.262 Unexpected discovery of unknown previously-created meter; creating wrapper for io.micrometer.core.instrument.composite.CompositeGauge@c923efe7
2024.02.17 13:50:41.263 Unexpected discovery of unknown previously-created meter; creating wrapper for io.micrometer.core.instrument.composite.CompositeGauge@9ef2fc51
2024.02.17 13:50:41.263 Unexpected discovery of unknown previously-created meter; creating wrapper for io.micrometer.core.instrument.composite.CompositeGauge@c47c45b3
2024.02.17 13:50:41.263 Unexpected discovery of unknown previously-created meter; creating wrapper for io.micrometer.core.instrument.composite.CompositeGauge@5007121b
2024.02.17 13:50:41.264 Unexpected discovery of unknown previously-created meter; creating wrapper for io.micrometer.core.instrument.composite.CompositeGauge@d3477c9d
2024.02.17 13:50:41.264 Unexpected discovery of unknown previously-created meter; creating wrapper for io.micrometer.core.instrument.composite.CompositeFunctionCounter@f0493908
2024.02.17 13:50:41.264 Unexpected discovery of unknown previously-created meter; creating wrapper for io.micrometer.core.instrument.composite.CompositeFunctionCounter@6b6e6c61
2024.02.17 13:50:41.264 Unexpected discovery of unknown previously-created meter; creating wrapper for io.micrometer.core.instrument.composite.CompositeGauge@59417b18
2024.02.17 13:50:41.265 Unexpected discovery of unknown previously-created meter; creating wrapper for io.micrometer.core.instrument.composite.CompositeGauge@fe8717a
2024.02.17 13:50:41.265 Unexpected discovery of unknown previously-created meter; creating wrapper for io.micrometer.core.instrument.composite.CompositeFunctionCounter@57613ee1
2024.02.17 13:50:41.265 Unexpected discovery of unknown previously-created meter; creating wrapper for io.micrometer.core.instrument.composite.CompositeFunctionCounter@cbd5f394
2024.02.17 13:50:41.265 Unexpected discovery of unknown previously-created meter; creating wrapper for io.micrometer.core.instrument.composite.CompositeFunctionCounter@6df5c008
2024.02.17 13:50:41.266 Unexpected discovery of unknown previously-created meter; creating wrapper for io.micrometer.core.instrument.composite.CompositeFunctionCounter@e26a74bb
2024.02.17 13:50:41.266 Unexpected discovery of unknown previously-created meter; creating wrapper for io.micrometer.core.instrument.composite.CompositeFunctionCounter@91b6f2f0
2024.02.17 13:50:41.266 Unexpected discovery of unknown previously-created meter; creating wrapper for io.micrometer.core.instrument.composite.CompositeFunctionCounter@62ba7a3

Steps to reproduce
helidon init --batch --version 4.0.5 -Dpackage=me.test  -Dflavor=se -Dapp-type=quickstart && \
cd ./quickstart-se && \
cat <<EOT >> ./src/test/java/me/test/DummyTest.java
package me.daniel.se.quickstart;
import io.helidon.webserver.testing.junit5.RoutingTest;
import org.junit.jupiter.api.Test;
@RoutingTest class DummyTest { @Test void test() {}}
EOT

And then:
mvn test

Looks like a duplicate of #8382 which, at this writing, has a PR awaiting review.

I was able to reproduce this and then, with the newly-merged PR for #8382 in place, I do not see the warnings.
Closing as duplicate.

authors: danielkec tjquinno

repo: helidon-io/helidon


text:
[Removal]:

Hotspot Name
Fancy Indigo Jaguar
Hotspot b58 Address
114uHYZrP6MSNBaBLS28LQVzj7i4tGf3nEwLkcPwqGHnaBnEu98
Discord Handle
No response
Hotspot Manufacturer
Syncrobit
Removal Reason
I have bought my hotspot from my friend abroad. Did not transferred on the exact date. When I did fast sinc, because was 8000 blocks behind not able to transfer, then my new hotspot went to Denylist straightaway.
Modifications
No
Extra forwarders
No
Extra antennas
No
Additional Information
I have bought my hotspot from my friend abroad. Did not transferred on the exact date. When I did fast sinc, because was 8000 blocks behind (not able to transfer), then my new hotspot went to Denylist straightaway.

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

source: gharchive/issue

repo: helium/denylist

license_type: permissive

license_source: github-api


text:
[Addition]:

Hotspot b58 Addresses
11WsvGoP2XvLsp1oGmULTTBRYVi27nfmV72bwfojAQeaZDuGA5N
116S5CZzNa98wK5YmneGwqUiDxnJ5fKgnqd7NYdy5NHkTaKSWrm
1122X1s5fLyDDSDTUAsjFEuaz3P8n3tc3gzkv97ZVHvtnFc1ij39
1122XdeKdkjJNSqHP4m7y81R2cHoGXi3u4SZxq1ZCGh3FqD6eCfc
11hinBW2K3jAEvYTAJrvX3R5pKkyMfA7vjZWBSFg6UmgDQK4enU
1126YqnhcFBmzh8SVb2n8pe1K9ef7Di7f2fRKFnay5zRFDTZeo4B
112sksTPdEqc6YKF86m6fCxqbRVayfVhAB8kXjA71t2Zz6krRPhM
112mqLSqSvXYbJfJZGuREoe7oFPLx1coonxZWp5nEzEA3JjcvGAH
112m3i6yQEPWLmyTxUNVJQ7Csb9MpZ9A1E3QBvSazDhDd4hUcWJ3
112jHb2oqNYFvFPyhqoLGspGkcTcKJHkk64mCA1Pn3EtY4pdYpyh
112MpGqNCeHJw3xQ3ZE1o5YFqapPM3XKMj9fDr9ZzZXQHhM9K4P6
1126ujEdnNMrzVcQWvirGfXc7D7qnmu4ceKQGBVfEvmVHwYkKy68
112fkmp5MsGcVjq9jGnyMq4kGnjiBxEnpzGnzEcVd5cEhhKuNTZY
1124NvzJ1P5mnxadDgXTqfWyHaxxHzbBfz86DK4Xwrns5AL9dTBW
11s15UnSHptbpf4FCTZAoHxPMVga6PFkofdv5ZLWUQcT2mgUrdV
112gGcvhhR1tCfYKz3SukgqgkFttTZ9v6PzpKmyQkoejNVnB9idv
112FL8q8hkivvJEQ7VjUfk36nPAiyG4tuKrx6civ3aQkxvHwp33G
1121xfYo1DJEui6up55StirmxRFZfwZZxAoazRn6P2KCLMBULF4W
112CRd8bfiwLVmLy3KArs2tbohS5gtuGWPUubpbp2Zs8ty1eeGEd
112FxFstSYy5UNCSemJ991WB5pqzQ8ggCyLk946PLjvMzWgiAYgc
11C3dFZtsJVbbMtxFggddgmzfT49SJE9QF6yPZP8kToDj7sK5D4
11oCZfxhXDLGDtzNZTE9sz5gtJPsJQKKynZJxp49LetvUBhyVvk
112Bk6CJdKtmHTVRVWCESCkbyEJRntJio7oNTeJshCwYjgGDdJam
112ienranDJoRWnWyrjgHSZzcyUPZbCwM9sxqRh6wYPGR7YkYc5V
11puGQj17u1UNGFsRpAuAdxdyP5ciKppGVJ87LKgNaS6imzWUw9
1126F1JeRz91Fxw2wxXNF8rWroRfQQuyscwxLkPVM4VZuvXZb8SZ
11LixftmUtjzATtZXPWbvcCpUFAGad53SbiUbFvTRybsuC4RDGA
11qBUrpMrPR8WQQ5pr9SjuGoQ1BU4KZp6LVYNczzamTsXiCvxD7
11URq7ABPNTSAqP9ZrHmpqimt3Ad1jsEfDCf2Fm4BFuigsoJzao
11ZfVchSQWx3t3qWpUpJPrWLdTb4ZcM3ckevrWKbh5uwZrDH9G9
11YiS69AdJj8RBTDvBgAj2AUTe6SzUNCmxJTwhJmeeR6or3SKd1
1129Spbr534ZaUQJHtwHrMS8kTxx5AkqnXiavudVt3EwiPWrVuF4
11bEyuGVuLTT9xjcvcHsDR4QW1C1TEDNTZpBj1t9DVYU2RBjci8
112RcHgahn1c4VM1U7GzNa2qxmzjuwZumyXS8NL3uDKV6xKrNuDm
11EZtLqd2u25iScp7nBPotdYNnrhAD7rEwz8mtRSKxAHinktdqL
11YbKqJKw6aDrrVkJCRPjqW2CS9NyFyA4ZBykJrpezUGFgkDUyn
11U7nVAUNgxKy6pkzi6oXtY7CD6vkxsosbDkj2t6qhK1aWJoWFf
112kV2hktwjDAqjTZK6a9ez9tS9rJvBPr1wsumZMEaoce7QUt8H9
112mVzromJP8oUL5gm1ruAo3mPQXQzywHTXaMBxtkvMWGBKJzA1N
112VbSrDeJY4sRj748gLwh8zK6z8BG4oFviUr21XXL3cTmruuhin
11Ur9RwS9mHc9BN8ThqGVWRPjHQ8xhfNn4xBvrMmRux6GWsPwNv
112MdC99mBmKZ5GhBdfX6FCoCFafS5m2MY2AZ2g16zS1B6gfkup8
11hw28eiNnwY52rmMDxBiktoGJ6k5S4KwMdXCVUJdbm2HSsjfSt
11ddcuguV6HeziTkJBmDVVmKomyHBNmwZSvERm9Z59cP8VBwYHR
11M2sEfnjMpXBVRNCGcde6ZDkn2xTVD3aZwqEHyJdXbSk3sZBPe
112RB6kYFyp1Y5PzWZQ2aPJquCU7gKSzWwdXY8J2vSeDt94hc1ck
Discord Handle
malder
Reason(s)
This group of hotspots only witness each other, despite there being 64 other online hotspots within 25 KM
These are all PantherX hotspots and they fail to interact with non-PantherX hotspots in their immediate area.

90% China miner are cheater! yah, we should ban them permanently


text:
Use parameter without tag

Hi!
First I‘d like to thank you for your work - coming from Python this helps quite a lot.
There is one case I don‘t seem to be able to solve - is something like
program -v -d  input.txt
feasible, where -v and -d are only flags and input.txt is a parameter that is used as input for program?
Kind regards
Stephan

Just perfect - looks easy... once you know how to do it.
Thanks a lot.

thanks for using this repo :)

repo: hellflame/argparse

license: MIT


text:
feat: Implement events/triggers

User description

Add onExpire trigger.
Add onRefetch trigger.

PR Type
enhancement, tests

Description

Implemented onExpire and onRefetch event triggers in the RunCache class.
Added error handling for negative TTL values in cache settings.
Updated the has method to be asynchronous to support event triggers.
Enhanced test coverage to include scenarios for new event triggers and negative TTL.

Changes walkthrough 📝
Relevant filesTests

run-cache.test.tsAdd tests for new event triggers and negative TTL

src/run-cache.test.ts
Added tests for negative TTL handling.  Added tests for onExpire and onRefetch triggers.  Updated existing tests to use async/await syntax.

+66/-18

Enhancement

run-cache.tsImplement event triggers and enhance TTL handling

src/run-cache.ts
Introduced onExpire and onRefetch event triggers.  Added error handling for negative TTL values.  Updated has method to be asynchronous.

+78/-16

💡 PR-Agent usage:
Comment /help on the PR to get a list of all available PR-Agent tools and their descriptions

/review
--pr_reviewer.extra_instructions="
In the possible issues section, emphasize the following:

Is the code logic efficient?
Give me points to improve if there's any.

/review
--pr_reviewer.extra_instructions="
In the possible issues section, emphasize the following:

Is the code logic efficient?

"
--pr_reviewer.inline_code_comments=true

/review
auto_approve
--pr_reviewer.extra_instructions="
In the possible issues section, emphasize the following:

Is the code logic efficient?

"
--pr_reviewer.inline_code_comments=true
--pr_reviewer.require_score_review=true

source: gharchive/pull-request

repo: helloscoopa/run-cache


text:
[stable/cockroachdb] for single node cockroachdb, deleting the pod doesn't restore it into a working state

Is this a request for help?:
NO
Is this a BUG REPORT or FEATURE REQUEST? (choose one):
YES

When you install the helm chart for replicas = 1, and then delete the running pod, it comes back up but with a readiness prob failed state and db doesn't work.
Version of Helm and Kubernetes:
helm : 2.10
k8s : 1.10
Which chart:
stable/cockroachdb
What happened:
deleting for from statefulset breaks the cockroachdb
What you expected to happen:
cockroachdb can't restore itself.
How to reproduce it (as minimally and precisely as possible):
kubectl scale statefulset my-release-cockroachdb --replicas=1
kubectl delete po my-release-cockroachdb-0

which will start cockroachdb in failed state.
NAME                                    READY     STATUS      RESTARTS   AGE
my-release-cockroachdb-0            0/1       Running     0          5m
my-release-cockroachdb-init-6t5q6   0/1       Completed   0          15m

** anything else we should know about **
logs
W180829 23:38:27.086169 152 sql/jobs/registry.go:286  unable to get node liveness: node not in the liveness table
W180829 23:38:27.433420 117 storage/store.go:1463  [n1,s1,r7/1:/Table/{SystemCon…-11}] could not gossip system config: [NotLeaseHolderError] r7: replica (n1,s1):1 not lease holder; lease holder unknown
I180829 23:38:27.952348 16476 gossip/client.go:129  [n1] started gossip client to my-release-cockroachdb-0.my-release-cockroachdb:26257
I180829 23:38:27.952917 16476 gossip/client.go:134  [n1] closing client to node 1 (my-release-cockroachdb-0.my-release-cockroachdb:26257): stopping outgoing client to node 1 (my-release-cockroachdb-0.my-release-cockroachdb:26257); loopback connection
W180829 23:38:28.466634 117 storage/store.go:1463  [n1,s1,r7/1:/Table/{SystemCon…-11}] could not gossip system config: [NotLeaseHolderError] r7: replica (n1,s1):1 not lease holder; lease holder unknown

And
kubectl describe po my-release-cockroachdb-0
logs
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  datadir-my-release-cockroachdb-0
    ReadOnly:   false
  default-token-dx7d8:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-dx7d8
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason                 Age               From               Message
  ----     ------                 ----              ----               -------
  Normal   Scheduled              8m                default-scheduler  Successfully assigned my-release-cockroachdb-0 to minikube
  Normal   SuccessfulMountVolume  8m                kubelet, minikube  MountVolume.SetUp succeeded for volume "pvc-54d81355-abe2-11e8-819b-080027096c35"
  Normal   SuccessfulMountVolume  8m                kubelet, minikube  MountVolume.SetUp succeeded for volume "default-token-dx7d8"
  Normal   Pulling                8m                kubelet, minikube  pulling image "cockroachdb/cockroach:v2.0.5"
  Normal   Pulled                 8m                kubelet, minikube  Successfully pulled image "cockroachdb/cockroach:v2.0.5"
  Normal   Created                8m                kubelet, minikube  Created container
  Normal   Started                8m                kubelet, minikube  Started container
  Warning  Unhealthy              3m (x58 over 7m)  kubelet, minikube  Readiness probe failed: HTTP probe failed with statuscode: 500```

@prashant182 A default CockroachDB with --replicas=3 will withstand a single node failure without any loss of service time or data.  Is there a specific reason to use 1 replica instead of default 3 that provides the HA capability?

Clusters, where we are deploying cockroachdb, doesn't necessarily have their ntp time sync. So we are keeping statefulset to 1 node.  If customers want to scale cockroachdb then they do the ntp timesync across their linux nodes and then they can scale it using kubectl scale statefulset ... --replicas=n.  Sometimes we can not This was our reasoning, we welcome other suggestions. Sometimes those clusters are in an air-gapped environment so customers are required to do ntp sync on their preferred method.

What are "air-gapped" environment limitations and accepted tradeoffs?
For example, in terms of infrastructure, limitations might be CPU, RAM, Network, Storage capacity, running in a single replica, not changing the replica count once started, not reducing replica count below a certain level once expanded.
The consequential tradeoffs could be reduced choice of database cluster topology patterns to choose from, maximum concurrency the database can accept, RPO and RPO, backup and recovery SLA, number of microservices or multitenancy per K8, the complexity of SQL or Schema.

An “air-gapped” environment is a network that has no path to inbound or outbound internet traffic at all. So in terms of support and installation, we can not assume things that rely on the internet such as timesync. I believe on cockraochdb official website, the recommended way is to use server time1.google.com iburst which might not be available for air-gapped environment, so we are not hitting all the points from your production checklist.

Also, the helmchart that is provided for such systems needs to be rock-solid and resilient in terms of reliability and failure tolerance. Let's say the single node cockroachdb goes down, then we should have a k8s cron job or some sort of mechanism which keeps checking on the health of the database and performs a series of steps to recover it from the failure. I have seen that k8s respawning of the crashed pod is not a reliable solution at least for cockroachdb.  Database is a fundamental platform to build apis and services upon, so downtime in a database affect all of these services.

Hi @prashant182, the problem is that you created a 3 node cluster and then scaled it down to 1 node when you ran the kubectl scale statefulset my-release-cockroachdb --replicas=1 command. Once cockroach has replicated its data to 3 or more nodes, scaling down to 1 node is no longer supported.  In other words, your cluster stopped working because of the kubectl scale command, not because of the subsequent kubectl delete commands.
If you want a 1 node cluster, you must start it with only 1 node:
helm install stable/cockroachdb --name=my-release --set Replicas=1

That 1 node cluster should then be just fine across restarts and other such issues. If you manage to hit a problem after starting the cluster with just 1 node, I'd be incredibly interested to know about it.

@a-robinson Sorry for late response, Turns out you were right, scaling statefulset up and down was the issue, keeping it to a single node worked out well.

authors: a-robinson prashant182 robert-s-lee

repo: helm/charts


text:
[stable/moodle] Use global registry in secondary and/or metrics images

Signed-off-by: Carlos Rodriguez Hernandez crhernandez@bitnami.com
Allow using global.imageRegistry (already implemented for the main images) in the metrics container and/or other secondary containers.
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

/ok-to-test
/lgtm


text:
[stable/minio] Bump version minio

Signed-off-by: Login Victor batazor111@gmail.com

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

fixes #

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

[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 @nitisht
/assign @wlan0

/ok-to-test
/assign
/lgtm

authors: batazor davidkarlsen


text:
[stable/kong] custom plugins support

Refactor out volumes and volumeMounts into helpers
Allow users to easily mount custom plugins via secrets and configmaps
Custom plugins containing custom DAOs are allowed as well

A guide will be published in near future on how to exactly use this
feature.
In a subsequent PR, we will de-duplicate env and initContainer sections
in the migrations jobs to reduce duplication.
Signed-off-by: Harry Bagdi harrybagdi@gmail.com

What this PR does / why we need it:
Allows users to install and use custom plugins easily in Kong.
Special notes for your reviewer:
ping @shashiranjan84 @rainest
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])

Here is the documentation for this:
https://github.com/Kong/kubernetes-ingress-controller/pull/423

Would there be any concern automatically setting KONG_PLUGINS in the main deployment as well?
I'd like to have as few things as possible require multiple pieces of configuration in different sections of values.yaml, and I expect that the use case for "make plugin available on the filesystem, but do not load it" is small (if one exists at all).
If we do populate it automatically, it's still possible to manually disable plugins by setting plugins under .Values.env and excluding a plugin, since that's evaluated last and would take precedence.

@rainest I didn't do it only because I couldn't figure out how to do it.
Took me a while to get it done but it's there now. Please review the commit I just pushed.

/test pull-charts-e2e

@shashiranjan84 Updated.

authors: hbagdi rainest


text:
[stable/datadog] remove useConfigMap, use customAgentConfig for datadog-yaml-configmap

What this PR does / why we need it:
If you are adding customAgentConfig, it seems counter intuitive to need an additional boolean:
useConfigMap: true
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])

@johnpekcan
For signing DCO, you need to force push a commit as showing in https://github.com/helm/charts/pull/18053/checks?check_run_id=262878474

Hey @zanhsieh, I've updated my PR to remove the useConfigMap boolean entirely.
I've had a chance to revisit this, and I don't think it serves a real purpose.
If you are providing customAgentConfig -- you are going to be using a config map.
If you were to set useConfigMap to True .. you don't really gain anything outside of some generic values that are provided for you. What's the benefit of using a configmap without providing any custom agent params?
Let me know what you think!

/ok-to-test

Also, I've noticed that https://github.com/helm/charts/pull/17702 and this PR are very very similar. Should we group up and try to combine our PR's?  @grumpymatt

@johnpekcan what you are trying to achieve is indeed being discussed in the other PR, so I think we can close this one. Please comment on #17702 if you feel like something is not being addressed.

authors: johnpekcan xlucas zanhsieh


text:
[stable/nginx-ingress] Feature  apiVersion compatibility switch

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

/ok-to-test

/retest

/retest

/retest

/lgtm

Hi!
https://github.com/helm/charts/blob/master/stable/nginx-ingress/templates/controller-role.yaml#L85 still use hardcoded "extensions" apiversion for podSecurityPolicy =(
Maybe template this too?

authors: ChiefAlexander andrsp msschl zanhsieh


text:
[stable/cerebro] bump image

Signed-off-by: fabriziofortino fabrizio.fortino@gmail.com

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

/ok-to-test

/lgtm

authors: davidkarlsen fabriziofortino


text:
.Capabilities.HelmVersion.Version does not include the patch version

Let's suppose I'm using Helm version 3.16.1. When I execute the following:
{{- $version := semver .Capabilities.HelmVersion.Version -}}
I get 3.16.0.
Why does .Capabilities.HelmVersion not include the patch version? Is there any specific reason or advantage to omitting that information?

How was the Helm binary built? I'm not able to replicate your issue. I see the patch version accurately.

To be honest, I'm not able to reproduce it. Probably I was doing something wrong. Sorry.

authors: jdiegosierra mattfarina

repo: helm/helm


text:
Does sha256Sum change when the values are rendered?

This is in reference to the trick mentioned here: https://github.com/helm/helm/blob/master/docs/charts_tips_and_tricks.md#automatically-roll-deployments-when-configmaps-or-secrets-change
Would the sha256sum of configmap.yaml change if it is picking up values from values.yaml which are being changed from --set option in helm CLI?
Below is a detailed scenario:
configmap.yaml
    ---
    apiVersion: V2.23
    kind: ConfigMap
    metadata:
       name: my-configmap
    data:
       image.tag: {{ .Values.image.tag }}

deployment.yaml
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}

values.yaml
    image:
      repository: myrepo
      tag: latest
      pullPolicy: IfNotPresent

Jenkinsfile
            sh """
              helm upgrade --install --force \
              --namespace=default \
              --values=values.yaml \
              --set image.tag=${output_of_git-describe} \
              --set image.pullPolicy=Always \
              myimage kubernetes/myimage
           """

Will the sha256sum of configmap.yaml change since I am passing --set image.tag value from the command line?

Should do. Have you tried it and is it working?

How can I verify this? Is there a way to print out the sha256sum from hell cli after running helm upgrade?

@Omnipresent ,
Can I ask what is your use case for this scenario?

And by the way, the command you are looking for is probably helm upgrade --dry-run --debug ...
Hope this helps!

@maorfr The scenario is that we build our docker repo in Jenkins, push it to docker hub, and finally execute helm upgrade to deploy to our dev/test server. Instead, what we're noticing is that helm upgrade is not doing a restart so the new changes aren't reflected. This could be because our docker tag is same on each push to master. I am trying to change that by modifying some value in configmap.yaml via helm upgrade CLI such that the sha256 sum changes and helm restarts the pod. I hope this makes sense.

If I understood correctly -
The easy option is to use the --recreate-pods flag (and a pull policy of always).
But in general, I think it's probably best to have a unique image tag per push.
Hope this helped ;)

closing as answered but please let me know if we need to re-open this. Thanks!

authors: Omnipresent bacongobbler hickeyma maorfr omnipresent07


text:
do not run pre and post upgrade hooks if there are no changes in charts

I just noticed that if we run helm upgrade on charts with pre and post upgrade hooks and there is no actual upgrade (change) in charts, helm is still running pre and post upgrade hooks.
Was curious if that behaviour can be changed (do not run upgrade hooks if deployment will not be upgraded)?
i use helm version 2.16.6

during an upgrade, helm compares the chart against the previous chart, as well as the live state. There's more going on than the previous chart vs. the new chart. It is entirely possible that the patch generated based on those three parameters resulted in a change in the live state.
The code within help to generate this patch can be found here:
https://github.com/helm/helm/blob/97774ee13cf9289918555a46948532f8ae313c9d/pkg/kube/client.go#L364-L412
if there are no changes in the patch, then helm will not continue through the upgrade process.
https://github.com/helm/helm/blob/97774ee13cf9289918555a46948532f8ae313c9d/pkg/kube/client.go#L435-L443
Let us know if you find anything interesting.

I understand, however pre-upgrade hooks run even if there are no changes in the patch. I was expecting that pre-upgrade hooks should not run if the main charts are remaining the same.
here is sample of tiller log where nothing is changed during upgrade but pre-upgrade hooks run.
[storage] 2020/07/07 12:52:26 getting release history for "frank-mariadb-galera"
[tiller] 2020/07/07 12:52:26 preparing update for frank-mariadb-galera
[storage] 2020/07/07 12:52:26 getting deployed releases from "frank-mariadb-galera" history
[storage] 2020/07/07 12:52:26 getting last revision of "frank-mariadb-galera"
[storage] 2020/07/07 12:52:26 getting release history for "frank-mariadb-galera"
[tiller] 2020/07/07 12:52:27 rendering mariadb-galera chart using values
2020/07/07 12:52:27 info: manifest "mariadb-galera/templates/backup/pvc.yaml" is empty. Skipping.
2020/07/07 12:52:27 info: manifest "mariadb-galera/templates/pv.yaml" is empty. Skipping.
2020/07/07 12:52:27 info: manifest "mariadb-galera/templates/backup/pv.yaml" is empty. Skipping.
2020/07/07 12:52:27 info: manifest "mariadb-galera/templates/backup/cronjob.yaml" is empty. Skipping.
[tiller] 2020/07/07 12:52:27 creating updated release for frank-mariadb-galera
[storage] 2020/07/07 12:52:27 creating release "frank-mariadb-galera.v10"
[tiller] 2020/07/07 12:52:27 performing update for frank-mariadb-galera
[tiller] 2020/07/07 12:52:27 executing 5 pre-upgrade hooks for frank-mariadb-galera
[tiller] 2020/07/07 12:52:27 deleting pre-upgrade hook frank-mariadb-galera-upgrade-deployment for release frank-mariadb-galera due to "before-hook-creation" policy
[kube] 2020/07/07 12:52:27 Starting delete for "frank-mariadb-galera-upgrade-deployment" ConfigMap
[kube] 2020/07/07 12:52:27 Waiting for 60 seconds for delete to be completed
[kube] 2020/07/07 12:52:29 building resources from manifest
[kube] 2020/07/07 12:52:29 creating 1 resource(s)
[kube] 2020/07/07 12:52:29 Watching for changes to ConfigMap frank-mariadb-galera-upgrade-deployment with timeout of 5m0s
[kube] 2020/07/07 12:52:29 Add/Modify event for frank-mariadb-galera-upgrade-deployment: ADDED
[tiller] 2020/07/07 12:52:29 deleting pre-upgrade hook frank-mariadb-galera-pre-upgrade for release frank-mariadb-galera due to "before-hook-creation" policy
[kube] 2020/07/07 12:52:29 Starting delete for "frank-mariadb-galera-pre-upgrade" Job
[kube] 2020/07/07 12:52:29 Waiting for 60 seconds for delete to be completed
[kube] 2020/07/07 12:52:31 building resources from manifest
[kube] 2020/07/07 12:52:31 creating 1 resource(s)
[kube] 2020/07/07 12:52:31 Watching for changes to Job frank-mariadb-galera-pre-upgrade with timeout of 5m0s
[kube] 2020/07/07 12:52:31 Add/Modify event for frank-mariadb-galera-pre-upgrade: ADDED
[kube] 2020/07/07 12:52:31 frank-mariadb-galera-pre-upgrade: Jobs active: 0, jobs failed: 0, jobs succeeded: 0
[kube] 2020/07/07 12:52:31 Add/Modify event for frank-mariadb-galera-pre-upgrade: MODIFIED
[kube] 2020/07/07 12:52:31 frank-mariadb-galera-pre-upgrade: Jobs active: 1, jobs failed: 0, jobs succeeded: 0
[kube] 2020/07/07 12:53:52 Add/Modify event for frank-mariadb-galera-pre-upgrade: MODIFIED
[tiller] 2020/07/07 12:53:52 hooks complete for pre-upgrade frank-mariadb-galera
[kube] 2020/07/07 12:53:52 building resources from updated manifest
[kube] 2020/07/07 12:53:52 checking 5 resources for changes
[kube] 2020/07/07 12:53:52 Looks like there are no changes for Secret "frank-mariadb-galera-db-root-password"
[kube] 2020/07/07 12:53:52 Looks like there are no changes for Secret "frank-mariadb-galera-db-user-credentials"
[kube] 2020/07/07 12:53:52 Looks like there are no changes for ConfigMap "frank-mariadb-galera"
[kube] 2020/07/07 12:53:52 Looks like there are no changes for Service "mariadb-galera"
[tiller] 2020/07/07 12:53:52 executing 5 post-upgrade hooks for frank-mariadb-galera
[tiller] 2020/07/07 12:53:52 deleting post-upgrade hook frank-mariadb-galera-post-upgrade-deployment for release frank-mariadb-galera due to "before-hook-creation" policy
[kube] 2020/07/07 12:53:52 Starting delete for "frank-mariadb-galera-post-upgrade-deployment" ConfigMap
[kube] 2020/07/07 12:53:53 Waiting for 60 seconds for delete to be completed
[kube] 2020/07/07 12:53:55 building resources from manifest
[kube] 2020/07/07 12:53:55 creating 1 resource(s)
[kube] 2020/07/07 12:53:55 Watching for changes to ConfigMap frank-mariadb-galera-post-upgrade-deployment with timeout of 5m0s
[kube] 2020/07/07 12:53:55 Add/Modify event for frank-mariadb-galera-post-upgrade-deployment: ADDED
[tiller] 2020/07/07 12:53:55 deleting post-upgrade hook frank-mariadb-galera-post-upgrade for release frank-mariadb-galera due to "before-hook-creation" policy
[kube] 2020/07/07 12:53:55 Starting delete for "frank-mariadb-galera-post-upgrade" Job
[kube] 2020/07/07 12:53:55 Waiting for 60 seconds for delete to be completed
[kube] 2020/07/07 12:53:57 building resources from manifest
[kube] 2020/07/07 12:53:57 creating 1 resource(s)
[kube] 2020/07/07 12:53:57 Watching for changes to Job frank-mariadb-galera-post-upgrade with timeout of 5m0s
[kube] 2020/07/07 12:53:57 Add/Modify event for frank-mariadb-galera-post-upgrade: ADDED
[kube] 2020/07/07 12:53:57 frank-mariadb-galera-post-upgrade: Jobs active: 0, jobs failed: 0, jobs succeeded: 0
[kube] 2020/07/07 12:53:57 Add/Modify event for frank-mariadb-galera-post-upgrade: MODIFIED
[kube] 2020/07/07 12:53:57 frank-mariadb-galera-post-upgrade: Jobs active: 1, jobs failed: 0, jobs succeeded: 0
[kube] 2020/07/07 12:57:23 Add/Modify event for frank-mariadb-galera-post-upgrade: MODIFIED
[tiller] 2020/07/07 12:57:23 hooks complete for post-upgrade frank-mariadb-galera
[storage] 2020/07/07 12:57:23 updating release "frank-mariadb-galera.v9"
[tiller] 2020/07/07 12:57:23 updating status for updated release for frank-mariadb-galera
[storage] 2020/07/07 12:57:23 updating release "frank-mariadb-galera.v10"
[storage] 2020/07/07 12:57:23 getting last revision of "frank-mariadb-galera"
[storage] 2020/07/07 12:57:23 getting release history for "frank-mariadb-galera"
[kube] 2020/07/07 12:57:24 Doing get for Secret: "frank-mariadb-galera-db-user-credentials"
[kube] 2020/07/07 12:57:24 Doing get for Secret: "frank-mariadb-galera-db-root-password"
[kube] 2020/07/07 12:57:24 Doing get for ConfigMap: "frank-mariadb-galera"
[kube] 2020/07/07 12:57:24 Doing get for Service: "mariadb-galera"
[kube] 2020/07/07 12:57:24 Doing get for StatefulSet: "frank-mariadb-galera"
[kube] 2020/07/07 12:57:24 get relation pod of object: frank/Secret/frank-mariadb-galera-db-user-credentials
[kube] 2020/07/07 12:57:24 get relation pod of object: frank/Secret/frank-mariadb-galera-db-root-password
[kube] 2020/07/07 12:57:24 get relation pod of object: frank/ConfigMap/frank-mariadb-galera
[kube] 2020/07/07 12:57:24 get relation pod of object: frank/Service/mariadb-galera
[kube] 2020/07/07 12:57:24 get relation pod of object: frank/StatefulSet/frank-mariadb-galera```

Hi, @maratsal - in our previous explanation, we were talking about the new three-way merge in Helm 3: https://helm.sh/docs/faq/#improved-upgrade-strategy-3-way-strategic-merge-patches
I will close this issue as we are not accepting feature requests or bugfixes for Helm 2.
As you are using Helm 2, our recommendation is to migrate to Helm 3. Helm 2 is no longer receiving bugfixes and will very soon not even receive security patches. So you will want to move to Helm 3: https://helm.sh/blog/helm-v2-deprecation-timeline/

Hi all, quick question. What is the expected behavior when  working with sub-chart. That is, attaching a hook to a sub-chart. Will the hook attached to the sub-chart only be executed when the sub-chart change, or anytime the umbrella chart changes ?

I'm still having still issue with latest helm and also with helm_release terraform resource.

authors: Maatary angeloudy bacongobbler bridgetkromhout maratsal


text:
3.5.3 build fails on linux

Output of helm version:
% bin/helm version
version.BuildInfo{Version:"v3.5.3", GitCommit:"041ce5a2c17a58be0fcd5f5e16fb3e7e95fea622", GitTreeState:"dirty", GoVersion:"go1.16.1"}

Output of kubectl version:
% kubectl version
Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.0", GitCommit:"e19964183377d0ec2052d1f1fa930c4d7575bd50", GitTreeState:"clean", BuildDate:"2020-08-26T14:30:33Z", GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"18+", GitVersion:"v1.18.12-gke.1210", GitCommit:"199a41188dc0ca5d6d95b1cc7e8ba96e05f9dd0a", GitTreeState:"clean", BuildDate:"2021-02-05T18:03:16Z", GoVersion:"go1.13.15b4", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):
N/A
Building with make build fails for 3.5.3 in some situations. I know virtually nothing about go but following the directions from the compiler seemed to fix the problem and update go.sum (hence "dirty" above). I noticed this while trying to install with linuxbrew and found Homebrew/linuxbrew-core#22543. While this may be related to something in linuxbrew, it seems unlikely to me since the fix was known by the compiler and changed go.sum (which I'm guessing is something like a library lock file) and looking at the formula it's just calling make build which seems to be the usual instructions.
Here's the error msg I get trying to build:
% make build
GO111MODULE=on go build  -tags '' -ldflags '-w -s -X helm.sh/helm/v3/internal/version.version=v3.5.3 -X helm.sh/helm/v3/internal/version.metadata= -X helm.sh/helm/v3/internal/version.gitCommit=041ce5a2c17a58be0fcd5f5e16fb3e7e95fea622 -X helm.sh/helm/v3/internal/version.gitTreeState=dirty -X helm.sh/helm/v3/pkg/lint/rules.k8sVersionMajor=1 -X helm.sh/helm/v3/pkg/lint/rules.k8sVersionMinor=20 -X helm.sh/helm/v3/pkg/chartutil.k8sVersionMajor=1 -X helm.sh/helm/v3/pkg/chartutil.k8sVersionMinor=20' -o '/tmp/helm-20210312-108426-19uzocz/bin'/helm ./cmd/helm
/home/<USER>/.cache/Homebrew/go_mod_cache/pkg/mod/github.com/moby/moby@v17.12.0-ce-rc1.0.20200618181300-9dc6525e6118+incompatible/pkg/system/path.go:9:2: missing go.sum entry for module providing package github.com/containerd/continuity/pathdriver (imported by github.com/docker/docker/pkg/system); to add:
        go get github.com/docker/docker/pkg/system@v1.4.2-0.20200203170920-46ec8731fbce
make: *** [Makefile:78: /tmp/helm-20210312-108426-19uzocz/bin/helm] Error 1

Simply running go get github.com/docker/docker/pkg/system@v1.4.2-0.20200203170920-46ec8731fbce as instructed allowed it to build and it seems ok but I didn't do much testing.
If you think this is a env problem related to linuxbrew please just let me know (though it would be great if you had any insight into what the problem could be) and I'll try to adjust the brew formula instead.

The latest builds on CircleCI seem to be passing, which runs on a linux machine: https://app.circleci.com/pipelines/github/helm/helm/2296/workflows/2fac5573-76a7-415f-8155-722883bce9a2/jobs/13863
Let us know what you discover.

Might be relevant: https://github.com/helm/helm/blob/543364fba59b0c7c30e38ebe0f73680db895abb6/go.mod#L51-L54

I don't know if this problem came up only with the new Go version 1.16.2 (released on 11/03).
Anyway, with an additional 'go mod tidy' the build problem is fixed.

@dbro86 @bacongobbler Tidy up of dependencies pushed in #9486

authors: bacongobbler dbro86 hickeyma xaocon


text:
Show diff for *chart.Chart

Right now we only show diff for manifests. But we also can show diff for *chart.Chart - this way users will be able to track chart changes (version, repository, name, etc.)

There is a library for this - https://github.com/r3labs/diff
But it doesn't generate diff output. We can use it and add all differences as logrus fields.

repo: helmwave/helmwave


text:
update {{subtract}} documentation

Added the missing parameter to the in code documentation.

thanks!

authors: foundy jonschlinkert

repo: helpers/handlebars-helpers

license: mit

license_source: bigquery


text:
Fix Avatar that was flashing when loading was completed

The avatar component was flashing when updating the state from loading to loaded. It was cause by the Avatar.Crop component changing his background image to currentColor to transparent.
By removing that line we make sure the avatar will fade in on top of the placeholder color

Pull Request Test Coverage Report for Build 2565

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

Totals

Change from base Build 2559:
0.0%

Covered Lines:
21

Relevant Lines:
21

💛  - Coveralls

authors: coveralls plbabin

repo: helpscout/hsds-react


text:
Use secure cloudinary link

PR regarding https://github.com/helpyio/helpy/issues/142

The original reporter of this issue suggested using just //res.cloudinary.com/#{Cloudinary.config.cloud_name}/image/upload what do you think about this as opposed to hard coding https  I am curious what the difference is, will that not work because you have to specify secure in the config?

I have used secure option in config so that it will always use https instead of http when we use cl_image_tag, and on the places where there is static http used I have replace them with https to prevent passive mixed content.

repo: helpyio/helpy


text:
WIP: コミュニティ外に開放するにあたり気になった部分を編集してみました。

ユーザーが自由に追加できるstorageの配列を別の関数内でfor文に使った場合、悪意のあるユーザーが大量に配列を追加すると、ガス代の上限のせいでfor文がリバートされ関数自体が動かなくなるというバグがあるそうです。
上の観点から、

registerした年賀状を取得する関数（retrieveRegisteredNengajo()）
mintした年賀状を取得する関数（retrieveMintedNengajoes()）

の安全性を高めるために、試作としてregisterとmintのtokenIdのリストをユーザーのアドレスをキーとしたmappingにまとめ、registerNengajo()、mint()、mintBatch()で記録してみました。
mapping(address => uint256[]) private ownerOfRegisteredIds;
mapping(address => uint256[]) private ownerOfMintedIds;

ガス代がそこそこ上がってしまったのですが、一案としてご意見伺えたら有難いです！

@yawn-c111
提案ありがとうございます！for文の分母を対象addressだけにするということですね
今回の実装ではよさそうです！
TheGraphとかindexサービス使う場合はこういうことしなくても良いと思うので、ガス代節約ポイントにはなりそうですね。おもしろいポイントです

repo: henkaku-center/henkaku-nengajo-contract


text:
Refactor and new feature

Refactor vertical move handler
Add restart feature by pressing "r" button

Hi @mahdiarn, thanks for making this PR. Sorry it's taken me so long to check it out, I haven't had access to a Mac quite a while. I'll take a look at this now and get back to you.

Hi @mahdiarn, I've finally got round to reviewing this PR. Unfortunately, I can see little benefit in your refactor; it, if anything, makes the code harder to read than before.
Sticking arbitrary parts of the code into functions with no arguments, which are called only once, means that if I were to want to make or review changes in that part of the code, I would have to track them down by following the function call breadcrumbs you've left for me, instead of intuitively finding them in the place they run. I would see benefit to such a refactor if you were to use it as an opportunity to reorganise the layout of the codebase, perhaps clearly separating the handlers you've created into a separate file, allowing for the easy viewing and editing of the code contained within, as opposed to the currently presented random assortment of functions strewn across GameScene.swift (I do think that such a change is overkill here though, it just serves as an example). Additionally, the handlers don't need 'handle' in their names - it's implied, and the function names already contain verbs e.g. restartGame instead of handleRestartGame.
I'd be more than happy to accept this PR if you sort out the refactored functions, as restart functionality is something I need to add, as per issue #13. I would suggest that perhaps comments would be a suitable way of indicating the function of the code blocks you've singled out, rather than individual functions.
I understand that not all of my original codebase follows this guideline, but that's because I never considered that other people would see it. It's my aim to slowly move this project away from spaghetti, so that others like you can contribute and pick up my (plentiful) slack. I really appreciate the time and effort you've put into this PR, and hopefully the changes I've outlined can help get it merged quickly.

Closing due to inactivity.

authors: henryefranks mahdiarn

repo: henryefranks/pac-bar


text:
move pvRestorer and tests to their own files

Signed-off-by: Steve Kriss krisss@vmware.com
I pulled the pvRestorer type and its associated tests out of restore.go and into their own files.  restore.go is a behemoth and I'm trying to do some cleanup to make it a little more manageable.

argh, always make update!! updated :)

repo: heptio/velero


text:
Cloning to plugins folder results in File Not Found +  error 500

Hi, I seem to be unable to use Pico-FeedMaker. If I clone it into my Pico plugins directory, even without enabling it in config.yml, I get the following error coming up:
AH01071: Got error 'PHP message: PHP Fatal error:  Uncaught RuntimeException: Unable to load plugin 'Pico-FeedMaker' from 'Pico-FeedMaker/Pico-FeedMaker.php': File not found in /var/www/site.com/pico/vendor/picocms/pico/lib/Pico.php:639\nStack trace:\n#0 /var/www/site.com/pico/vendor/picocms/pico/lib/Pico.php(520): Pico->loadLocalPlugins(Array)\n#1 /var/www/site.com/pico/vendor/picocms/pico/lib/Pico.php(401): Pico->loadPlugins()\n#2 /var/www/site.com/pico/index.php(33): Pico->run()\n#3 {main}\n  thrown in /var/www/site.com/pico/vendor/picocms/pico/lib/Pico.php on line 639\n'

Hi,
how exactly did you clone the repo?
As mentioned in the readme you should clone via: git clone https://github.com/hermannmarkus/Pico-FeedMaker.git FeedMaker
The FeedMaker at the end is important, because it will clone into the folder FeedMaker. When you clone without it, git will clone into the folder Pico-FeedMaker. From your error message it seems like this happened.
The problem is that pico will look for the plugin class dependent of the folder name. So when you clone into FeedMaker it will look for the class FeedMaker. So, when you cloned into Pico-FeedMaker Pico will look for another class.
Just renaming the folder to FeedMaker should fix the error.

authors: hermannmarkus zerojay

repo: hermannmarkus/Pico-FeedMaker


text:
Nakama authentication returns an error on iOS

Authenticating with Nakama returns this error when using nakama.authenticate_device(), nakama.authenticate_custom(), nakama.authenticate_apple(),  nakama.authenticate_game_center() and nakama.authenticate_email() on iOS:
ERROR:SCRIPT: HTTP request to 'http://127.0.0.1:7350/v2/account/authenticate/apple?username=Niclas&create=true' failed (http result: -1  socket result: -24)
DEBUG:SCRIPT:
{ --[[0x10b469ad0]]
  message = "Unable to decode response",
  error = true
}

This line (and probably some other logs):
https://github.com/heroiclabs/nakama-defold/blob/master/nakama/engine/defold.lua#L67
Returns this:
DEBUG:SCRIPT: /v2/account/authenticate/device    with coroutine
DEBUG:SCRIPT: HTTP    POST    http://127.0.0.1:7350/v2/account/authenticate/device?username=Niclas&create=true
DEBUG:SCRIPT: DATA    {"id":"ccac5124-3e27-49c8-c93a-020000000000"}

Using nakama.authenticate_device(), nakama.authenticate_custom() and nakama.authenticate_email() works in the local Defold player on Mac.

It turns out that this is the default error message when no connection can be made. When testing I incorrectly used 127.0.0.1 on both the Mac and the iPhone. This means the iPhone tried to connect to its own localhost, which of course doesn't work.
The solution to test locally is to find the actual local IP of the server and use that for external devices.

Oh, good to hear that you managed to figure it out!

authors: britzl totebo

repo: heroiclabs/nakama-defold


text:
Fail fast if cannot retrieve migration history from database

Fail fast if cannot retrieve migration history from database. #22
Print database DSNS when migrating. #21
Improve checking for existing database entity in the database.

@mofirouz Looks good 👍

authors: mofirouz novabyte

repo: heroiclabs/nakama


text:
Warning BaseWithApp

I am receiving this error after upgrading to the latest heroku. It is killing my deployment scripts.
/Library/Ruby/Gems/1.8/gems/heroku-2.16.1/lib/heroku/command/base.rb:209: warning: already initialized constant BaseWithApp
!     !    Resource not found
/Library/Ruby/Gems/1.8/gems/heroku-2.16.1/lib/heroku/command/base.rb:209: warning: already initialized constant BaseWithApp

After downgrading to 2.15.3 everything worked again.

@sjonnet19 Hmm. I don't believe that the warning should actually be causing the problem in and of itself. There may be some other issues that were introduced during the cleanup.  Could you  give me some context around what you are trying to do and what command is actually failing so I can try to get it fixed for you?  Thanks!

I'm attempt with my scripts to destroy apps and/or create apps then add add ons and start a worker.
I think the warning does f with my script though. I am removing my err checks to see if that fixes it.

Any reason for the warnings?
By removing my catches it fixed it...

No good reason for the warning no, I just made a mistake in how I did it.  The file must be getting required/loaded more than once some how.  In any event, I just pushed a commit that should prevent it here:
https://github.com/heroku/heroku/commit/3e133703df54bd22f55942bbd3681022bb888170
Sorry for the confusion and difficulty, glad you found a quick workaround.

Thank you for the help and quick turn around as well.

repo: heroku/heroku


text:
Update rest-client gem because security vulnerabilities

@balazslaszlo I made two small changes for readability, but otherwise it looks good

lgtm

authors: dickeyxxx ransombriggs


text:
🛑 Software Center - Test 1 is down

In 0791cfe, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in e7c9dcb.

repo: herrphon/upptime


text:
🛑 Software Center - Test 1 is down

In b0ddd0a, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 9b8d30f.


text:
🛑 Software Center - Test 1 is down

In f14ae92, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 0a12f42.


text:
🛑 Software Center - Test 1 is down

In 91c6baf, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 8ddfbfe.


text:
🛑 Software Center - Test 1 is down

In 8e7214d, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 050e3ac after 34 minutes.


text:
🛑 Software Center - Test 1 is down

In c1fcc67, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in e4c9c45 after 10 minutes.


text:
🛑 Auth-Bridge - Test 1 is down

In ac1310f, Auth-Bridge - Test 1 ($AUTH_BRIDGE_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in ccd78d3 after 38 minutes.


text:
🛑 Software Center - Test 1 is down

In d438c53, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in baeee38 after 2 hours, 30 minutes.


text:
🛑 Auth-Bridge - Test 1 is down

In c8ebeeb, Auth-Bridge - Test 1 ($AUTH_BRIDGE_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in 6e699c2 after 10 minutes.


text:
🛑 Auth-Bridge - Test 1 is down

In 6650e19, Auth-Bridge - Test 1 ($AUTH_BRIDGE_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in dc6a922 after 43 minutes.


text:
🛑 Software Center - Test 1 is down

In 8dca89f, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in b6fbb29 after 29 minutes.


text:
🛑 Software Center - Test 1 is down

In c5a4da4, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 8827448 after 38 minutes.


text:
🛑 Auth-Bridge - Test 1 is down

In 149f260, Auth-Bridge - Test 1 ($AUTH_BRIDGE_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in be5ebe1.


text:
🛑 Auth-Bridge - Test 1 is down

In c587c1b, Auth-Bridge - Test 1 ($AUTH_BRIDGE_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in 971883a.


text:
🛑 Software Center - Test 1 is down

In 8b1e679, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 3715d7b.


text:
Azure: delete everything

infrastructure clean up

@ggebel Do you mean azure files in deployments or docs?

@Anu-Ra-g We are cleaning up some older instances that are no longer used

authors: Anu-Ra-g ggebel

repo: hexa-org/policy-orchestrator


text:
A little supplement to the get_train_instances()

Mr.He,
Thanks a lot for your great work! I have learned a lot from it！
I've noticed that the get_train_instances() method is trying to get the input consists of positive and negative examples.The way to get the negative examples is sampling the item that [user,item] is not appeared in the train set.But there is a small possibility that [user,item] shows in the test set.So I just edit the GMF.py,MLP.py,NeuMF.py files to add a  condition to determine  whether the [user,item] exists in the test set.
I am just a general graduate,so I'm a little bit nervous that if I have made any mistake.I'll appreciate a lot if you can point out any mistake that I've made.
Thank you again！

Thanks for your efforts!
On Tue, Feb 2, 2021 at 12:09 PM Davezqq notifications@github.com wrote:

Closed #71.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

--
Xiangnan HE (Dr) :: Professor :: Vice Dean, School of Data Science ::
University of Science and Technology of China (USTC) :: 443 Huangshan
Road, Hefei, China 230027 :: (0551) 63607236 (DID) :: hexn@ustc.edu.cn
(E) :: http://staff.ustc.edu.cn/~hexn/ (W)

authors: Davezqq hexiangnan


text:
Allow passing of rsync parameters

Would be great if rsync parameters could be passed on a per server basis, eg
"servers": {
    "test": {
        "user": "user",
        "host": "some.hostname",
        "webroot": "subdomains/staging",
        "rsync-params": "--no-perms"
    }
}

@icecaster can you give some more detail on your use case for this? What kind of constraints/setup do you have that requires this? If it's a common, general problem it's possibly better to add an option in Beam for it.

Hey @stecman
My use case is that the files & folders in the web root of my server should be owned by the web user (www-data) - not the deployment user.
Rsync will try to apply same permissions as per git, which causes it to fail, throwing errors.

Hmm, do you have an error message example? Also, is this solved for you by using --no-perms, or is that a random example?
There's a known issue with target directory permissions being synced, which causes an error if the user doesn't have permission to change the mode of the target folder. We technically shouldn't be syncing that permission as it's not from the repository.

This would be related to this issue, setting permissions on parent directory:

I could also see this being an issue when 2 different users are deploying to the same target

I've had a look at possible solutions/workarounds for this, and it doesn't look like there's a quick change we can make to skip permission syncing on the target directory.

As far as I can tell, Rsync doesn't have a way to selectively sync permissions at all, and doesn't provide a way to specify the root/target directory in a filter/exclude rule.
Syncing directorie contents (source/) appears to be required for deletion of files that are missing from the source but exist on the target. Syncing explicit files from the source (source/*) doesn't delete removed files from the target, and specifying the missing files on the source side causes rsync to error.

Adding an option in the Beam config to not sync permissions is my vote to solve this, since there's more than one case where syncing them isn't required/desired:

Permissions on the root directory differ between source and target and the target directory is not owned by the ssh user (your case)
Permissions disabled in Git (git config core.fileMode false). The permissions from git archive are inherited from the source system and aren't really meaningful.
The target system has a different umask to the source and this needs to be honoured. For example Some shared hosting will refuse to serve PHP files that have group write permission, which currently requires a Beam command to chmod before deploying.
Custom acls (eg. setfacl) or some other permissions scheme is in use on the target that specifies how permissions are inherited.

How about this?
{
    "servers": [
        {
            // ...
            "permissions": false
        }
    ]
}

FWIW I'm reluctant to add an equivalent to the --args option in the config, since that option was intended as more of a debugging/workaround tool than something for permanent solutions.

Agree with your points.
Only change suggested would be naming the config variable "syncPermissions"

Awesome, thanks!

authors: icecaster stecman

repo: heyday/beam


text:
Fix edge cases calculation often causing float overflows.

I noticed when trying to correct perspective transform from 4 arbitrary points, this routine often returns NaN thus destroying all further geometry calculations.
With the correction proposed I was able to make it work ideally on all cases for me.
This may also fix issue people refer to here

@snown can you do a code review?

I will take a look

I'll be merging this very soon and publish to cocoapods.

Work has been extremely busy lately, but I am hopeful that I will have time to take a look in the next 24 hours. Sorry for the delay.

This looks good. It's a pretty simple change, but it's smart.

Thanks for doing the code review. I'll publish this version tomorrow.

Published as version 1.2.3. Suitable tag version for this cute fix. Thanks @gavrix

Thanks you guys. Glad to help!

authors: gavrix hfossli snown

repo: hfossli/AGGeometryKit


text:
Use pyvisa compat/struct.py for python < 2.7.8

Use pyvisa.compat.struct instead of standard library struct module
resolves #30

Coverage decreased (-12.48%) to 11.87% when pulling 96ba5b075aaf0f680470e6ff6cf47263cb770af6 on daritter:compat_struct into 4d160450f06328b9399d7eba37e6cf56e6e6d59b on hgrecco:master.

Coverage decreased (-12.48%) to 11.87% when pulling 96ba5b075aaf0f680470e6ff6cf47263cb770af6 on daritter:compat_struct into 4d160450f06328b9399d7eba37e6cf56e6e6d59b on hgrecco:master.

authors: coveralls daritter

repo: hgrecco/pyvisa-py


text:
Broken on Hyper 3.0.0-canary.1

Breaks things like new tabs entirely.
Note that Hyper 3.x now use both WebGL and Electron v4, which are likely related:
https://github.com/zeit/hyper/pull/3329
https://github.com/zeit/hyper/pull/3368
Uncaught (in promise) TypeError: newCwd.trim is not a function
    at setCwd (/Users/dids/.hyper_plugins/node_modules/hypercwd/setCwd.js:9)

Fixed by #60

authors: Dids hharnisc

repo: hharnisc/hypercwd


text:
Term Modus and forward reasoning

We need to explain basic term modus at some point.
In particular people find it hard to distinguish between backwards argumentation (apply) and forward argumentation (not nicely implemented yet).
Maybe the syntax have j := even_squared h or replace h := even_squared h would be good to introduce?

For forward reasoning, we should in any case introduce 'apply at', now that it's in mathlib.

authors: TentativeConvert joneugster

repo: hhu-adam/Robo


text:
Garbage Collector

[x] Should remove orphaned Files or FileInfos.

[ ] Check if a group still exist. If not: delete all files and directories from the group. [Can use deleteService.deleteFolder]

To collect all the files, all the services need methods without permission checking, which isn't really elegant. Maybe we could change our restrictions and make the garbage collector a "special" component which can access all repositories by itlself?
@iTitus @KaFe23 @Segelzwerg

I don't know if it's practical but we could add a role called wallie who is allowed everything everywhere.

We don't need to add a new role, just create an account in the Garbage Collector class with the admin role (@Value("mops.material1.role.admin") or smth like that) and a name that makes it clear that it is an automated action happening (like [GARBAGE_COLLECTOR])

Does not work: We don't check Keycloak roles. We fetch the role of a user in a directory. And a user named "Garbage Collector" isn't in any group so it never has any permissions.

authors: Segelzwerg iTitus realemx


text:
对Redis的返回结果进行类型判断，如果是dict,list转为json字符串

Redis允许的命令添加 info。
增强兼容性。对Redis的返回结果进行类型判断，如果是dict,list转为json字符串。 不让前端处理复杂类型显示。

这个pr多了东西，关闭。

repo: hhyo/Archery


text:
add additional target types for cast() function

With this patch, the following additional cast() target types are now supported

Binary
Character
BigDecimal and BigInteger
Boolean (with caveats)
LocalTime
LocalDate
LocalDateTime

Also, length or precision/scale may be specified for target types.

cast(number as String(10))
cast(text as Binary(100)
cast(amount as BigInteger(20))
cast(measurement as BigDecimal(10, 5))

Of course, the length, precision, or scale might be ignored, depending on the database type defined by the Dialect. (In particular, the are always ignored on Spanner, which doesn't support length, precision, or scale in cast().)
Also, when any DECIMAL type occurs without an explicitly-defined precision, a database-specific default is used. This makes casting and DDL generation more portable across databases when you're using BigIntegers or BigDecimals.

Almost by side-effect, the patch also fixes an ancient problem where columns for mapped attributes of type BigInteger got a scale of 2 instead of 0. (A JavaTypeDescriptor now provides hints for default length/precision/scale instead of always defaulting to 255/19/2.)

I finally got fed up with maintaining this as a separate conflicting branch. So I cleaned up the conflicts, and merged it into #2879 as a single commit fc9f6025fb833564835a12e60d6e202563e44004 (though note that some earlier work had already been merged in 18123e704a1ec15b529e90395d59d793d740bfa2 and 5cbc2efa703c47d0285ada4333f5f55ced51cb16).
Closing.

repo: hibernate/hibernate-orm


text:
re-enable tests

https://github.com/hibernate/hibernate-orm/discussions/3889
Simple implementation of expanded cast-target support.  No registry at this point, and this version allows dot-ident

Applied this upstream after rebasing locally


text:
oracle connect error.

Hello..
i use Oracle Autonomous Data Warehouse.
jdbc url example : jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=server_name)(PORT=port))(CONNECT_DATA=(SERVICE_NAME=serviceName)))
https://docs.oracle.com/en/cloud/paas/autonomous-database/adbsa/connect-jdbc-thin-tls.html#GUID-364DB7F0-6F4F-4C42-9395-4BA4D09F0483
but connection error.
error message here
org.hibernate.service.spi.ServiceException: Unable to create requested service [org.hibernate.engine.jdbc.env.spi.JdbcEnvironment] due to: begin 0, end -1, length 235
at org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:277) ~[hibernate-core-6.2.2.Final.jar:6.2.2.Final]
	Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException:

https://docs.oracle.com/en/cloud/paas/autonomous-database/adbsa/connect-jdbc-thin-tls.html#GUID-364DB7F0-6F4F-4C42-9395-4BA4D09F0483

Are you sure this is an issue for Hibernate Reactive? Which dependencies are in your project?

I tested example source

org.hibernate.reactive.pool.impl.DefaultSqlClientPoolConfiguration
oraclePath method return empty string
oracleHost method throw exception
plese check this method..

It seems that the oracle driver support this type of syntax.
I will have a look as soon as I have some time. In the meanwhile, you can try this approach I've suggested some time ago on StackOverflow

repo: hibernate/hibernate-reactive


text:
HSEARCH-4674 DO NOT MERGE

https://hibernate.atlassian.net/browse/HSEARCH-4674
just to have some execution time to compare with https://github.com/hibernate/hibernate-search/pull/3796

Closing this one as we've already got the execution time from it. (see linked PR)

repo: hibernate/hibernate-search


text:
🛑 Kiwi Farms Forum is down

In 9c31d9b, Kiwi Farms Forum (https://kiwifarms.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Kiwi Farms Forum is back up in c23305c after 1 hour, 22 minutes.

repo: hickoryhouse/kf


text:
🛑 kiwifarms.us is down

In 7f75a8c, kiwifarms.us (https://kiwifarms.us) was down:

HTTP code: 0
Response time: 0 ms

Resolved: kiwifarms.us is back up in 00100c9 after 10 minutes.


text:
HSX coil set added to simsopt.configs

This PR adds the HSX coil set provided by Thomas Kruger to simsopt.configs.  Thanks to Thomas Kruger and a summer student, Hancya Han, for the assistance.

I think HSX.dat needs to be added?

added the missing HSX.dat file, and also added unit tests that compute BoozerSurfaces in the HSX configuration

added the missing HSX.dat file, and also added unit tests that compute BoozerSurfaces in the HSX configuration. If there are any other configurations that would be nice to add to SIMSOPT, let me know.

Some possible other configs: w7x, the coils from the PNAS paper, and the coils from your SurfaceOpt paper.
It might be worth having some comments at the top of the  .dat files explaining the format. Could be a separate PR.

great, any suggestions of whom to contact for the W7X coils?

Joachim Geiger @.***) is the vmec guru at
IPP-Greifswald, and he would likely have the coils used to compute the
"official" W7-X free-boundary vmec equilibria.
On Thu, Aug 11, 2022 at 12:15 PM Andrew Giuliani @.***>
wrote:

great, any suggestions of whom to contact for the W7X coils?
—
Reply to this email directly, view it on GitHub
https://github.com/hiddenSymmetries/simsopt/pull/257#issuecomment-1212201218,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABH4ZA4HK65RBJZ6WTL74RLVYURJVANCNFSM56CFIS6Q
.
You are receiving this because your review was requested.Message ID:
@.***>

--
Dr. Matt Landreman
Associate Research Scientist
Institute for Research in Electronics & Applied Physics
University of Maryland
8223 Paint Branch Drive, College Park MD 20742, USA
(+1) 651-366-9306
@.***
https://terpconnect.umd.edu/~mattland/

added coils for the SurfaceOpt paper, still waiting on W7X coils

authors: andrewgiuliani landreman

repo: hiddenSymmetries/simsopt


text:
Add C23 keywords and types

Changes
This PR adds a few keywords that have been introduces in C23. Firstly, C now also has constexpr and the preprocessor got #elifdef and #elifndef. See https://en.cppreference.com/w/c/23.
Secondly, there are numerous extended floating point types (not yet documented on cppreference). See N3096 H.5.1 Keywords.
Checklist

[x] Added markup tests, or they don't apply here because this is a simple expansion of the keyword list
[x] Updated the changelog at CHANGES.md

You can merge or rebase on latest to get newest changelog.

authors: Eisenwave joshgoebel


text:
Negative lookbehind not supported in Firefox

This plugin is using negative lookbehind (?<! ...) which is not yet widely supported. In particular it doesn't work in Firefox yet, but also not in Safari or Edge as can be seen in MDN.
https://github.com/highlightjs/highlightjs-solidity/blob/3c0a75c7f075281b218f300331c18fd8fc076640/solidity.js#L133

Ah, good point.

+1 for this issue.
I had to downgrade back to 1.0.6 because it caused our app to crash in Firefox and Safari.

Oh geez, sorry, this was due to my PR.  For a fix... you could revert back to just using \b instead of the negative lookbehind I used?  It's not technically correct, but it'll likely be good enough most of the time?  Not sure what else to do; a complemented character set doesn't work as then the beginning gets included in the highlighting which isn't right at all.  I dunno, maybe someone else has some better idea.

@haltman-at Can you explain why \b is not technically correct with an example?

Sure.  The problem is that Solidity allows $ in variable names, but JavaScript doesn't count $ as a word character.  So, if you have a variable named, say, value$1, or even just $1, the highlighter should not highlight that 0 as a number, because it's part of a variable name.  However, if you use \b intead of my negative lookbehinds, it will.  Like I said, this is likely an acceptable sacrifice to make things work in browsers again, as I doubt dollar signs in variable names are used that often.

We can transform the negative lookahead into a negative lookbehind by using negated set: (?<=[^$]). I would simplify the regexp by matching (?<=[^$])\b rather than explicitly expanding the meaning of \b.

I think we should do feature detection of negative lookahead and fall back to \b.

If that's possible in this context, that sounds like the right thing to me!

We apparently haven't fixed this yet, because we're using RegExp literals with negative lookbehind and it fails at the parsing stage. So it seems the only alternative is to use the RegExp constructor with a string...

OK, this should be fixed for real now!

authors: frangio haltman-at marcoscaceres miljantekic

repo: highlightjs/highlightjs-solidity

license: WTFPL


text:
Release process: Docker + Pypi?

Currently, Docker is using the same strategy as higlass-server, and new images are being pushed to docker-hub on successful travis runs. It might make sense to get these releases in sync with the pypi release process described at the end of the README. Maybe they both should be automatic, or they both should be manual? Or not.

Travis is no longer pushing anything to docker-hub... I guess it's manual?, or wrapped in some project that uses this as a dependency? In any event, closing this.

repo: higlass/clodius


text:
1d-heatmap-track-2.html not working

Commit: 89a91e0eca1
Steps to reproduce
http://localhost:8080/1d-heatmap-track-2.html
react-dom.development.js:1542 Uncaught TypeError: _assign is not a function
    at react-dom.development.js:1542
    at validateFormat (react-dom.development.js:15)
    at react-dom.development.js:16
hglib.js:129 Uncaught TypeError: Cannot read property 'render' of undefined
    at launch (hglib.js:129)
    at Object.viewer (hglib.js:182)
    at 1d-heatmap-track-2.html:157

Expected behavior

No error, but beyond that, not sure.
Does this do something different than 1d-heatmap-track.html?

@flekschas : This is another example it looks like you checked in, but here it's more than just missing data. Remove the example, or fix, as you think best? Thanks!

Issue with 3rd party libs.

authors: flekschas mccalluc

repo: higlass/higlass


text:
ERROR:  Could not find a valid gem 'huginn_influxdb_write_data_agent' (>= 0) in any repository ERROR:  Possible alternatives: huginn_sqlite3_agent, huginn_sqlite_agent

I am trying to get it installed in the huginn docker, I logged into the docker and tried the following command, However getting the below error.
`
default@f5cdb452b4f7:~$ gem install huginn_influxdb_write_data_agent
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:29: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:30: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:29: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:30: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
ERROR:  Could not find a valid gem 'huginn_influxdb_write_data_agent' (>= 0) in any repository
ERROR:  Possible alternatives: huginn_sqlite3_agent, huginn_sqlite_agent

`

Hello, for installing this gem , you need to use the .env file like ADDITIONAL_GEMS=huginn_influxdb_write_data_agent(github: hihouhou/huginn_influxdb_write_data_agent , the version  ADDITIONAL_GEMS=huginn_influxdb_write_data_agent should works but I never tested :-) could you try like I did ?

no news , good news -> closed

authors: hihouhou upuldi


text:
Unit test for workflow/forms.py: Formset

Is your feature request related to a problem? Please describe.
Write unit test for the class Formset for the forms in activity section workflow/forms.py
For Django REST Framework views, please use the REST testing framework which extends Django's existing test framework, and improves support for making API requests.
Acceptance Criteria

All tests should run successfully.
The Formset class should have all their lines covered in the coverage report.

Additional Information
All the tests should be located in the tests folder workflow/tests in the file named test_forms.py. If the file does not exist please create one.

Hi @andrewtpham can i work on this?

hey @atoyegbe yes of course feel free to take it up 🙂  please do let us know if you have any questions

hey @atoyegbe actually if you are interested in tests feel free to take up any from this list: https://github.com/hikaya-io/activity/issues?q=is%3Aopen+is%3Aissue+label%3Atests+label%3A"Ready+for+development"
This issue might not be relevant since we are doing some refactoring for the Forms. Please let me know if you have any questions 🙂

Thanks @ninetteadhikari. I will really like to contribute to this project. Can you guide me on how to go about it.

Thanks @ninetteadhikari. I will really like to contribute to this project. Can you guide me on how to go about it.

hey @atoyegbe so great to hear you interested to contribute 🙂  have you already setup the app locally? You can follow the Readme document to setup. Let me know if you face any issues.
Then once you are set up locally you can do some of the issues labelled defect. They might be easy ones to get you started. Then if you want you can try some of the small test tickets.
You can try these ones if you want. They are all frontend tickets. Let me know if you have any preference:
https://github.com/hikaya-io/activity/issues/467
https://github.com/hikaya-io/activity/issues/435
https://github.com/hikaya-io/activity/issues/478

Thanks @ninetteadhikari. I don't have docker installed on my PC. I will get back to you.

authors: atoyegbe ninetteadhikari

repo: hikaya-io/activity


text:
Added login screen(with all the resolved changes)

Related Issue

Fixes #44 .

Checklist

[x] Tested
[x] No Conflicts
[x] Change In Code
[ ] Change In Documentation

@Samdid You should have pulled the latest code before creating the PR. Do the following changes:

@himanshusharma89 All the changes are resolved


text:
🛑 File Share is down

In f07e057, File Share (https://share.hinzwifi.xyz/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: File Share is back up in 40c06a3 after 16 minutes.

repo: hinzwifi/uptime-hinz


text:
Save

This solves a bug when loading a trained model.

watch out: that new strategy does not work for all types of models.
On Wed, Oct 18, 2017 at 7:01 PM, Thibault Clérice notifications@github.com
wrote:

Merged #71 https://github.com/hipster-philology/pandora/pull/71.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hipster-philology/pandora/pull/71#event-1299513459,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AELJL_Z6pPn48aI1kWExU4ppMuuj5Mlvks5sti7hgaJpZM4P-B25
.

Can you describe when it should not work ? Version of keras issue ?

Whenever you have custom layers it tends to break.
On Wed, Oct 18, 2017 at 7:14 PM, Thibault Clérice notifications@github.com
wrote:

Can you describe when it should not work ? Version of keras issue ?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hipster-philology/pandora/pull/71#issuecomment-337662122,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AELJL055OjK7Sqz0DLblpxu0ebYHgpgCks5stjH6gaJpZM4P-B25
.

authors: PonteIneptique mikekestemont

repo: hipster-philology/pandora


text:
Allow 'Element' type for arrows

First off, thanks for the library!
Currently, the arrows prop allows object with keys prev and next which both must be string. However, per the Glider.js documentation, element instances can be passed here as well instead of the selectors. See https://nickpiscitelli.github.io/Glider.js/ -> Settings -> arrows
It'd be great if this library took that into account as well

I messed around with this issue here: https://github.com/yashvesikar/react-glider/commit/fc742b3af6327144cba2568510d8734a9d4e464d does this seem like an acceptable solution to the problem?
Thanks for any input :) I can make a PR if it looks good. @kevinfarrugia

Left a comment on the PR. Awaiting your feedback.

@yashvesikar @kevinfarrugia Can we merge the PR? This issue also has the effect that react-glider is not correctly working when you use it within web components.

@mkampmey do you have a demo using Web Components so that I may include it in the test suite?

:rocket: Issue was released in v3.0.0 :rocket:

authors: hipstersmoothie kdembler kevinfarrugia mkampmey yashvesikar

repo: hipstersmoothie/react-glider


text:
Publish Chainhooks API Docs

Generate and publish the API docs for Chainhooks; OpenAPI spec here.
Ensure the JSON file is up-to-date on every new release of Chainhooks.
Likewise, there's no reference to the hosted Chainhooks in the current document; let's, please capture that detail in the feature guide.

Depends on https://github.com/hirosystems/chainhook/issues/251.

Closing this since we will be wrapping this via DevEx inside Hiro Platform.

repo: hirosystems/docs


text:
Fee estimation not loading on custom regtest

On ALEX a custom regtest/testnet is used. Currently no transactions can be confirmed because the fee is not prefilled/loaded it just halts at the loading screen.
What could be causing this? Should this be resolved by Hiro or is there something at ALEX that can be done?

What version of the wallet are you using?

Thanks for looking into it 🙇
Please close the issue if it's fixed on the lastest version of the wallet

Okay on the second swap I try to make I do get the error again with the 2.22.0 wallet version

The other users on ALEX testnet are also still getting this error with the latest version.

Regtest has been decommissioned. We have an open issue to remove it from the selection list https://github.com/hirosystems/stacks-wallet-web/issues/1763
Are you using regtest or testnet?

Regtest has been decommissioned. We have an open issue to remove it from the selection list #1763
Are you using regtest or testnet?

ALEX uses a custom testnet (it is a lot like the old regtest with fast block times) All the testers add the network manually, like this:

That is why I am not sure if there is a fix ALEX can implement or it is something that can only be fixed in the web wallet itself.

Could this be the underlying problem on the API-side? https://github.com/hirosystems/stacks-blockchain-api/issues/865

We've upgraded our mocknet to stacks-blockchain-api v0.71.2 (master:01cd4a1), which supports the APIs called by the latest Hiro wallet to estimate the cost.
So this can close. Thank you.

authors: 314159265359879 andresgalante fiftyeightandeight markmhx

repo: hirosystems/stacks-wallet-web


text:
v2/fees/transaction  -  "SyntaxError: Unexpected end of JSON input"

Trying to deploy contract via Hiro wallet but returns with 400 when fetching fee estimate.   However, the resulting JSON seems incorrect.
Supposed to get a 'reason', according to  https://github.com/stacks-network/stacks-blockchain/pull/2872

Thank you!

Closing for now.  Issue might have been resolved.

See issue https://github.com/hirosystems/stacks-wallet-web/issues/2181

I am getting a 400 as well


text:
关于我 — 孙中明

https://szm2019.cn/2021/01/01/about-me/
更多

hello

repo: hiszm/blog-comments


text:
Change contributing section in README.md?

Hi the instructions in README.md seems a bit too complex.
It should be :
poetry install
poetry run pytest .

These are what i did to test locally

Just make sure to install poetry

@baseplate-admin Alright. I'll have a look into this.

Update: Fixed with the https://github.com/hitblast/avro.py/commit/233edfdc60374d62c5ba97498f92a4a5f9319747 commit.

pip install -U pip setuptools

Is this required?
Also poetry should not be installed with pip, but pipx.
The reason is it gives isolated environment.

@baseplate-admin I was planning to recreate a pipx environment on my machine but since avro.py doesn't really rely on dependencies outside of pip, I had kept poetry installation inside pip as-is.
Will reconsider it.

poetry is a development dependency, it is not a single dependency.
Consider it like this.
Poetry python er motoi machine e installed thake, eita vscode er moto consider kora jete pare :)

@baseplate-admin Bujhechi beparta, don't worry. ;)

@baseplate-admin Apparently not using the --all-extras flag removes the CLI dependencies as well, so I guess I'll keep it for the developer notes.

authors: baseplate-admin hitblast


text:
Encoding problem during pip install

System:

Windows 10
Python 3.7

I run in to the following problem when running pip install dwdweather2:
PS D:\workspaces\robotframework-dwdweather> pip install dwdweather2
Collecting dwdweather2
  Using cached https://files.pythonhosted.org/packages/b9/0c/fb48f9e43f263a493f0a5e13d00bbe6ca0a31d11958b444836d218951a25/dwdweather2-0.8.0.tar.gz
    ERROR: Complete output from command python setup.py egg_info:
    ERROR: Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Users\Daidalos\AppData\Local\Temp\pip-install-pa4hwo8d\dwdweather2\setup.py", line 6, in <module>
        README = open(os.path.join(here, 'README.rst')).read()
      File "d:\programs\python\python37\lib\encodings\cp1252.py", line 23, in decode
        return codecs.charmap_decode(input,self.errors,decoding_table)[0]
    UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 2062: character maps to <undefined>
    ----------------------------------------
ERROR: Command "python setup.py egg_info" failed with error code 1 in C:\Users\Daidalos\AppData\Local\Temp\pip-install-pa4hwo8d\dwdweather2\

Installation works with dwdweather (is this project related to you) but not with dwdweather2.
Installing dwdweather:
PS D:\workspaces\robotframework-dwdweather> pip install dwdweather
Collecting dwdweather
  Downloading https://files.pythonhosted.org/packages/ee/4f/4bd3ceff7b6158133d6e7cbfd68f27e4d72fd2f80c83d032944e16bbbb2f/dwdweather-0.7.tar.gz
Installing collected packages: dwdweather
  Running setup.py install for dwdweather ... done
Successfully installed dwdweather-0.7

Dear @Noordsestern,
thanks for writing in.

UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 2062: character maps to <undefined>

Ah, the usual suspects if README.rst is not totally ASCII-clean.
Thanks already for providing a fix through #6, we just released version 0.8.2 which should mitigate this issue.
With kind regards,
Andreas.

Any plans migrating to python3?

Dear @Noordsestern,
thanks for asking. We would love to get Python3 support for this program and moved the discussion over to #7.
With kind regards,
Andreas.

authors: Noordsestern amotl


text:
Shrink ILocation interface

Remove:

[x] - getNPCs
[x] - getItems

Duplicate of #97

repo: hjaremko/io-rpg


text:
🛑 Reime ohne Sinn und Verstand is down

In e0ec60b, Reime ohne Sinn und Verstand (https://www.reimeohnesinnundverstand.de) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Reime ohne Sinn und Verstand is back up in 71ad3c6 after 6 minutes.

repo: hjstrauss/MonitorMySites


text:
🛑 LM Bogen WSV is down

In 6cc708a, LM Bogen WSV (https://www.lmbogenwsv.de) was down:

HTTP code: 0
Response time: 0 ms

Resolved: LM Bogen WSV is back up in 961ffa5 after 22 minutes.


text:
🛑 Opa Hansi is down

In 612be7c, Opa Hansi (https://www.opahansi.de) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Opa Hansi is back up in 6feb7ae after 23 minutes.


text:
🛑 Opa Hansi is down

In 1ca4658, Opa Hansi (https://www.opahansi.de) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Opa Hansi is back up in bf42fa9 after 15 minutes.


text:
🛑 HJStrauss is down

In 4a5cde7, HJStrauss (https://www.hjstrauss.de) was down:

HTTP code: 0
Response time: 0 ms

Resolved: HJStrauss is back up in 3fcb9a3 after 21 minutes.


text:
device not reachable/rejected

Description
I am suddenly having this error with basically all node types:

At first I thought one of my speakers had gone bad, so I tried removing it from the configuration but the issue persists. It seems to be a new issue between the module and the speakers.
I've tried:

Installing Sonos speaker updates
Reverting to 6.7 of this module
Factory resetting speakers

I don't really know that the problem originates in a code change here given reversion doesn't fix it. Perhaps what I'm doing is unique and others aren't seeing this.
What node/command (topic)/state (payload)
node:
command:
state:
In case of a bug: Are you able to reproduce the error

Versions and Infrastructure
what system: podman on Fedora box, Home Assistant
node-red-contrib-sonos-plus version: 6.7.3, 6.7.8, 6.8.0
Node-RED version: 3.1.3 and 3.1.9
NodeJS version: using Docker container for node-red
"dependencies": {
        "node-red-contrib-home-assistant-websocket": "~0.63.1",
        "node-red-contrib-homekit-bridged": "~1.6.0",
        "node-red-contrib-log-elk": "~1.2.8",
        "node-red-contrib-pythonshell": "~1.5.4",
        "node-red-contrib-sonos-plus": "^6.7.3",
        "node-red-contrib-state": "~1.6.1",
        "node-red-contrib-sunevents": "~3.1.1",
        "node-red-contrib-tts-ultimate": "~2.0.5"
    }

see: [https://flows.nodered.org/flow/a5c42641bf33dd0da9bfd4426a06950a]

Hi.
That sounds like a network problem. Do you use static ip address or dns
names? Please check the ip address of your speakers.
On Sat, Apr 13, 2024 at 8:38 PM Nick Borgers @.***>
wrote:

Description
I am suddenly having this error with basically all node types:
image.png (view on web)
https://github.com/hklages/node-red-contrib-sonos-plus/assets/73143201/311f53d6-a331-4b1d-95f0-ea14b032b358
At first I thought one of my speakers had gone bad, so I tried removing it
from the configuration but the issue persists. It seems to be a new issue
between the module and the speakers.
I've tried:

Installing Sonos speaker updates
Reverting to 6.7 of this module
Factory resetting speakers

I don't really know that the problem originates in a code change here
given reversion doesn't fix it. Perhaps what I'm doing is unique and others
aren't seeing this.
What node/command (topic)/state (payload)
node:
command:
state:
In case of a bug: Are you able to reproduce the error Versions and
Infrastructure
what system: podman on Fedora box, Home Assistant
node-red-contrib-sonos-plus version: 6.7.3, 6.7.8, 6.8.0
Node-RED version: 3.1.3 and 3.1.9
NodeJS version: using Docker container for node-red
"dependencies": {
"node-red-contrib-home-assistant-websocket": "~0.63.1",
"node-red-contrib-homekit-bridged": "~1.6.0",
"node-red-contrib-log-elk": "~1.2.8",
"node-red-contrib-pythonshell": "~1.5.4",
"node-red-contrib-sonos-plus": "^6.7.3",
"node-red-contrib-state": "~1.6.1",
"node-red-contrib-sunevents": "~3.1.1",
"node-red-contrib-tts-ultimate": "~2.0.5"
}
see: [https://flows.nodered.org/flow/a5c42641bf33dd0da9bfd4426a06950a]
—
Reply to this email directly, view it on GitHub
https://github.com/hklages/node-red-contrib-sonos-plus/issues/292, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AEDZCHZJ7VIPNFZLK4ZSPO3Y5F3TNAVCNFSM6AAAAABGFVGWQ2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGI2DCNRZGE3TONQ
.
You are receiving this because you were assigned.Message ID:
@.***>

Had been using dns names, have tried switching to ip addresess
Just got NodeRed running on a different host (laptop) and have the same problem behavior, so not a network problem between the server I'm running NodeRed on and the speaker.
Am going to try moving the laptop closer to the Sonos speakers from a network perspective.

I can consistently reach them directly via the diagnostics HTTP interface

Though we have been seeing unable to connect to Sonos errors in the app sometimes...

OK - thats a good sign.
Do you have a lot of nodes? 100 or more?
You can check one node and activate "Do not check avaialabily of sonos
player" and try that
On Sat, Apr 13, 2024 at 9:11 PM Nick Borgers @.***>
wrote:

I can consistently reach them directly via the diagnostics HTTP interface
image.png (view on web)
https://github.com/hklages/node-red-contrib-sonos-plus/assets/73143201/60ab78be-3459-4b3c-9244-ab8d5afc570b
Though we have been seeing unable to connect to Sonos errors in the app
sometimes...
—
Reply to this email directly, view it on GitHub
https://github.com/hklages/node-red-contrib-sonos-plus/issues/292#issuecomment-2053734998,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEDZCH654IUTO3AUZJNVTKDY5F7OFAVCNFSM6AAAAABGFVGWQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJTG4ZTIOJZHA
.
You are receiving this because you were assigned.Message ID:
@.***>

Looking at your github pictures all sonos nodes have an issue - there it says "could not resolve dns names".
Are the players reachable in Home Assistant? as media player?

The images generated for GitHub are in an ephemeral container in a GitHub Action; they're not captured from my running instance.
My problem is at a Sonos level, I rarely use the iOS app b/c everything is managed via NodeRed but now I've been poking around and Spotify isn't working reliably.
It's silly, but I think the "what changed" is that a neighbor moved into the apartment next door and we're now just over the edge on RF interference for the SonosNet to function.
Will look at "Do not check availability of sonosplayer"; definitely a good thing to disable with how many Sonos nodes I have.

Wow, "Do not check availability of sonosplayer" has made some difference. I'm not seeing the same connection errors anymore.
Also I think Sonos is having a Spotify connectivity problem at the moment, other music services ARE working in the app.

OK, I'm chalking this up to general system network instability.
Disabling "Do NOT check availability of sonosplayer" did make a difference though; the system is working much better after that change. I think the burst of checks was contributing the problem originally, and I'm not seeing the specific error I initially was seeing and reported anymore. However, my system still isn't working properly and I think it has nothing to do with this code.
Thanks for responding, and quickly. You did help me get to a much better limping state. I move in a month anyway so I'll just live with degraded functionality of my Sonos system until then. With the config tweak to not check speaker state on deployment this codebase seems to be working properly and not causing or contributing to any problem.

... you can even more optimize by just using Node-RED link nodes and sending messages with topic/payload to a few universal node - maybe even to only one single universal node.
Thanks for your feedback.

Added #293 to discussions

authors: NickBorgersOnLowSecurityNode hklages

repo: hklages/node-red-contrib-sonos-plus


text:
Automate tw

We have to remove Tw as a free parameter and adjust the whole method to the fact, that L is not a meaningful absolute measure, but is well suited for being a relative measure in between reconstruction-cycles.

The biggest change is, that we have to compute L’s for many different Tw’s until this gap I was talking about shrinks. Codewise it means that in local_l_statistics I am not calling uzal_cost anymore Of course I could simply loop over all Tw’s and call uzal_cost with this changing Tw every single time. But uzal_cost Is averaging over T = 1:Tw anyway! So my idea in uzal_cost_pecuzal was to compute L for each Tw step by step for the actual embedding (L1) AND the candidate embedding (L2) and compute L2 - L1 in each step. Whenever this distance increases, the loop breaks (assumed that this distance is negative). This is all done in the function uzal_cost_pecuzal. Of course this slows down the whole thing. I encountered slowing factors of up to 6 so far, which is bad and maybe you can help me to improve this.
I tried with parametrizing all the auxiliary functions, but this had no effect at all.
The bottleneck is clearly the re-computation of all nearest neighbors in every itearation of T = 2:Tw in the main function uzal_cost_pecuzal. First I thought it would be sufficient to compute this only once at the beginning and use the same information about the nearest neighbors in each iteration of T, but it turned out that this will bias the results heavily. The problem is, that vtree is taking the trajectory Y[1:end-Tw]. If we would only perform the tree search once at the beginning than this is based on Y[1:end-Tw], but it should be based on Y[1:end-T], T = 2:Tw. Meaning, when I set the maximum Tw, which coincides with the maximum encountered delay values (this is a free parameter), to be large, say, Tw=200 then the results will change compared to the case where, say, Tw=100, even though the statistic the algorithm works on will only be based on, say, T = 4. So despite the fact that it will never actually get to Tw=100 or even Tw=200, it will give different results dependent on what Tw you set in the first place. That is why vtree needs to be computed all over again. That is the problem and maybe - hopefully - you have a solution for this? I know, that for large datasets that will literally have no effect, but even on intermediate sizes it has!

Hi @hkraemer I see that this is already merged. Is there something you'd still like me to do, in general for here or for the paper? If so please let me know.

Hi @hkraemer I see that this is already merged. Is there something you'd still like me to do, in general for here or for the paper? If so please let me know.

authors: Datseris hkraemer