text:
Postfixadmin can't reach MariaDB

Classification

[X] Question

Reproducibility

[x] Always

Docker information
$ docker info
Containers: 23
 Running: 23
 Paused: 0
 Stopped: 0
Images: 23
Server Version: 18.06.1-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 468a545b9edcd5932818eb9de8e72413e616e86e
runc version: 69663f0bd4b60df09991c08812a60108003fa340
init version: fec3683
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.15.0-34-generic
Operating System: Ubuntu 18.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 31.28GiB
Name: services
ID: ZAET:O7R4:XJB5:6YCM:D4KF:MMZR:NM7D:LY43:WAGK:4XIR:X64U:AZ5K
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Portainer network view

$ docker inspect network utilities_network
},
        "ConfigOnly": false,
        "Containers": {

             ...

            "2b01fa919d62accf9250340434404bede9da5cbd0cff600142487be4450e2507": {
                "Name": "mailserver",
                "EndpointID": "bdf25bd3f984779ac80a4952ab109c924ae0fada45e359d8e53c6cd829cc46be",
                "MacAddress": "02:42:ac:13:00:04",
                "IPv4Address": "172.19.0.4/16",
                "IPv6Address": ""
            },
            "85d36fca66abf861ee040c5c5d50ba6b0ee82ed128ef0dc3664b094b77d865e5": {
                "Name": "postfixadmin",
                "EndpointID": "4ea61b9a3eb58e3653d25b339475f8f2ebbb40c4e1a3c69015a566201ea6fcec",
                "MacAddress": "02:42:ac:13:00:07",
                "IPv4Address": "172.19.0.7/16",
                "IPv6Address": ""
            },
            "9dab119cd897b71caf1944e6fb6a536ac6ad33c5ac9ec800e683644c377b81fb": {
                "Name": "rainloop",
                "EndpointID": "f4b59d9ffcb54532996e92f180f428c77481956ac5129f4f009a6bc698e97388",
                "MacAddress": "02:42:ac:13:00:06",
                "IPv4Address": "172.19.0.6/16",
                "IPv6Address": ""
            },
            "b730ff5eee3c3b4f1d0d41f7a44c4dc50388357a9587085c151f8738475551db": {
                "Name": "traefik",
                "EndpointID": "73825e788dc3bc8d782a8e016f3acff513417e540ce9edb0483c96077432b5bf",
                "MacAddress": "02:42:ac:13:00:02",
                "IPv4Address": "172.19.0.2/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {}
    }

$ docker inspect network utilities_mail_network
},
        "ConfigOnly": false,
        "Containers": {
            "2b01fa919d62accf9250340434404bede9da5cbd0cff600142487be4450e2507": {
                "Name": "mailserver",
                "EndpointID": "2aa2a27b286575391902c82552f7726d0338c64a7e963190220f551e79cb2b56",
                "MacAddress": "02:42:ac:17:00:04",
                "IPv4Address": "172.23.0.4/16",
                "IPv6Address": ""
            },
            "85d36fca66abf861ee040c5c5d50ba6b0ee82ed128ef0dc3664b094b77d865e5": {
                "Name": "postfixadmin",
                "EndpointID": "3964b18db8794bcd640ede1e3ba4b9f2b8ac0fd2d5550c9979d6edba84354390",
                "MacAddress": "02:42:ac:17:00:05",
                "IPv4Address": "172.23.0.5/16",
                "IPv6Address": ""
            },
            "9668f8bf887cdcf10fe51e441553c2d5f84f9fbd27a27a2f24e0bc13b2f43184": {
                "Name": "mail_mariadb",
                "EndpointID": "cbe5785282e283d732be88dd997f5d18f26fa9a2b5f9de27bf25573d2a85162e",
                "MacAddress": "02:42:ac:17:00:02",
                "IPv4Address": "172.23.0.2/16",
                "IPv6Address": ""
            },
            "9dab119cd897b71caf1944e6fb6a536ac6ad33c5ac9ec800e683644c377b81fb": {
                "Name": "rainloop",
                "EndpointID": "1c10738315434f0055b250007eda62fc8d30b7c9846cba9cdc436a9c5063fd13",
                "MacAddress": "02:42:ac:17:00:06",
                "IPv4Address": "172.23.0.6/16",
                "IPv6Address": ""
            },
            "f3a7d2999dc597e178ba6855abad0fc159d303303cf0c5ec7b3f9181535af177": {
                "Name": "mail_redis",
                "EndpointID": "7f1925ba3e0abfba045d0082ae932872646ba5c240b3853d2fc916681d5b065b",
                "MacAddress": "02:42:ac:17:00:03",
                "IPv4Address": "172.23.0.3/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {}
    }

The network db_network serves me to access my different databases via adminer.
Description
I am currently experiencing a problem with the configuration of Postfix and Mariadb.
Even after modifying the config.inc.php file postfix seems not be able to reach db.

docker-compose.yml mariadb conf
      - MYSQL_DATABASE=postfix
      - MYSQL_USER=postfix
      - MYSQL_PASSWORD="password"

config.inc.php
$CONF['database_type'] = 'mysqli';
$CONF['database_host'] = '172.23.0.2';
$CONF['database_user'] = 'postfix';
$CONF['database_password'] = 'password';
$CONF['database_name'] = 'postfix';

Debugging information

Postfix Web server seems not have any trouble

Configuration (docker-compose.yml, traefik.toml...etc)
docker-compose.yml
...
mailserver:
    image: hardware/mailserver:1.1-stable
    container_name: mailserver
    restart: always
    depends_on:
      - mail_mariadb
      - mail_redis
    extra_hosts:
      - "mariadb:172.23.0.2"
      - "redis:172.23.0.3"
    domainname: ${SERVER_DOMAIN}
    hostname: mail
    networks:
      - utilities_network
      - mail_network
    ports:
      - "25:25"       # SMTP                - Required
      - "143:143"     # IMAP       STARTTLS - Optional - For webmails/desktop clients
      - "587:587"    # Submission STARTTLS - Optional - For webmails/desktop clients
      - "993:993"     # IMAPS      SSL/TLS  - Optional - For webmails/desktop clients
      - "4190:4190"   # SIEVE      STARTTLS - Optional - Recommended for mail filtering
    volumes:
      - /srv/appdata/utilities/mail:/var/mail
    environment:
      - PUID=${USERID}
      - PGID=${GROUPID}
      - TZ=${TIMEZONE}
      - DBPASS=${MAIL_DB_PASSWORD}
      - RSPAMD_PASSWORD=${MAIL_MONITORING_PASSWORD}
    labels:
      - traefik.enable=true
      - traefik.frontend.rule=Host:monitoring.mail.${SERVER_DOMAIN}
      - traefik.port=11334
      - traefik.docker.network=utilities_network
      - traefik.backend=Mail

  postfixadmin:
    image: hardware/postfixadmin
    container_name: postfixadmin
    restart: always
    depends_on:
      - mailserver
      - mail_mariadb
    networks:
      - utilities_network
      - mail_network
    domainname: ${SERVER_DOMAIN}
    hostname: mail
    environment:
      - PUID=${USERID}
      - PGID=${GROUPID}
      - TZ=${TIMEZONE}
      - DBPASS="password"
    labels:
      - traefik.enable=true
      - traefik.frontend.rule=Host:dashboard.mail.${SERVER_DOMAIN}
      - traefik.port=8888
      - traefik.docker.network=utilities_network
      - traefik.backend=Postfixadmin

  rainloop:
    image: hardware/rainloop
    container_name: rainloop
    restart: always
    depends_on:
      - mailserver
      - mail_mariadb
    networks:
      - utilities_network
      - mail_network
    environment:
      - PUID=${USERID}
      - PGID=${GROUPID}
      - TZ=${TIMEZONE}
    volumes:
      - /srv/appdata/utilities/mail/rainloop:/rainloop/data
    labels:
      - traefik.enable=true
      - traefik.port=8888
      - traefik.frontend.rule=Host:web.mail.${SERVER_DOMAIN}
      - traefik.docker.network=utilities_network
      - traefik.backend=Rainloop

  mail_mariadb:
    image: mariadb:10.2
    container_name: mail_mariadb
    restart: always
    networks:
      - mail_network
    environment:
      - MYSQL_RANDOM_ROOT_PASSWORD=yes
      - PUID=${USERID}
      - PGID=${GROUPID}
      - TZ=${TIMEZONE}
      - MYSQL_DATABASE=postfix
      - MYSQL_USER=postfix
      - MYSQL_PASSWORD="password"
    volumes:
      - /srv/appdata/utilities/mail/mysql/db:/var/lib/mysql
    labels:
      - traefik.enable=false

  mail_redis:
    image: redis:4.0-alpine
    container_name: mail_redis
    restart: always
    command: redis-server --appendonly yes
    networks:
      - mail_network
    environment:
      - PUID=${USERID}
      - PGID=${GROUPID}
      - TZ=${TIMEZONE}
    volumes:
      - /srv/appdata/utilities/mail/redis/db:/data
    labels:
      - traefik.enable=false

...

networks:
  mail_network:
    external: false
  utilities_network:
    external:
      name: utilities_network
  db_network:
    external:
      name: db_network

Sorry for my bad english you can reply in french if you want.
thank you in advance.

Try to set DBHOST in postfixadmin as mail_mariadb
  postfixadmin:
    image: hardware/postfixadmin
    container_name: postfixadmin
    restart: always
    depends_on:
      - mailserver
      - mail_mariadb
    networks:
      - utilities_network
      - mail_network
    domainname: ${SERVER_DOMAIN}
    hostname: mail
    environment:
      - PUID=${USERID}
      - PGID=${GROUPID}
      - TZ=${TIMEZONE}
      - DBPASS="password"
      - DBHOST=mail_mariadb
    labels:
      - traefik.enable=true
      - traefik.frontend.rule=Host:dashboard.mail.${SERVER_DOMAIN}
      - traefik.port=8888
      - traefik.docker.network=utilities_network
      - traefik.backend=Postfixadmin

Ok ty, you were right the link between postfix and db is now established.
Now the message had change:

I had already deal with this error but i don't remember how i fix it ..

I've found this ticket, but don't understand what was the problem.
https://github.com/hardware/postfixadmin/issues/15

You should also sync the configs on the mail_mariadb service with the postfixadmin
  mail_mariadb:
    # ...
    environment:
      - MYSQL_RANDOM_ROOT_PASSWORD=yes
      - PUID=${USERID}
      - PGID=${GROUPID}
      - TZ=${TIMEZONE}
      - MYSQL_DATABASE=postfix
      - MYSQL_USER=postfix
      - MYSQL_PASSWORD=password

  postfixadmin:
    # ...
    environment:
      - PUID=${USERID}
      - PGID=${GROUPID}
      - TZ=${TIMEZONE}
      - DBPASS="password"

The default database and user are called postfix, have you changed it? If so, you may need to set DBUSER and DBNAME on postfixadmin service.
Another problem could be that quotation marks that you are using on the password, may I suggest a simpler password for tests? (without the quotes or special characters) as it may being bad interpreted by the docker (you may need to escape some character).

All information describe in docker-compose are right for mail_mariadb i can connect to mysql with user

postfix

and pass

password

and i found the postfix db

When i reach mariadb from postfixadmin

Try to get the content of the /postfixadmin/config.local.php
docker exec postfixadmin cat /postfixadmin/config.local.php

It may help, maybe something is being set wrong there...
Take a closer look at the $CONF['database_...'] variables.

You were right thank you very much.
I add DBUSER and DBNAME variables to docker-compose.yml and it's work fine here it's my sample
postfixadmin:
    image: hardware/postfixadmin
    container_name: postfixadmin
    restart: always
    depends_on:
      - mailserver
      - mail_mariadb
    networks:
      - utilities_network
      - mail_network
    domainname: ${SERVER_DOMAIN}
    hostname: mail
    environment:
      - PUID=${USERID}
      - PGID=${GROUPID}
      - TZ=${TIMEZONE}
      - DBPASS=password
      - DBHOST=mail_mariadb
      - DBUSER=postfix
      - DBNAME=postfix
    labels:
      - traefik.enable=true
      - traefik.frontend.rule=Host:dashboard.mail.${SERVER_DOMAIN}
      - traefik.port=8888
      - traefik.docker.network=utilities_network
      - traefik.backend=Postfixadmin

 ...

 mail_mariadb:
    image: mariadb:10.2
    container_name: mail_mariadb
    restart: always
    networks:
      - mail_network
    environment:
      - MYSQL_RANDOM_ROOT_PASSWORD=yes
      - PUID=${USERID}
      - PGID=${GROUPID}
      - TZ=${TIMEZONE}
      - MYSQL_DATABASE=postfix
      - MYSQL_USER=postfix
      - MYSQL_PASSWORD=password
    volumes:
      - /srv/appdata/utilities/mail/mysql/db:/var/lib/mysql
    labels:
      - traefik.enable=false

Ty again for your time.

I don't either need to manually change config.inc.php file anymore.

You shouldn't do that, it will only bring your problems.
I think you are new using docker right? I'm no expert either, but you may take a read about how the data are persisted on it.
You will see that the files inside the container are lost each time the container is (re)created.
If you want to persist some kind of data you will need a bind mount ou a volume mount.
[]'s

Yes I discover docker by the installation of my server.
I understand, especially with the use of docker-compose that it is not good to modify files manually after mounting the container.
I will read more about it thanks.

authors: elielam navossoc

repo: hardware/mailserver


text:
Disable generated by message

Describe the bug
The generated sitemap includes a message "generated by nuxt-simple-sitemap.xml" with no clear way to remove this.

This problem has been raised before (https://github.com/harlan-zw/nuxt-simple-sitemap/issues/64), but the solution only fixes a styled xsl sitemap. Plain XML sitemaps still include a "generated by" comment.
This could be an "opt out" configuration flag, that is documented with a message encouraging those who wish to turn it off to check out the Sponsor this repo promo page
Reproduction
No response
System / Nuxt Info
No response

I think adding a config to disable this is a reasonable suggestion.
At a minimum, you should be able to remove this using the hooks, but I don't think that's possible either.

You now can provide the credits: false option to disable this in v3.

source: gharchive/issue

authors: harlan-zw mrspence

repo: harlan-zw/nuxt-simple-sitemap

license: MIT

license_type: permissive

license_source: github-api


text:
Standardized X matrix, switched to pytest, added tests, and added docs

First big change was standardizing the X matrix. The most important piece of the epistasis models are the X matrix. There were horrible inconsistencies with the X matrix across the models in the epistasis package. I've now simplified this logic and documented it.
Second big change was switching the testing framework to pytest. I think Pytest provides an easier-to-read testing output. I'd like to settle on this framework.
Finally, added some test and documentation for the changes.

Not finished with the PR just yet.

Okay, finally happy with this PR. Lacking on documentation, but many tests have been added. Merging.

source: gharchive/pull-request

repo: harmslab/epistasis

license: unlicense

license_source: bigquery


text:
CCM Release Notes

Updated CCM release notes with some fixed issues.
The local build is successful.

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

authors: bot-gitexp-user charanya-j

repo: harness/developer-hub


text:
add release notes

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

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

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

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

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

authors: bot-gitexp-user naman-goenka


text:
Fix user tests in cg

Describe your changes
Comment Triggers

PR Check triggers

Build: trigger build
Sub Category Field Check: trigger subcategoryfieldcheck

trigger build

repo: harness/terraform-provider-harness


text:
DTO docs

The program makes use of DTO objects for parsed programs, predicates and WP context objects, but generally lacks documentation on those.

Closed by PR #16

repo: harry-tallbelt/verifiable-tests

license: mit


text:
Rename all images and add alt tags

The images are not properly named.
To do:  Rename the images properly in snake case for example web_development_icon

can you please assign this to me?

Can I please work on this issue?

hey cool, im also working on this

Hey @UshasriMavuri1999 , assigning the task to you! 🚀

hlo sir, i would like to do this :>
it will be really kind of u if u can let me do this too :)

@harshgoel05 checkout my PR and tell me if you still need any changes

Hey! @ShobhitRathi it looks great but it was already assigned to @UshasriMavuri1999, will check her PR and if that's not great. Will merge yours.

@harshgoel05 cool you can merge it anytime you want

Closing this #14 #19


text:
scammers

bro power on the server and stop do stuff like this shiiit

bro power on the server and stop do stuff like this shiiit

Calm down. It's just a bridge

repo: harshitethic/whatsapp-turbo-gpt


text:
module 'model/convNN.lua' not found:No LuaRocks module found for model/convNN.lua

rzai@rzai00:~/prj/sent-conv-torch$ CUDA_VISIBLE_DEVICES=1 th main.lua -data MR.hdf5 -cudnn 0
loading data...
data loaded!
vocab size: 	18766
vec size: 	300
==> fold 	1
epoch:	1	train perf:	70.476744186047	%, val perf 	81.062124248497	%
epoch:	2	train perf:	81.337209302326	%, val perf 	82.765531062124	%
epoch:	3	train perf:	87.093023255814	%, val perf 	81.763527054108	%
epoch:	4	train perf:	91.337209302326	%, val perf 	82.765531062124	%
epoch:	5	train perf:	94.709302325581	%, val perf 	82.364729458918	%
epoch:	6	train perf:	96.546511627907	%, val perf 	82.865731462926	%
epoch:	7	train perf:	98.186046511628	%, val perf 	82.865731462926	%
epoch:	8	train perf:	98.872093023256	%, val perf 	82.965931863727	%
epoch:	9	train perf:	99.267441860465	%, val perf 	83.567134268537	%
epoch:	10	train perf:	99.558139534884	%, val perf 	83.867735470942	%
epoch:	11	train perf:	99.779069767442	%, val perf 	84.168336673347	%
epoch:	12	train perf:	99.755813953488	%, val perf 	84.268537074148	%
epoch:	13	train perf:	99.779069767442	%, val perf 	84.168336673347	%
epoch:	14	train perf:	99.872093023256	%, val perf 	84.068136272545	%
epoch:	15	train perf:	99.883720930233	%, val perf 	84.068136272545	%
epoch:	16	train perf:	99.883720930233	%, val perf 	83.967935871743	%
epoch:	17	train perf:	99.953488372093	%, val perf 	84.268537074148	%
epoch:	18	train perf:	99.953488372093	%, val perf 	84.268537074148	%
epoch:	19	train perf:	99.93023255814	%, val perf 	84.468937875752	%
epoch:	20	train perf:	99.96511627907	%, val perf 	83.967935871743	%
epoch:	21	train perf:	99.941860465116	%, val perf 	84.168336673347	%
epoch:	22	train perf:	99.96511627907	%, val perf 	84.36873747495	%
epoch:	23	train perf:	99.96511627907	%, val perf 	84.468937875752	%
epoch:	24	train perf:	99.96511627907	%, val perf 	84.068136272545	%
epoch:	25	train perf:	99.976744186047	%, val perf 	84.468937875752	%
best dev err:	84.468937875752	%, epoch 	19
test perf 	81.707317073171	%
saving checkpoint to 	results/20161106_2343_model_1.t7
==> fold 	2
/home/rzai/torch/install/bin/luajit: /home/rzai/torch/install/share/lua/5.1/trepl/init.lua:384: module 'model/convNN.lua' not found:No LuaRocks module found for model/convNN.lua
no field package.preload['model/convNN.lua']
no file '/home/rzai/.luarocks/share/lua/5.1/model/convNN/lua.lua'
no file '/home/rzai/.luarocks/share/lua/5.1/model/convNN/lua/init.lua'
no file '/home/rzai/torch/install/share/lua/5.1/model/convNN/lua.lua'
no file '/home/rzai/torch/install/share/lua/5.1/model/convNN/lua/init.lua'
no file './model/convNN/lua.lua'
no file '/home/rzai/torch/install/share/luajit-2.1.0-beta1/model/convNN/lua.lua'
no file '/usr/local/share/lua/5.1/model/convNN/lua.lua'
no file '/usr/local/share/lua/5.1/model/convNN/lua/init.lua'
no file '/home/rzai/.luarocks/lib/lua/5.1/model/convNN/lua.so'
no file '/home/rzai/torch/install/lib/lua/5.1/model/convNN/lua.so'
no file '/home/rzai/torch/install/lib/model/convNN/lua.so'
no file './model/convNN/lua.so'
no file '/usr/local/lib/lua/5.1/model/convNN/lua.so'
no file '/usr/local/lib/lua/5.1/loadall.so'
no file '/home/rzai/.luarocks/lib/lua/5.1/model/convNN.so'
no file '/home/rzai/torch/install/lib/lua/5.1/model/convNN.so'
no file '/home/rzai/torch/install/lib/model/convNN.so'
no file './model/convNN.so'
no file '/usr/local/lib/lua/5.1/model/convNN.so'
no file '/usr/local/lib/lua/5.1/loadall.so'
stack traceback:
[C]: in function 'error'
/home/rzai/torch/install/share/lua/5.1/trepl/init.lua:384: in function 'require'
main.lua:80: in function 'build_model'
main.lua:178: in function 'train_loop'
main.lua:341: in function 'main'
main.lua:354: in main chunk
[C]: in function 'dofile'
...rzai/torch/install/lib/luarocks/rocks/trepl/scm-1/bin/th:145: in main chunk
[C]: at 0x00406670
rzai@rzai00:~/prj/sent-conv-torch$
rzai@rzai00:~/prj/sent-conv-torch$ ll model/
total 24
drwxrwxr-x 2 rzai rzai 4096 10月 25 20:36 ./
drwxrwxr-x 6 rzai rzai 4096 11月  6 18:43 ../
-rw-rw-r-- 1 rzai rzai 4345 10月 25 20:36 convNN.lua
-rw-rw-r-- 1 rzai rzai 1392 10月 25 20:36 highway_conv.lua
-rw-rw-r-- 1 rzai rzai  957 10月 25 20:36 highway_mlp.lua
rzai@rzai00:~/prj/sent-conv-torch$

Thanks, I have fixed the bug.

authors: jeffreyling loveJasmine

repo: harvardnlp/sent-conv-torch


text:
[BUG] Crash on Namespace edit page

Describe the bug

To Reproduce
Steps to reproduce the behavior:

Go to projects/namespaces page
Go to namespace detail page

Expected behavior

the page runs well

Support bundle

Environment:

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

Additional context
Add any other context about the problem here.

Validated in master-661ee801-head.

repo: harvester/harvester


text:
[Doc] Describe the upgrade path of Harvester multi-cluster-management

Is your doc request related to a problem? Please describe or add related issue ID.
Need to describe the upgrade path of Harvester multi-cluster-management(When Rancher is deployed separately from the Harvester cluster)
Describe the solution you'd like

Close as the doc PR is merged and the Rancher multi-cluster upgrade reference is available on https://docs.harvesterhci.io/dev/upgrade/automatic#rancher-upgrade.


text:
[ENHANCEMENT] Drop tho potential manual patch of Rancher shell image v0.1.26 on Harvester v1.3.2

Is your enhancement related to a problem? Please describe.

Harvester v1.4.0 will use Rancher v2.9 version, and the later uses a new shell image defaultShellVersion: rancher/shell:v0.2.1
https://github.com/rancher/rancher/blob/3f7c25803c00e5311d89d1144b3c6684b288ed51/pkg/settings/setting.go#L128C78-L128C97
https://github.com/rancher/rancher/blob/a9946d267616beb1be27c3142a4ebaf6186ba3e7/build.yaml#L4
From issue https://github.com/harvester/harvester/issues/6352, the shell-image was patched to v0.1.26 on Harvester v1.3.2 upgrade path, that may affect the further upgrade to v1.4.0.
Describe the solution you'd like

Drop to manual patch on v1.4.0 upgrade path
Describe alternatives you've considered

Additional context

Previous upgrade PR: https://github.com/harvester/harvester/pull/6347

Test plan:
(1) Upgrade to v1.3.2, check below CRD object, notice the VALUE column has value like v0.1.26
(2) Further upgrade to v1.4.0, the VALUE column is empty
v132->v140 upgrade, Rancher should upgrade smoothly, and the value of below CRD object should be empty after upgrade

setting.management.cattle.io/shell-image
NAME          VALUE
shell-image

Verified this enhancement has been applied.
Test Information

Environment: qemu/KVM 1 node
ui-source Option: Auto

Test Plan
basically follow the test plan in https://github.com/harvester/harvester/issues/6352#issuecomment-2326958381

Harvester Version: v1.4.0-rc2 , shell-image is emptyharvester-node-0:~ # kubectl get settings.management.cattle.io shell-image
NAME          VALUE
shell-image

Harvester Version: v1.3.2, shell-image is v0.1.26harvester-node-0:~ # kubectl get settings.management.cattle.io shell-image
NAME          VALUE
shell-image   rancher/shell:v0.1.26

Harvester Version: upgrade from v1.3.2 to v1.4.0-rc2, shell-image is emptyharvester-node-0:~ # kubectl get settings.management.cattle.io shell-image
NAME          VALUE
shell-image


text:
[TEST] Test CSI chart bump to v0.1.21 in Rancher 2.8 branch

What's the test to develop? Please describe
This would be a manual effort to test the CSI chart latest version v0.1.21 on Rancher. The validation should be done with RKE1 cluster only

[x] Deploy CSI latest version and verify the functionality of CSI chart.
- [ ] Deploy a pvc with Harvester storage class
- [ ] Attach to a workload, verify the volume attached in Longhorn.
- [ ] Scale down to 0, verify the volume detached in Longhorn.
[x] Uninstall the chart
[x] Upgrade scenario
- [ ] Deploy v0.1.18 CSI version
- [ ] Deploy a pvc with Harvester storage class
- [ ] Attach to a workload, verify the volume attached in Longhorn.
- [ ] Scale down to 0, volume will fail to reattach
- [ ] Upgrade CSI version to v0.1.21, attachment should work

Validated with Harvester v1.4.0 and Rancher v2.8.10. Tested with CSI driver v0.1.21 and upgrade from v0.1.18 -> v0.1.21.

authors: khushboo-rancher noahgildersleeve

repo: harvester/tests


text:
issue #205: GitHub repo link

Resolving #205
Description
Mobile:

Add a logo to the sidebar menu.

Mobile & Desktop:

Add a GitHub icon that navigates to the repo link.
Add dividers to the sidebar menu.

screenshots
Desktop:

Mobile:

@NoamGaash
Thank you!
About the i18n texts, done :)

repo: hasadna/open-bus-map-search


text:
Tests

I have added tests for utils.py except for make_redirect_url(). It has been used in oauth.py in oauth_auth_success() but I don't know how to test because I don't know in what scenario does oauth_auth_success function gets called. Any pointers?
Meanwhile I am working on adding tests to test_model_client.py

This branch I am working on is getting confusing as I have mixed up adding all kinds of tests for lastuser in there (unit, integration) and so am closing this and sending separate PRs for unit and integration.

repo: hasgeek/lastuser


text:
Charts[Network Node]: Ensure CI pipeline tests network node installation

User Story
As a software engineer,
I want

the CI pipeline, for both manual and PR based triggered runs, to perform all available Helm chart tests.

So that

I can be assured my changes did not break the Helm chart.

Assumptions

The helm test command runs all available tests.

Requested Changes

Add the following workflow level permissions near the top of the zxc-compile-code.yaml CI workflow: permissions:
      id-token: write
      contents: read

Add the following GCP authentication steps to the zxc-compile-code.yaml CI workflow:    - name: Authenticate to Google Cloud
      id: google-auth
      uses: google-github-actions/auth@ef5d53e30bbcd8d0836f4288f5e50ff3e086997d # pin@v1
      with:
        token_format: 'access_token'
        workload_identity_provider: "projects/101730247931/locations/global/workloadIdentityPools/hedera-registry-pool/providers/hedera-registry-gh-actions"
        service_account: "swirlds-automation@hedera-registry.iam.gserviceaccount.com"

    - name: Setup Google Cloud SDK
      uses: google-github-actions/setup-gcloud@d51b5346f85640ec2aa2fa057354d2b82c2fcbce # pin@v1

Update the Makefile to add the setup-nodes and start-nodes targets as prerequisite for the test target.
Update the CI pipeline to run both NMT and Direct install variants:

make test SCRIPT_NAME=direct-install.sh
make test SCRIPT_NAME=nmt-install.sh

:tada: This issue has been resolved in version 0.5.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

authors: nathanklick swirlds-automation

repo: hashgraph/full-stack-testing


text:
Align log with execution apis (0.4)

Description:
CHerry-pick #337 to release/0.4
Update log response integers to be hexadecimals
Related issue(s):
Fixes #337
Notes for reviewer:

Checklist

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

Codecov Report

Merging #364 (c3ef282) into release/0.4 (37d5eb6) will not change coverage.
The diff coverage is n/a.

@@             Coverage Diff              @@
##           release/0.4     #364   +/-   ##
============================================
  Coverage        62.29%   62.29%
============================================
  Files                9        9
  Lines              870      870
  Branches           142      142
============================================
  Hits               542      542
  Misses             290      290
  Partials            38       38

Impacted Files
Coverage Δ

packages/relay/src/lib/eth.ts
64.25% <ø> (ø)

Continue to review full report at Codecov.

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

authors: Nana-EC codecov-commenter

repo: hashgraph/hedera-json-rpc-relay


text:
fix: Add Ansible on Dockerfile + Hardening alpine packages

What problem is this solving?
Ansible provisioner not working, because in the base image ansible package was not included
Types of changes

[X] Dockerfile: Including ansible package

[X] Dockerfile: Upgrade son package with vulnerabilities:

CVE-2022-32207: curl from 7.83.1-r1 to 7.83.1-r2

CVE-2022-32206: curl from 7.83.1-r1 to 7.83.1-r2

CVE-2022-32208: curl from 7.83.1-r1 to 7.83.1-r2

CVE-2022-32205: curl from 7.83.1-r1 to 7.83.1-r2

CVE-2022-30065: busybox from 1.35.0-r13 to 1.35.0-r15

CVE-2022-29187: git from 2.36.1-r0 to 2.36.2-r0

CVE-2022-2097: openssl from 1.1.1o-r0 to 1.1.1q-r0

CVE-2022-34903: gnupg from 2.2.35-r3 to 2.2.35-r4

Additional Info

You can review a build workin on Build Artifact

Checklist

[X] Bug fix (a non-breaking change which fixes an issue)
[X] New feature (a non-breaking change which adds functionality)
[] Breaking change (fix or feature that would cause existing functionality to change)
[] Requires change to documentation, which has been updated accordingly.
[X] Unit test (Add or update unit test)

Screenshots

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement
Learn more about why HashiCorp requires a CLA and what the CLA includes
Have you signed the CLA already but the status is still pending? Recheck it.

authors: hashicorp-cla jveraduran

repo: hashicorp/packer-github-actions


text:
Support async actions

Second PR after breaking down https://github.com/jd/tenacity/pull/433 (follows https://github.com/jd/tenacity/pull/434)
After DRYing the iter() function, make AsyncRetrying support async callbacks.

@jd second PR here stacked on the first one I opened against your repo. Please let me know if you prefer that I opened it against your main instead (which would include the commits of the previous PR too).

Superseded by https://github.com/jd/tenacity/pull/437

repo: hasier/tenacity


text:
Inline Markdown link doesn't render correctly when it's first thing on a line

I've come around a bug/quirk where Markdown link syntax doesn't render into a Html link (the output is the link syntax literally):
{-| Some multi-line comment that points to
[foo](https://en.wikipedia.org).
-}
someFunction :: Int -> Int
...

The issue only occurs when that link is the first  on a line.
So, the issue is resolved when adding a space in front of [foo]
{-| Some multi-line comment that points to
 [foo](https://en.wikipedia.org).
-}

or some other word
{-| Some multi-line comment that points
to [foo](https://en.wikipedia.org).
-}

The following also works correctly:
{-| [foo](https://en.wikipedia.org) within
some multi-line comment.
-}

Tested with Haddock version 2.24.2 within Stack version 2.7.3 x86_64 hpack-0.34.4 on NixOS 21.11, GHC version 8.10.7.
A project to test against can be found in https://github.com/malteneuss/hakyll/blob/5a7742a64bf9b41827138aeddd35b00504548971/lib/Hakyll/Core/Rules.hs#L147

Duplicate of #774?!

Yes.

authors: malteneuss sjakobi

repo: haskell/haddock


text:
Add scene support for scenes defined in Home Assistant

 is a comment.
You will see these throughout the issue template. Make sure you do not type your comments
between these characters or we will not be able to see what you wrote!

4. Links
To create a hyperlink, type the [text you want to link](followed by the url in parenthesis)
-->
Is your feature request related to a problem? Please describe.

I bought this light switch, which displays and allows you to activate Hue scenes for the chosen room.
Violet smart switch lite
It would be great to have this work natively with hass-emulated-hue !
Describe the feature that you would like to be added

Support for scenes:

Scenes defined in HomeAssistant should be exposed by the /scenes API route.
Scenes defined in HomeAssistant can can be recalled/activated by calls to the /groups/id/action route, specifying a scene ID in the request body as per the standard API.

Describe alternatives you've considered

I have used Postman to call the create scene API endpoint to define scenes manually, with some success.
Describe your use case for this feature

Exposing the scenes defined in home assistant will avoid having to create them manually and would be of benefit to all users, not just those who want to use the light switch I've mentioned!
Additional context

One concern is that it wouldn't be modifiable through the hue API. The other major feature I would like to work on is the v2 api

The v2 api will be great to get implemented once we see the documentation for it :)
Could we just return an appropriate http error code if a user tried to edit a hass managed scene?
It would also be nice to have a config option to turn on the scene integration only if required.

The issue with error messages is that all apps won't necessarily respond correctly to it as its not something that is normally encountered with the normal hue bridge. While I'm not sure of the exact outcome, I would not be surprised if many if not all apps crash when trying to do that.
Regardless, will consider this for the future as development here has been slow.

That's a good point about the crashes. I guess the other option is to discard the new values in the request and then return an OK response?

Made some changes in my own fork that have got this working for my use case - compare
All the existing scene functionality is retained, but now the hass scenes are exposed as well. Hass scenes are identified by the presence of an entity_id attribute in the scene config and as such, when the action to recall a scene is handled, the command is directed to hass to turn_on the scene instead of running the original code.
If a user deletes a hass scene through the api, the scene does not get deleted from hass and will therefore get recreated automatically the next time the /scenes endpoint is called.
If a user edits a hass scene through the api, the changes are not propagated to hass, so the changes have no effect

repo: hass-emulated-hue/core


text:
Using pyproject.toml triggers special pip behavior

I shouldn't have to kick pip into a new, incompatible mode just to configure towncrier.  towncrier should provide an alternate configuration mechanism that avoids pep 518 and pyproject.toml completely.

One possible work-around would be to add an option to specify a file to use instead of pyproject.toml.  If an alternately named file is used it won't trigger the special processing from pep 518.

This becomes even more problematic with pip 19:
editable mode is not supported for pyproject.toml-style projects. pip is processing this project as pyproject.toml-style because it has a pyproject.toml file. Since the project has a setup.py and the pyproject.toml has no "build-backend" key for the "build_system" value, you may pass --no-use-pep517 to opt out of pyproject.toml-style processing. See PEP 517 for details on pyproject.toml-style projects.

This requires special pip switches for editable installs.

I don't know what the original issue text means, but the comment from @zgoda-mobica made me look up that message from pip.
Apparently more people have complained about this pip behavior, see this thread. (I haven't fully read it.)
And a couple of hours ago, a pip PR was merged that reverts the changes that caused the editable mode problem. So should be fixed with a new pip release.
@exarkun Is this the problem you meant or was it something else?

Note the issue was filed more than 4 days ago so I don't think the recently merged pip PR solves the issue.
I'll try to recreate the problem and post more details.

Actually, maybe I won't, because #127 was merged and provides a work-around.  Not sure why this issue is still open at all.

I'm not sure how to reproduce the original problem now that there's a new pip release with a new behavior, anyway.  The problem was probably originally encountered via tox which wants to do extra management of installed versions.  The obvious attempt at pinning an older version of pip doesn't produce the problem.  Consider #127 is merged I'm not sure it's worth digging through the history further to try to understand.  If it's still broken, I'm sure I'll be back. ;)
I'm gonna call this fixed by #127.

authors: exarkun mauritsvanrees zgoda-mobica

repo: hawkowl/towncrier


text:
Allow for multiple fragments with the same ticket and type

This extends the fragment format to be <issue>.<type>(.<counter>) i.e have an optional .counter after the type, which needs to be an integer.

Codecov Report

Merging #119 into master will increase coverage by 0.08%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #119      +/-   ##
==========================================
+ Coverage   93.19%   93.27%   +0.08%
==========================================
  Files          12       12
  Lines         485      491       +6
  Branches       53       54       +1
==========================================
+ Hits          452      458       +6
  Misses         19       19
  Partials       14       14

Impacted Files
Coverage Δ

src/towncrier/test/test_write.py
100% <ø> (ø)
:arrow_up:

src/towncrier/test/test_format.py
100% <ø> (ø)
:arrow_up:

src/towncrier/_builder.py
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

@Cadair Could you write a changelog entry for this? :)

done :)

ping? :angel:
Anything else that needs to happen on this?

authors: Cadair codecov-io hawkowl


text:
[HKWINVENT-24] WIP - port pinger to new inventory bus

This builds on top of #69 and re-adds the ability of the inventory to inform about changes inside over the bus.
There are still some problems though, so don't merge yet.

This depends on PR https://github.com/hawkular/hawkular-inventory/pull/46 in inventory and on the ability of inventory to create entities and add properties to them at the same time (which is pending).
Once both of those features are in, this should theoretically work.

Can you start the pinger immediately, so we start collecting data sooner than collection period. We would like to have the UI show results faster than the current collection period.

I'm glad I managed to hack around the pinger enough to make it receive the new inventory messages, but I see no deeper into it ;)
@pilhuhn would you be able to comment on @mtho11's request?

Closing this pr on behalf of PR #75 (it's based on it)

authors: Jiri-Kremser metlos mtho11

repo: hawkular/hawkular


text:
[hax editor] Exception while loading insights dashboard

I see the following console errors when attempting to load the insights dashboard via my local editor.
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://haxapi.vercel.app/api/apps/haxcms/insights. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 500.

Request failed TypeError: NetworkError when attempting to fetch resource.

Uncaught (in promise) TypeError: e is null

Drilling down, e seems to refer (possibly?) to this line in haxcms-site-insights.js.
            <lesson-highlight icon="editor:insert-drive-file">

${e.pages?e.pages:s`0`} ${this.t.pages}

${e.objectives} ${this.t.learningObjectives},
              ${e.authorNotes} ${this.t.authorNotes},
              ${e.specialTags} ${this.t.specialElements},
              ${e.dataTables} ${this.t.dataTables},
              ${e.headings} ${this.t.headings}

            </lesson-highlight>

support for local dev path (via node) which is not in need of rewriting our environment to point to local version. This is a dividing line as to why we should maintain some kind of forced 'demo' space for local testing but at least now MFR is able to detect nodejs and keep w/ the open-apis instead of assuming local

authors: btopro whatsacomputertho

repo: haxtheweb/issues


text:
ADD event details for Rustathon 2k18

also added images

Merged via #54

authors: haxzie nathanielmathew

repo: haxzie/sosc-website


text:
Near cache implementation for MixedMap

Implements the near cache support for mixed type support for all data structures.

Test FAILed.

Test FAILed.

verify

Test PASSed.

Test PASSed.

Test FAILed.

Test FAILed.

Test FAILed.

Test FAILed.

Test FAILed.

Test FAILed.

Test FAILed.

Test FAILed.

Test PASSed.

Test FAILed.

Test FAILed.

Test FAILed.

Test FAILed.

Test PASSed.

authors: devOpsHazelcast ihsandemir

repo: hazelcast/hazelcast-cpp-client


text:
Yahoo email address verification no longer works

It looks like Yahoo has removed their JSON check API to check for valid accounts/emails. It now goes to a page not found.
https://github.com/hbattat/verifyEmail/blob/master/src/VerifyEmail.php#L226

I knew it won't work for long. So, now for the hard way!
I just updated the class to verify yahoo emails using the sign up form. It imitates a sign up form submission with the email we want to verify, then parse the response to see if they complained about existing email.
Let's see how long before this breaks too :)
Thanks for reporting. Let me know if you see an issue with the latest update.

This has been fixed in v1.0.6

repo: hbattat/verifyEmail


text:
sqlite3.OperationalError: attempt to write a readonly database

After updating label-studio to latest version(1.7), When I am restarting  label-studio with docker , I am always getting this error

Please check section Breaking changes in Release Notes for 1.7.0:
https://github.com/heartexlabs/label-studio/releases/tag/1.7.0

=>
Breaking changes
Starting with this release, the application will run using a non-root docker user with ID 1001.
If you encounter any permission issues when running the application in a docker container, you can fix them by changing the ownership of the relevant files and directories to 1001.
docker run -it --user root -v `pwd`/mydata:/label-studio/data heartexlabs/label-studio:1.7.0 chown -R 1001:root /label-studio/data/

authors: farioas gauravjadhav-1997 makseq

repo: heartexlabs/label-studio


text:
Slow interactions with many RectangleLabels

Describe the bug
When a lot of RectangleLabels are loaded in (> 100, like in OCR), moving around and zooming in the image becomes very slow.
To Reproduce
Steps to reproduce the behavior:

Create project with OCR template
Upload image with several hundred annotations
Open label editor and try to zoom in and move around the image

Expected behavior
It would be nice if performance (and therefore user experience) would be improved in this case.
Environment (please complete the following information):

OS: Ubuntu 16
Label Studio Version 1.0.2

Region performance was improoved in release/1.1.0. Feel free to reopen if you have this problem again.


text:
Avoid completion conflict with modern 'nix' CLI

[This supersedes https://github.com/hedning/nix-bash-completions/pull/21.]
Upstream nix (>=2.4) has completion for the modern 'nix' CLI, and the
completion provided by nix-bash-completions cause a conflict that breaks
completion:
$ nix build<TAB_TAB>  # line gets erased
Fix it by not installing completion for 'nix', which lets Nix handle its
own completions.
As a side effect, this breaks/removes completion for the experimental
'nix' commands in nix<=2.3, but hopefully there is no real use case for
that anymore as even the latest NixOS version use nix>=2.8.
Fixes https://github.com/hedning/nix-bash-completions/issues/20.

Ping?

Ping. NixOS 22.05 has Nix 2.8.1, which means completing modern nix ... is now broken. It would be great to have this PR landed and release a new version of nix-bash-completions :-)

@hedning: friendly ping

@ncfavier: friendly ping?

I want this as much as you do, but the maintainer is unresponsive. Perhaps it is time to add this patch in nixpkgs.

I want this as much as you do, but the maintainer is unresponsive. Perhaps it is time to add this patch in nixpkgs.

Oh, I guess I assumed you had commit rights based on this comment, and I realized I hadn't pinged you in this PR.
Ok, nixpkgs next.

https://github.com/NixOS/nixpkgs/pull/207224

authors: bjornfor ncfavier

repo: hedning/nix-bash-completions


text:
Null Pointer Exception when using Builder Based RestClients and FT annotation and FT metrics together

Environment Details

Helidon Version: 2.5.4
Helidon SE or Helidon MP : MP
JDK version: 17
OS:
Docker version (if applicable):

Problem Description
We are noticing a problem with helidon.microprofile.faulttolerance
Our micro service is using RestClient. This rest client has @Retry annotation. But its not having @RegisterRestClient.
We are creating an instance of RestClient at run time using RestClientBuilder.newBuilder().build() and uses it.
Since we are not using @RegisterRestClient ,the bean is no prepared and FaultToleranceExtension.registerFaultToleranceMethods is not invoked for our Restclient while starting the container.
Hence our method is not added to the collection FaultToleranceExtension.registeredMethods;
So when FaultToleranceExtension.registerMetricsAndInitExecutors loops through  registeredMethods to invoke FaultToleranceMetrics.registerRetryMetrics , since our method is not present in the registeredMethods , retry.retries.total counter is not registered for our method.
Once the container is started and our services uses the RestClient(created at run time) , CommandInterceptor.interceptCommand is called, which calls MethodInvoker.get(), which calls updateMetricsAfter() , which calls updateCounter().
In updateCounter() , Counter counter = getCounter(method, name) returns null (our counter is not registered as i mentioned above)  .
But there is no null check. Hence counter.getCount() throws null pointer exception

Stack trace
Caused by: java.lang.NullPointerException: Cannot invoke "org.eclipse.microprofile.metrics.Counter.getCount()" because "counter" is null
at io.helidon.microprofile.faulttolerance.MethodInvoker.updateCounter(MethodInvoker.java:764) ~[helidon-microprofile-fault-tolerance-2.5.4.jar:2.5.4]
at io.helidon.microprofile.faulttolerance.MethodInvoker.updateMetricsAfter(MethodInvoker.java:657) ~[helidon-microprofile-fault-tolerance-2.5.4.jar:2.5.4]
at io.helidon.microprofile.faulttolerance.MethodInvoker.get(MethodInvoker.java:436) ~[helidon-microprofile-fault-tolerance-2.5.4.jar:2.5.4]
at io.helidon.microprofile.faulttolerance.CommandInterceptor.interceptCommand(CommandInterceptor.java:54) ~[helidon-microprofile-fault-tolerance-2.5.4.jar:2.5.4]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73) ~[weld-core-impl-2.5.4.jar:2.5.4]
at org.jboss.weld.interceptor.proxy.WeldInvocationContextImpl.invokeNext(WeldInvocationContextImpl.java:92) ~[weld-core-impl-2.5.4.jar:2.5.4]
at org.jboss.weld.interceptor.proxy.WeldInvocationContextImpl.proceed(WeldInvocationContextImpl.java:124) ~[weld-core-impl-2.5.4.jar:2.5.4]
at org.jboss.weld.bean.InterceptorImpl.intercept(InterceptorImpl.java:105) ~[weld-core-impl-2.5.4.jar:2.5.4]
at org.glassfish.jersey.microprofile.restclient.InterceptorInvocationContext$InvocationInterceptor.intercept(InterceptorInvocationContext.java:136) ~[jersey-mp-rest-client-2.35.jar:?]
at org.glassfish.jersey.microprofile.restclient.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:108) ~[jersey-mp-rest-client-2.35.jar:?]
at org.glassfish.jersey.microprofile.restclient.RestClientModel.invokeMethod(RestClientModel.java:69) ~[jersey-mp-rest-client-2.35.jar:?]
at org.glassfish.jersey.microprofile.restclient.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:70) ~[jersey-mp-rest-client-2.35.jar:?]
at jdk.proxy2.$Proxy239.getFeedConfigurationBySignal(Unknown Source) ~[?:?]
at com.oracle.osc.digitalsales.restclient.impl.FARestClientImpl.getFeedConfigurationBySignal(FARestClientImpl.java:189) ~[osc-commoncore-23.04.1-M4-SNAPSHOT.jar:?]
at com.oracle.osc.digitalsales.restclient.impl.FARestClientImpl$Proxy$_$$_WeldClientProxy.getFeedConfigurationBySignal(Unknown Source) ~[osc-commoncore-23.04.1-M4-SNAPSHOT.jar:?]
at com.oracle.osc.feed.rest.fa.client.facade.impl.FaRestClientFacadeImpl.getFeedConfigurationBySignal(FaRestClientFacadeImpl.java:129) ~[feed-system-api-1.jar:?]
... 168 more

repo: helidon-io/helidon


text:
Unsatisfied dependencies for type Boolean with qualifiers @ConfigProperty

Environment Details

Helidon Version: 4.1.3
Helidon MP
JDK version: Temurin-21.0.4+7
OS: Windows 11
Docker version (if applicable): N/A

Problem Description
I am using Helidon version 4.1.3 with MicroProfile Config and encountered an unusual exception when injecting org.eclipse.microprofile.config.inject.ConfigProperty with jakarta.inject.Provider<Boolean>. The error message states:
org.jboss.weld.exceptions.UnsatisfiedResolutionException:
    WELD-001334: Unsatisfied dependencies for type Boolean with qualifiers @ConfigProperty
        at org.jboss.weld.bean.builtin.InstanceImpl.checkBeanResolved(InstanceImpl.java:251)
        at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:113)
        at it.test.com.my.WalkthroughIT.whenGetConfigFromProvider(WalkthroughIT.java:88)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:38)
        at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:106)
        at it.test.com.my.WalkthroughIT$Proxy$_$$_WeldClientProxy.whenGetConfigFromProvider(Unknown Source)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        at java.base/java.util.concurrent.RecursiveAction.exec(RecursiveAction.java:194)
        at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:387)
        at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1312)
        at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1843)
        at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1808)
        at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:188)

Steps to reproduce
Below is my test class:
package it.test.com.my;

import org.eclipse.microprofile.config.inject.ConfigProperty;
import io.helidon.microprofile.testing.junit5.HelidonTest;
import jakarta.inject.Inject;
import jakarta.inject.Provider;

@HelidonTest
class WalkthroughIT {

    @Inject
    @ConfigProperty(
        name = "providerBoolean", defaultValue = "true"
    )
    private Provider<Boolean> providerBoolean;

    @Test
    @DisplayName(
        "When getting config from provider, it must succeed."
    )
    void whenGetConfigFromProvider() {
        BDDAssertions.then(this.providerBoolean).isNotNull();
        BDDAssertions.then(this.providerBoolean.get()).isTrue(); // <--- Exception thrown here.
    }

}

NOTE
Surprisingly, when there is an additional injection of org.eclipse.microprofile.config.inject.ConfigProperty directly with Boolean, no exception occurs.
package it.test.com.my;

import org.eclipse.microprofile.config.inject.ConfigProperty;
import io.helidon.microprofile.testing.junit5.HelidonTest;
import jakarta.inject.Inject;
import jakarta.inject.Provider;

@HelidonTest
class WalkthroughIT {

    @Inject
    @ConfigProperty(
        name = "providerBoolean", defaultValue = "true"
    )
    private Provider<Boolean> providerBoolean;

    @Inject
    @ConfigProperty(
        name = "objectBoolean", defaultValue = "true"
    )
    private Boolean objectBoolean; // <--- Here is an additional.

    @Test
    @DisplayName(
        "When getting config from provider, it must succeed."
    )
    void whenGetConfigFromProvider() {
        BDDAssertions.then(this.providerBoolean).isNotNull();
        BDDAssertions.then(this.providerBoolean.get()).isTrue(); // <--- This works like a charm.
    }

}

Could you please provide further advice? Thank you very much for your help in advance. I look forward to hearing from you soon.

This failure, along with the workaround, also applies to the injection of ConfigProperty with the following (and possibly others):

Provider<Byte>
Provider<Long>
Provider<Float>
Provider<Double>
Provider<Character>
Provider<String>

Additionally, the custom Converter is also affected, and the workaround is also successful.
package it.test.com.my;

import java.util.concurrent.TimeUnit;
import org.eclipse.microprofile.config.spi.Converter;

public class TimeUnitConverter implements Converter<TimeUnit> {

    @Override
    public TimeUnit convert(final String value)
                    throws IllegalArgumentException,
                           NullPointerException {

        return TimeUnit.valueOf(value);

    }

}

# META-INF/services/org.eclipse.microprofile.config.spi.Converter

it.test.com.my.TimeUnitConverter

package it.test.com.my;

import org.eclipse.microprofile.config.inject.ConfigProperty;
import io.helidon.microprofile.testing.junit5.HelidonTest;
import jakarta.inject.Inject;
import jakarta.inject.Provider;

@HelidonTest
class WalkthroughIT {

    @Inject
    @ConfigProperty(
        name = "providerTimeUnit", defaultValue = "MILLISECONDS"
    )
    private Provider<TimeUnit> providerTimeUnit;

    @Inject
    @ConfigProperty(
        name = "objectTimeUnit", defaultValue = "SECONDS"
    )
    private TimeUnit objectTimeUnit; // <--- Here is an additional.
                                     // <--- Without it, an exception is thrown.

    @Test
    @DisplayName(
        "When getting config from provider, it must succeed."
    )
    void whenGetConfigFromProvider() {
        BDDAssertions.then(this.providerTimeUnit).isNotNull();
        BDDAssertions.then(this.providerTimeUnit.get()).
            isEqualTo(TimeUnit.MILLISECONDS); // <--- This works like a charm.
    }

}


text:
Use Hamcrest assertions instead of JUnit in tests/integration/restclient (#1749)

Part of #1749
Backport 2.x

/trigger


text:
Add HIP draft for HIP-####-reward-MOBILE-carrier-beta-hotspots

This was drafted based on discussion during the 9/19 MWG Meeting.

If there's a way to know how many connections a hotspot gets AND if that can be a variable used to modify rewards a simple modifier based on connections is cleaner I think.
"A hotspot serving unique connections will receive an additional 0.01 modifier per connection up to 100 connections." That way connections are the incentive, no need to track paid or unpaid data. Goal is to incentivize new hotspots being deployed in high traffic areas. You can drop the bump to 1.0 for hotspots in 103 modified areas as unique connections will drive what they should  be rewarded. Cap it at 100, either daily or rolling weekly, whichever is simpler.

If there's a way to know how many connections a hotspot gets AND if that can be a variable used to modify rewards a simple modifier based on connections is cleaner I think.
"A hotspot serving unique connections will receive an additional 0.01 modifier per connection up to 100 connections." That way connections are the incentive, no need to track paid or unpaid data. Goal is to incentivize new hotspots being deployed in high traffic areas. You can drop the bump to 1.0 for hotspots in 103 modified areas as unique connections will drive what they should be rewarded. Cap it at 100, either daily or rolling weekly, whichever is simpler.

Nova knows how many connections a hotspot is getting, but need to discuss with them how easy is it would be to use it as a variable like you suggested.  Was hoping to get some feedback on this in the next MWG.
I like the idea of 0.01 modifier up to 100 connections if it's easy to implement.  I do think data transferred is important.  I could set-up my hotspot on top of a busy highway and get a lot of connections, but I probably won't transfer a lot of data.  We want high footfall areas with long dwell times.  Plus rewarded data means someone paid for it and results in HNT burn which is good for the ecosystem flywheel.

Easy to implement is something I have no information on. Up to the devs to let you know. I’d offer run the modified subscriber multiplier the following epoch. I.e. Monday’s connections modify Tuesday rewards just to smooth compute cycles.
Requiring data thresholds gives an incentive to artificially use carrier plans to get rewards. Consider the what that will look like.

Back to the importance of number of connections visibility, if it's possible for that number to be shared and even used in rewards calculations.
Just had a conversation with a host asking if I could tell them how many unique phones connected, seems they have an interest in near real time hard data about foot traffic.

Back to the importance of number of connections visibility, if it's possible for that number to be shared and even used in rewards calculations.
Just had a conversation with a host asking if I could tell them how many unique phones connected, seems they have an interest in near real time hard data about foot traffic.

Remember that carriers don't pay for unique connections, but pay for data over connections, so rewarding per connection may not be the right way to incentivize deployments. I suggest that unique connections are useful from a planning perspective (and in fact planner has a layer showing just that)  and could count as an eligibility criteria for rewards instead.

@WorkingTitle-Helium I am concerned that introducing some linear rewards accelerator as a function of connections / data served could be a recipe for gaming. My suggestion is to keep it binary. I.e. we agree on a threshold, like 25 unique connections in the last day and, if you met the threshold - you are excused from CDR and maybe some other requirements. If you didn't - then you are not.

@zer0tweets My thoughts were around carrier offload is something Nova could disable if a hotspot was somehow selected and gaming, just update the hotspot in question to a non-carrier version and all the 131 requirements are in place. Also my inclination is hotspots in high traffic areas that get 100+ connections a day should be rewarded more than non-carrier hotspots and hotspots with even 25 connections. I see that as encouraging the community to deploy in commercial locations. I am not a fan of any data transfer benchmark as most data is now paid and that's enough of a reward. Looking forward to discussing this in a HIP channel.

authors: WorkingTitle-Helium jhella madninja zer0tweets

repo: helium/HIP


text:
[Removal]: Cuddly Ebony Huskie

Hotspot Name
Cuddly Ebony Huskie
Hotspot b58 Address
1128nDozMUUgzcWmJovGYW235HwMa3UPgW9fjRccLVGXX6uDC8Q6
Discord Handle
BogdanG#1799
Hotspot Manufacturer
SenseCap
Removal Reason
This hotspot was bulk added to the denylist along withe the whole town again.
Modifications
No
Extra forwarders
No
Extra antennas
No
Additional Information
Hi again im the owner of Blunt Ivory Ferret,Cold Tan Beetle,Cuddly Ebony Huskie and Fast Jetblack Finch all they are regular.
Please remove them from the denylist.

We do not have sufficient evidence to remove these hotspots from the denylist. 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.

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

repo: helium/denylist


text:
[Addition]: Hundreds of PantherX spoofers are being added to the US as we speak

Hotspot b58 Addresses
112TNbgBQ1rT2hkBJFcisqsJL1Tp8z546NT2ju5DE4c1WtxR1ucb
116QHsKocAaSNvrqpbHgqn6DauWSPpYDTQE2HeRRqUDB65xqMmP
11UagNTqDSizn1Q3XHT4yMEH5tJrx2kbBi9GqsViCE4sLvc7jVg
112ohWseGKpv5jCHiqw5KZsCDk2iwSv9uW3Yt1Vcegmzm2jxWFbR
117UEyqqH5BkCwizp2mj9BhnxJFcB2Pnoh3Tm4Td5eTdSA8DHG4
11ToqngSwb8nZfqXFNTe8vSuWEnon6j4s6AdFaGhYhfiza4fXor
112CLjpP4EnHTrtQayXwTSPKwzgrfqYuqCHBSaUUMLc2T8vzNZr1
112So9Fp5QtFD6uUu8nvbwUfbacEWmGEb1wBZtNtQvezosrmcSzF
11T1zFjn8y16D5bAt9VPfmCBynJzt7KbCn8BNQULJVvqDWwQRHF
112dzzH53cYTeKL9mhFZGV7oW2yC3Mcz8PQPQQUrkHE7RmufRqT1
11fx1N7jH7SVnqiWu1AFeDHAGQGQ7LrZJojuK1o5i5AF7g28hE8
112GbfoAMsSTSVyciez8Yaf3XMEdM9rXuTXAb7K1VT3vi9mxnUft
11Kf46Z4pfzDpJqkcYTEpcT6oqYJETL4YUg4uoEwABw1Xa1DSAA
11kQjwbpzYx7DY9uWq5NmVkAn5vEa6sMxkVEEdHdAKVPrkM9P2n
11FgQnJJj15z6vBK4BY7LYzztKCHzHkqBqFx3VHyi4yWbTPetKZ
1123JJfqoVTNVjRYKPozsBx9ntkVwNpy6ReKenJ3zYm5k5tyNC1K
1123uKanxLAP1gvAh4y2fR984xeRidc4F3PGaCnhgN5z7WaS8DCa
1124W9Wo9A9q1DcfXvY8poeFTHS2BKmQK271Z66wSQtJJnJXpVcw
112cyqjaorvWYyxCcCiUAYqQL2Wuva7Rwmr4nhh6NGHU18BknreG
112FQ5z9DmBMfaWbzfDZtGh5x1cwtV1sgZ4q5SUdayz2KPRTV4nS
112FUPaUU3QDkhCUXS95DJ5JX2XyUZgPNwaAu8JEtHPSvdhv4gjT
112mzjcVJNZgDvh67CjRuWu8o9udddi9Y1a21snk5eM2gQ4X8Kqf
112uvhgGqr3VEPxNDJoeYPqgUtNvAaZTVi3SzvrHPqP6D1x4AdRd
11dweW3qVXbVcyQtNfyCvh3oBS8pxmUzYCtuwrecY5GxYJzfrjY
11GLdC4rnsmDk9SV6cikWUPznQptHMhYcC11vxJi6wdbRmH5GUk
11GNTBuZNjyZagxEeDgfeWyoHVxXgpB2bvzSxqCZ7N1RqKYkeuu
11KtXgcgwKKZuPTHuKMxcootzyjz6JY2oQ4Z4tziFc53E1zLTDx
11PgdWUA5HNr8iwKKnBM9SXorw3ND1PiLNUa19xCeztgUGQXqVh
11ybAJUw4kxfmiqAkPEjAC3RYCTX8rK4L6tVNKGqFrg1PeRWJAg
11Yn5LyQW1t773LNoagTu133v6yb3YHhRchuEAQ9SMms7of7brn
1121K5RKpranddTKDNCwyA8ocZCVDLFV6G6ZFm92ChiycFYnykJx
112dugp8SQVeBPauGUVWmcRZC9Zf58DVBsnCjKhG5aW7WmV5qh3
112dyXNKpFq2rJAYUKJ3G1JefJxockrWyQxjXNCn8KEdmVQdgXSX
112eFcaWR8woMoZ9qkyQ2ZES7E858dbN3dcemon5vjf6wazvAiu5
112Sv1KHNXPCd4jb7oZaQ1NsiP2aEDpbGx8JbK36ShKLPQnx4M42
112vNUGPuuo4fnQA6FYWejruYQvLBFFvWDauJtQ7rwMbpcYnfubd
112WmFP3kRfmaS1Knct1wLB4LScw5QUeobesNoVBvwwkZ1au4cDW
11aEcJwGJJZJqHbpYbSgLEqJHWh6J7cipi2428ywd5wN9k6NZPe
11c2z5LSFfZkHstpZSoMSUBoH6FiR8KaVjC6RSxDidFXgBcvNHr
11p4abQ8mBXBkumbBdv4VcTrfsrrN5xamcTvLQDTkzDV5WDZwtH
11pPVXLcCko3KPtG128VaApFUq2AEkTGfUBZUNeUdcFcmhWfu3B
11s2BHDs49pbKMdUoSxwTa1scV8Uy3U7T5PuMQEGndUjtQhbpMK
11ZhEEsFfhbPbYsd52aztagc2Ys7EqryUmvyfTSqs7zVfz99kLk
1126Q8B2rkf5qBL2B697TUJjEZTyu77W8DVhtoSt6yXMd2cpvHzp
112MvZ2k1aAoQUCmyaBA3iWk7eCwWFV7CizaTn3s5gqQ76DeQsCL
112nmifWSNReSfAHdSXxPUp3BoAeEpyCVSkZWt1WqsuAhEpzURRb
11nSNJELWeXyvdepgbmyJPwf3Waqd4WCdyPBv6iihsBrEHpqVeo
11qVsXJtnKYejAPJmYmk8XnErgKDQaBX7yXFZQWkskuC1f1LokD
11236geMhrVtDuJN3DubY3zRVe4jhmcubfEEpyzqVLkyCNxmK9se
1125w3nApFBMVH5wSUzoGpaYQ42oWchQ1yYh5C3nz9xRY8j9mxzT
112AQ3dEcAFvNgaYMSXA4h9tS1YDoobf3smwMvKZj5BVimGxaj4G
112byVXHGZCcF7DpNu3FEbmx9mV4RPmEjCyZwisscLMi8C1YwoDQ
112DmWZJ8hySPMwdsfA8vo85Jp2umD68ovNuL37n9k3HAUkwmASV
112hd6HCwQxR29RmZdUs2Nqr9JBe7X9EtjxxFxgbpZywbQHzW36w
112jWq5jDJgfZSgxcctHWEVZre6GSnn8XszJjd4KhbaJp5vKMmN7
112NUZxt4FjQe5E462eVfyzvNr3TDwdku84Xe6RVQtyhc8NaRxe4
112NXkbExQXvu3ip95BzFYfUX4R39ugUTihwX5kwPSQBtrBE3uV1
112RJHbsFTS2TvkLMcXtv3VbEZP52dxhgw2pB24oYhxBdPF4pLiU
112SMShDgvxKMc3E3468SYLqJUpuKESb4798m3bcie7JkPBZvvfR
112weeS1s8z4y7brYzjkVH6K89ihpUz1DQxHJ7jXaXt6wrfK3Xw4
11dUqB8b3CdDoXkueZ8cEpwZzcK1YZ5MMKm7yfheX4z2wYZiiHh
11e9LHuvSApH3J386LZfUh6byQVnW2b4i4k4vwwcQrK6JyeSvdp
11ee9Bz3nYnaCpF2aVJqWW88J8igoeCx9jKKuQiHFuaM1sU3ah3
11h2MG1RtcWtBT3NfE6RabqakYHmFKTis43JwwVFSSNZ4SFkoHY
11kMpDG8TXFtQvRDJJ4SYppWcRZmEKYs3grWJnwJnBQwr5PN8MT
11kYUNN6chDKXKweyRhLAhdoCB8FmAKjFDbV92439mrVVvc4fL7
11rYVEHmaL2Hrv8q5zGoV3YxM5FxfietqxELwJmVRtnULrUBVPe
11YGhkEZ6Y8NGYDKmhz9rJEsdh9Pi4FC2um6RDh88FeamQy2hiH
Discord Handle
No response
Reason(s)
Just look at the screenshots. this is getting out of control...

They are doing exactly same thing as Deper, same method. Self witness and modify RSSI to make it legal in another same maker node.

authors: hexPi oosui


text:
[Addition]: Hummingbird selfwitnessing cluster

Hotspot b58 Addresses
111SDamKurHrxLBvTacw55AimHraA4YH3QRmLhGMhFZ8sJzVfW2
1121Sd3ehTHgjeHMqtRP2L7WmC32aRsMyDSvpAqxsZk9qZbWPrP
1124CTMBprEsFo1u8mwtE9z5sqBrddMzChNnNTeNA9mejsn4bQ4D
1128v4cxzdXtCJe93pyTuwaU7Ra48XgRHJvX6Ur9PTvY3RWxz8Z9
1129Y13G9XQnng5xbJ3HkcnSXNFRusG9JoXBdJj7naPxeTSXMj2v
112BnF65y7TktWtGUgs73BqhhhpvBfDSEvsd1QtiRMHpK3XbL3he
112Co4FXrTDXAjAkVZR8Pt9SBskU51m3xQKuyxwCG4GzdBKr9cNs
112fWbBc7Wd7MrSvRriGdHXgMyZWLo52DRwvT4EGEtSSq7Svou5v
112P5CPUYaNz7omPcc6Vk3cjFw44FoGfQWyQs1AvYrCKgVbfeY3Y
112qSKzZvT7SDPoch8axg7q6acrBJJjMEHbX5Jbkn9bS3Upq9ERn
112rbDJgzXQqW1efcy5sXjFjpgmqSu4HrAKeXk6T37fNYERpZmE1
112VF2UmBzKUJoF5LFiAsCi8Wsti6FA9472wx8fkAvYTy9ig4LBX
118DACLdrbbkGqKA3ceEWbn62hB8cvmMD2gMzA8CoPLUWNqVTHg
11FEbVC389yVXxqSCMEbB3wHNsoBAsbHD9MZoUfXhJDVYB8Giae
11MiiBWGxZxfo81drJ43obVh6WRyscaswgbTq6dgEH4pdCiKrYT
11pR8mdoYW5YC9q9Dy8DcLwiH2RgHsqdy6aXNfUnT9iD3K93BUL
11Sn1WggtVPLXnQWXYJMmZfMFfgmPMYPo8fQFZW5x7c6jFWbCd3
11tNzH6X7VuwhiAr7R14Nf9DA7eVjfKB842CM2Le4EZnZKnoWqi
11ZZCdVvhAwNScaSKNJY32w1VVq12PVdQqeoK2oso3S4qoRqCHR
Discord Handle
No response
Reason(s)

All but 1 account for all Hummingbird gateway's didn't show any data transfers.
So data transfer is possible! only 109 out of 3853 showed packet transfer data, all these 109 are in same account.
the gateway's in that account are part of a selfwitnessing cluster so they probably all heared the same
signal.

Most of all Hummingbird gateway's witness only Hummingbird gateway's.

We iterated the witnesses of the witnesses to find the clusters.
We used the node-red server we setup for this to get the results out of api.

All HNT stolen with the total amount of 21067 HNT as by todays date/time.

We conclude that out of the 3852 gateway's we inspected only 109 gateway's in 1 account showed accidental
data transfer. so data transfer for gateway's Hummingbird is possible.

We conclude that out of the 3852 gateway's we inspected only a couple of accounts showed communication with other makers. so communication with other makers for Hummingbird gateway's is possible.

Rssi/ distance / SNR calculations are to perfect, we have found some invalids -59 dbm but we suspect they are from cables touching eachother.

We haven't targetted any maker, it was the result of a count WHERE actors1.actor_role = 'witness'
AND actors2.actor_role = 'challengee' are in same account.

Resolved in https://github.com/helium/denylist/pull/4048


text:
Add Bobcat Miner 300 to Hotspots App

fix merge conflict

Cool! Thank you team!

repo: helium/hotspot-app


text:
ADR & manual console downlinks not being received by end device

Similar issue to https://github.com/helium/router/issues/497 but still ongoing on my device. I'm in EU863 region, using an original Helium hotspot. I moved my device over to the staging console to test with the updates from issue 497 but still seeing the same behaviour
I have been looking at the timestamps in the console to try and see where the issue is, but unsure if they provide enough info to base this on or not. As far as I understand, device will 'listen' for a downlink 1s & 2s after an uplink. For a join request I can see the accept message is sent 2s after the request

The accept message sets the Rx windows on the device to 1s

This is received, and my device joins. With ADR set, my device sends uplinks until #20 is reached, then the console sends a downlink, but it looks as though this occurs only 400mS after the uplink

My device does not see this, so an endless loop of downlink attempts is started, with nothing being received

Similar behaviour if I try to send a manual downlink via the console, except it seems to deploy a 500mS delay after the uplink is received

I am unable to get ADR or a manual downlink to my device, testing with an mClimate Vicki TRV
https://docs.mclimate.eu/mclimate-lorawan-devices/devices/mclimate-vicki-lorawan/vicki-lorawan-device-communication-protocol/communication-concepts

Unfortunately I missed the debug logs in the console, but this chart shows one of my sensors that has ADR enabled. I have a log running that records the 'spreading factor' used for uplinks, just so I can keep an eye on battery usage. It was uploading data using SF7BW125, but I assume as it never received a downlink from the console it can be seen stepping all the way up to SF12, with 20 uplinks per step.
After 24 hours of the console attempting downlinks to set the ADR 1 eventually got through, resetting my sensor to the correct SF7 (it's only about 10m away from my hotspot).
Downlinks will eventually get through it seems, but this shows it took approx 100 attempts before a successful one was received (10min uplink period * 24 hours = 96 uplinks)

Could it be that the downlink signal is too strong for the device to receive? Many LoRaWAN users (on Helium and other networks such as TTN) have experiences that short distances between gateway and device cause the RF frontend on the device to be saturated, which results in the device being unable to hear the downlink.
The situation can be compared to someone shouting into your ear using a megaphone from a short distance.
If you can, maybe it is worth trying to move the device a bit further away from the gateway?

@Net-Metrics have a look at issues #338 and #519, as well as the well documented #517.
I'd recommend start looking at the hold_time for your uplinks, this is the most likely cause for your downlinks not being received.

@nilotnas I read your #519 with interest, but can't see where to check the hold_time, can you point me in the right direction for that so I can compare?
Certainly a few people now having problems with this, pretty unusable for many commercial applications if downlinks cannot be reliably performed

@Net-Metrics for looking at incoming packets I usually open the debug window and tick the "Expand all" box in the top right corner, then do a search for hold_time. For looking at more data you can "Export JSON" and search through it.

@nilotnas average hold_time for my packets range between 1600-1800, bu have gone as high as 5000+. My device will regularly re-join the network, I assume as it is not receiving any downlinks. When it re-joins (which always seems to be successful on the first attempt), I see the following
    "category": "uplink",
    "data": {
      "dc": {
        "balance": 9145,
        "nonce": 1,
        "used": 1
      },
      "devaddr": "0B080048",
      "fcnt": 1,
      "hold_time": 302,

Then when uplink 2 is sent it reverts to the following
    "category": "uplink",
    "data": {
      "dc": {
        "balance": 9144,
        "nonce": 1,
        "used": 1
      },
      "devaddr": "0B080048",
      "fcnt": 2,
      "hold_time": 1809,

So this looks like the same issue as you are seeing, question is why is the hold_time low for a join_request, but then increases for standard uplinks

This is received, and my device joins. With ADR set, my device sends uplinks until #20 is reached, then the console sends a downlink, but it looks as though this occurs only 400mS after the uplink

That 400ms delay is interesting. I'm also seeing it here with downlinks failing https://github.com/helium/router/issues/517#issuecomment-997492361

Running on console 2.1.9 now and I had hoped the new Set Delay Before Rx1 Window setting in the device profiles would help with my downlink issues, but so far no luck. I have tried setting the Rx1 delay to all 5 settings, forcing a device rejoin after each change but still getting the same cycle of behaviour. Join request & Join accept always works first time ( with a 400ms hold_time give or take. I then get regular uplinks, with hold_time averaging between 1900 & 2300.
Device sends 20 uplinks (using SF12BW125), console then tries to send a downlink with the following MAC commands

Data Rate
5

TX Power
1

Channel Mask
255

Channel Mask Control
0

No. of Transmissions
0

Unfortunately this downlink is never received by my device, it continues to go through the uplink/downlink attempt cycle, until my device gets to approx 96 uplinks (24 hours, 1 * uplink every 15 mins), after which it sends another join request and the cycle starts again
I have tried this with all delay settings, and before trying the 2s delay again there, I deleted the device & re-added as a 'new' device to see if that helped, no change in behaviour

@Net-Metrics there have been key changes made but not yet released for this. I was told to wait, don't waste your time on it.

Status Update

This issue has priority and is being actively investigated
Most likely the root cause from an examination of the logs - the end-device does not physically receive the ADR downlink
The root cause issue can be explained by pending rx-delay work.  I'll re-post here when the rx-delay work is deployed.
Another potential cause is that rssi from some gateways is too high.  This would result in ADR setting DR and TX too high.  Work is pending  on this issue.
ADR is complex - working is pending to add more unit ADR unit tests

An additional 40 unit tests verifying ADR behavior have been added.  The ADR algorithms, at least internally, is behaving correctly.
https://github.com/helium/router/pull/574
Additional unit tests for edge cases are planned.

@Net-Metrics - The RX delay should be deployed now.  This must be configured in your device's config profile.  The default remains 1 second.  So you'll need to increase the setting to 5 seconds or more.

@Net-Metrics - The RX delay should be deployed now. This must be configured in your device's config profile. The default remains 1 second. So you'll need to increase the setting to 5 seconds or more.

The UI setting has been on staging for a while, but there was an outstanding issue that caused downlinks to fail on settings not equal to 1 second (the original value).
Looking at Sprint 68 it doesn't look like this entire feature has been completed or deployed end to end - just trying to save people from confusion.

The rx delay feature is coming soon and is deployed on Stage now. ETA is Monday, Jan 31st.
#582 (comment)

The rx delay feature is now deployed to Production. https://github.com/helium/router/issues/597
@Net-Metrics - Can you retest ADR with your end-device? Whether positive or negative, can you post trace logs of the packets?

The rx delay feature is now deployed to Production. #597
@Net-Metrics - Can you retest ADR with your end-device? Whether positive or negative, can you post trace logs of the packets?

Attached file shows JSON results for a downlink set to default, then 2s, 3s, 4s 5s 6s & 7s.
The most succesfull looking downlink occurred with the default Tx window, but although the downlink was immediately followed by 2 uplinks, the command was not received by my end device.

I'm trying to send a downlink to an mClimate Vicki TRV, I'm in UK, EU868. Command I'm sending is 'text' 0E15
json.txt

Have I been trying to do downlinks incorrectly? If I want to send the hex command 0E10 to my device I was entering the following in the downlink window

This shows a console calculated Base64 payload of MEUxMA==
However, if I use an online Base64 encoder and convert from 0E10 it shows a Base64 payload of DhA=
Entering this as my downlink, works fine, downlink received by my device.

Have I been doing something wrong with the Text downlink option, or is is encoding to Base64 incorrectly?

MEUxMA== is indeed the text 0E10.
Text ≈ ascii
Text != hex

MEUxMA== is indeed the text 0E10.
Text ≈ ascii Text != hex

I can see that, what I didn't understand was why there is a text option. As far as I was aware a downlink would always be either hex or base64. Is there ever a situation where you would want to download ascii?

I have seen multiple cases where people send json text strings or plain text to their devices. Doing so is extremely inefficient (in terms of radio spectrum capacity, battery consumption and payload capacity), but people still do it. I can imagine Helium wants to be "n00b-friendly" and therefore have a text option available.
For any professional use, a hex option would make much more sense.

@Net-Metrics - Examining your logs I noticed that Downlinks are stuck on FCnt 35.  In other words, the Confirmed Downlink is queued but an Ack from the end-device never confirms receipt of the packet.
Were you able to configure the rx_delay feature successfully?

Yes, the rx_delay now lets me send downlinks successfully, issue solved as far as I'm concerned.
Thanks for the help
On 18 Feb 2022 9:07 pm, Michael Vierling @.***> wrote:
@Net-Metrics https://github.com/Net-Metrics - Examining your logs I noticed that Downlinks are stuck on FCnt 35. In other words, the Confirmed Downlink is queued but an Ack from the end-device never confirms receipt of the packet.
Were you able to configure the rx_delay feature successfully?
—
Reply to this email directly, view it on GitHub https://github.com/helium/router/issues/510#issuecomment-1045191954 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATIT3ZSYMZVBXP2HWT65SJ3U32YILANCNFSM5H77CSKA .
Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .
You are receiving this because you were mentioned. https://github.com/notifications/beacon/ATIT3ZWCIHULQLZMT77OQH3U32YILA5CNFSM5H77CSKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOHZGF2EQ.gif Message ID: @.***>

Excellent!  I'll officially close this issue then.

Ideal, thanks. A hex downlink option would be a great idea, nice and simple for a quick modification, and easier for new users to get to grips with
On 18 Feb 2022 9:50 pm, Michael Vierling @.***> wrote:
I'll leaving a closing comment on Text vs Hex vs Base64. There is a misunderstanding in the comments above; data is always sent over the wire via the LoRaWAN protocol as a bit array - https://en.wikipedia.org/wiki/Bit_array https://en.wikipedia.org/wiki/Bit_array We don't ever send data as text or base64.
When binary bit data is displayed to a UI it is re-formatted into a more human readable form, e.g. usually hexadecimal, but sometimes base64 encoded. This is just a display format. The underlying bit data is just 1 and 0s.
The console allows input of data as either text or base64 which then gets encoded into bit data. I'm not sure why a Downlink hex option was not provided; that sounds useful. Hope this clarifies matters.
—
Reply to this email directly, view it on GitHub https://github.com/helium/router/issues/510#issuecomment-1045231484 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATIT3ZSHDJ7G2QPBZMY5CRLU325K7ANCNFSM5H77CSKA .
Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .
You are receiving this because you were mentioned. https://github.com/notifications/beacon/ATIT3ZXBMXGPUF3NI7NCX3LU325K7A5CNFSM5H77CSKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOHZGPO7A.gif Message ID: @.***>

authors: Net-Metrics buzzware mfalkvidd mikev nilotnas

repo: helium/router


text:
[stable/postgresql] PostGIS support

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

Version of Helm and Kubernetes:
Helm: 2.8.2
K8s: v1.10.12
Which chart:
postgresql v 3.9.1
What happened:
I've tried to enable the postgis extension by running a script at the start up as user 0 (root). This was necessary for installing packages with apt-get.
My values.yaml :
postgresql:
  securityContext:
    runAsUser: 0
  initdbScripts:
    setup_postgis_extension.sh: |
      apt-get update
      apt-get install wget gcc make build-essential libxml2-dev libgeos-dev libproj-dev libgdal-dev -y
      su - postgres
      cd /tmp
      wget "http://download.osgeo.org/postgis/source/postgis-2.4.6.tar.gz"
      export C_INCLUDE_PATH=/opt/bitnami/postgresql/include/:/opt/bitnami/common/include/
      export LIBRARY_PATH=/opt/bitnami/postgresql/lib/:/opt/bitnami/common/lib/
      export LD_LIBRARY_PATH=/opt/bitnami/postgresql/lib/:/opt/bitnami/common/lib/
      tar zxf postgis-2.4.6.tar.gz && cd postgis-2.4.6
      ./configure --with-pgconfig=/opt/bitnami/postgresql/bin/pg_config
      make
      make install

Works fine - Until the postgresql pod gets killed.
The new pod gets a Permission denied on the file postmaster.pid:
Welcome to the Bitnami postgresql container
Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-postgresql
Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-postgresql/issues
 nami    INFO  Initializing postgresql
postgre INFO  ==> No injected postgresql.conf file found. Creating default postgresql.conf file...
postgre INFO  ==> No injected pg_hba.conf file found. Creating default pg_hba.conf file...
postgre INFO  ==> Deploying PostgreSQL with persisted data...
postgre INFO  ==> Configuring PostgreSQL...
postgre INFO  ==> Configuring replication parameters...
postgre INFO  ==> Configuring permissions for config files...
postgre INFO
postgre INFO  ########################################################################
postgre INFO   Installation parameters for postgresql:
postgre INFO     Persisted data and properties have been restored.
postgre INFO     Any input specified will not take effect.
postgre INFO   This installation requires no credentials.
postgre INFO  ########################################################################
postgre INFO
nami    INFO  postgresql successfully initialized
INFO  ==> Starting postgresql...
nami    ERROR Unable to start com.bitnami.postgresql: pg_ctl: could not open PID file "/opt/bitnami/postgresql/data/postmaster.pid": Permission denied

I tried to change the permission in my setup_postgis_extension.sh script by adding things like
sudo chown -R 1001:1001 /opt/bitnami/postgresql
sudo chmod 700 /opt/bitnami/postgresql/data

with no luck.
What you expected to happen:
I expected that the pod can be restarted without any problems.
How to reproduce it (as minimally and precisely as possible):
Use the values.yaml form above and kill the pod once.
Anything else we need to know:
I use an alias in my deployment.yaml.
There is also a feature request for Postgis at the bitnami repo (https://github.com/bitnami/bitnami-docker-postgresql/issues/106)
I hope you can help me! Thank you very much in advance!

No update on this @tompizmor ?

I am afraid we couldn't work on this yet. However, we still see the value and plan to do it.
This issue has been already close by the bot but we still have the task opened in our work board.

@SDC2021 - Hi! Is your image publicly available?
Best regards
Jone

@lurajon Sry, it's not...

any news on this @tompizmor ?

Hello @SDC2021,
I am afraid that this approach is not suitable to install the postgis extension. The scripts specified using initdbScripts are only executed during the first database initialization so even if we fix the permission issue with the postmaster.pid file, the postgis extension won't be available in the new pod.
Regarding the request to include postgis in the container, we are evaluating it. At this moment we are not sure if it would be better to just include postgis in the bitnami container or create a different postgres container with postgis installed.

Hi ,
regarding " include postgis in the bitnami container "
Can you please explain how this done ?
Thanks

Regarding the request to include postgis in the container, we are evaluating it. At this moment we are not sure if it would be better to just include postgis in the bitnami container or create a different postgres container with postgis installed.

Please also consider including uuid-ossp extension as it's another popular extension.

Hello @tompizmor ,
thanks for your reply.
I already solved the problem by creating my own bitnami image with the installed postgis extension. Works fine so far!
Nevertheless, I am looking forward for your solution. It would be great to have an officially maintained postgis helm chart! 👍
Greetings
SDC2021

Hi SDC2021,
Please let me know how you solve this problem, because after creating my own image, the postgis is working fine,but as soon as we delete the pod,  we again need to install the postgis.

repo: helm/charts


text:
[stable/prometheus-operator] Cluster-autoscaler down-scaling events causes KubeNodeUnreachable alerts

Describe the bug
When a cluster autoscaling scale-down event occurs it causes a KubeNodeUnreachable alert to be fired. This is described in-depth in here: https://github.com/kubernetes-monitoring/kubernetes-mixin/issues/300 (and should be mimicked here as well)
Version of Helm and Kubernetes:
2.x, 1.14.x
Which chart:
stable/prometheus-operator
What happened:
Alert is fired in the shutdown phase of the Node
What you expected to happen:
When a node is being scaled-down an alarm isn't fired.
How to reproduce it (as minimally and precisely as possible):
Scale down your k8s cluster
Anything else we need to know:
See discussion here: https://github.com/kubernetes-monitoring/kubernetes-mixin/issues/300

Would be really wonderful to be able to have a parameter to modify this easily.

This has been fixed in the kubernetes-mixin project. I'll make a PR to update it here too. https://github.com/kubernetes-monitoring/kubernetes-mixin/pull/415

authors: AXington cablespaghetti sdavids13


text:
[stable/prometheus-operator] Add image pull secrets to prometheus operator

What this PR does / why we need it:
Add imagePullSecrets to prometheus operator deployment to allow pulling images from private repos
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

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

@vsliouniaev @bismarck @gianrubio

/assign @gianrubio

There's already an global.imagePullSecrets flag, any reason this doesn't meet your needs?

/ok-to-test
/lgtm

There's already an global.imagePullSecrets flag, any reason this doesn't meet your needs?

Hi Bismarck. I didn't see it, sorry for wasting your time, i'll close the pr.

authors: bismarck vsliouniaev worldtiki


text:
[stable/kube-state-metrics] Add variable to optionally set priorityClassName

Signed-off-by: Chris O'Brien chrisob91@gmail.com
@fiunchinho
What this PR does / why we need it:
Allow priorityClassName to be set for kube-state-metrics podSpec.
Which issue this PR fixes

fixes #9425

Checklist

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

/assign @viglesiasce

/lgtm

authors: chrisob davidkarlsen


text:
[incubator/cassandra] minor issue fixes

What this PR does / why we need it:
Fixing minor issues.
Which issue this PR fixes

fixes #9818
fixes #9819
closes #9818
closes #9819

Checklist

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

/ok-to-test

/lgtm
/approve