Security headers are not applied with Docker Backend

Do you want to request a feature or report a bug?
A bug.
What did you do?
Set up some security headers on my containers.
version: "3"

traefik:
    image: traefik:1.5-alpine
    container_name: traefik
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    labels:
      - traefik.enable=true
      - traefik.frontend.rule=Host:mail.domain.tld
      - traefik.backend.port=8080
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./certs:/certs
      - ./traefik.toml:/traefik.toml:ro

rainloop:
  image: hardware/rainloop
  container_name: rainloop
  restart: unless-stopped
  labels:
    - traefik.enable=true
    - traefik.backend.port=8888
    - traefik.frontend.rule=Host:webmail.domain.tld
    - traefik.frontend.headers.frameDeny=false
    - traefik.frontend.headers.browserXSSFilter=true
    - traefik.frontend.headers.isDevelopment=false
    - traefik.frontend.headers.STSSeconds=315360000
    - traefik.frontend.headers.forceSTSHeader=false
    - traefik.frontend.headers.contentTypeNosniff=true
  volumes:
    - /mnt/docker/rainloop:/rainloop/data
  depends_on:
    - mailserver
    - mariadb

What did you expect to see?
I expect all headers requested in the docker-compose.yml file.
What did you see instead?
# curl -I https://webmail.domain.tld/

HTTP/2 200
cache-control: no-store, no-cache, must-revalidate, max-age=0
cache-control: post-check=0, pre-check=0
content-type: text/html; charset=utf-8
date: Sat, 10 Mar 2018 17:26:28 GMT
expires: Mon, 26 Jul 1997 05:00:00 GMT
last-modified: Sat, 10 Mar 2018 17:26:28 GMT
pragma: no-cache
server: RainLoop
vary: Accept-Encoding

What version of Traefik are you using ?
# docker exec traefik traefik version

Version:      v1.5.3
Codename:     cancoillotte
Go version:   go1.9.4
Built:        2018-02-27_02:47:04PM
OS/Arch:      linux/amd64

What is your environment & configuration ?
defaultEntryPoints = ["http", "https"]
debug = true

[api]
entryPoint = "traefik"
dashboard = true

[entryPoints]
  [entryPoints.http]
  address = ":80"
    [entryPoints.http.redirect]
    entryPoint = "https"
  [entryPoints.https]
  address = ":443"
    [entryPoints.https.tls]
      [[entryPoints.https.tls.certificates]]
      certFile = "/certs/mailserver.crt"
      keyFile = "/certs/mailserver.key"
  [entryPoints.traefik]
  address = ":8080"
  [entryPoints.traefik.auth.basic]
  users = ["admin:xxxxxxxxxxxxxxx"]

[docker]
endpoint = "unix:///var/run/docker.sock"
domain = "domain.tld"
watch = true
exposedbydefault = false

# docker inspect --format "{{ index .Config.Labels }}" rainloop

map[
    traefik.enable:true
    traefik.backend.port:8888
    traefik.frontend.headers.isDevelopment:false
    traefik.frontend.rule:Host:webmail.domain.tld
    traefik.frontend.headers.forceSTSHeader:false
    traefik.frontend.headers.frameDeny:false
    traefik.frontend.headers.STSSeconds:315360000
    traefik.frontend.headers.browserXSSFilter:true
    traefik.frontend.headers.contentTypeNosniff:true
    com.docker.compose.config-hash:5f0c1a248be2d04def0ccc65ed4d5e8208dc6a7b26dc08c8f4e9669786003b64
    com.docker.compose.container-number:1
    com.docker.compose.service:rainloop
    com.docker.compose.version:1.19.0
    com.docker.compose.project:mailserver description:Rainloop is a simple, modern & fast web-based client
    com.docker.compose.oneoff:False
    maintainer=Hardware<EMAIL_ADDRESS>]

docker info
# docker info

Containers: 11
 Running: 11
 Paused: 0
 Stopped: 0
Images: 129
Server Version: 18.02.0-ce
Storage Driver: devicemapper
 Pool Name: docker-8:6-2502428-pool
 Pool Blocksize: 65.54kB
 Base Device Size: 107.4GB
 Backing Filesystem: xfs
 Udev Sync Supported: true
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 4.827GB
 Data Space Total: 107.4GB
 Data Space Available: 15.03GB
 Metadata Space Used: 6.521MB
 Metadata Space Total: 2.147GB
 Metadata Space Available: 2.141GB
 Thin Pool Minimum Free Space: 10.74GB
 Deferred Removal Enabled: true
 Deferred Deletion Enabled: true
 Deferred Deleted Device Count: 0
 Library Version: 1.02.146 (2017-12-18)
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: 9b55aab90508bd389d7654c4baf173a981477d55
runc version: 9f9c96235cc97674e935002fc3d78361b696a69e
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.15.6-1-ARCH
Operating System: Arch Linux
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 15.61GiB
Name: arch-desktop
ID: X6WJ:GS7Q:MM4B:IWXF:ECNZ:4KHJ:OWCA:47YM:HO2V:R65K:5FVW:FRGU
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: hardware
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 <IP_ADDRESS>/8
Live Restore Enabled: false

docker version
# docker version

Client:
 Version:       18.02.0-ce
 API version:   1.36
 Go version:    go1.9.4
 Git commit:    fc4de447b5
 Built: Tue Feb 13 15:28:01 2018
 OS/Arch:       linux/amd64
 Experimental:  false
 Orchestrator:  swarm

Server:
 Engine:
  Version:      18.02.0-ce
  API version:  1.36 (minimum version 1.12)
  Go version:   go1.9.4
  Git commit:   fc4de447b5
  Built:        Tue Feb 13 15:28:34 2018
  OS/Arch:      linux/amd64
  Experimental: false

If applicable, please paste the log output in debug mode (--debug switch)

logs
time="2018-03-10T17:54:23Z" level=info msg="Using TOML configuration file //traefik.toml"
time="2018-03-10T17:54:23Z" level=info msg="Traefik version v1.5.3 built on 2018-02-27_02:47:04PM"
time="2018-03-10T17:54:23Z" level=info msg="
Stats collection is disabled.
 Using default method wrr."
time="2018-03-10T17:54:23Z" level=debug msg="Validation of load balancer method for backend backend-traefik-traefik-mailserver-backend failed: invalid load-balancing method ''. Using default method wrr."
time="2018-03-10T17:54:23Z" level=debug msg="Validation of load balancer method for backend backend-adminer-adminer-mailserver-backend failed: invalid load-balancing method ''. Using default method wrr."
time="2018-03-10T17:54:23Z" level=debug msg="Validation of load balancer method for backend backend-flarum-flarum-mailserver-backend failed: invalid load-balancing method ''. Using default method wrr."
time="2018-03-10T17:54:23Z" level=debug msg="Validation of load balancer method for backend backend-mailserver-mailserver-mailserver-backend failed: invalid load-balancing method ''. Using default method wrr."
time="2018-03-10T17:54:23Z" level=debug msg="Validation of load balancer method for backend backend-postfixadmin-postfixadmin-mailserver-backend failed: invalid load-balancing method ''. Using default method wrr."
time="2018-03-10T17:54:23Z" level=debug msg="Validation of load balancer method for backend backend-rainloop-rainloop-mailserver-backend failed: invalid load-balancing method ''. Using default method wrr."
time="2018-03-10T17:54:23Z" level=debug msg="Configuration received from provider docker: {"backends":{"backend-adminer-adminer-mailserver-backend":{"servers":{"service-0":{"url":"http://<IP_ADDRESS>:8888","weight":0}},"loadBalancer":{"method":"wrr"}},"backend-flarum-flarum-mailserver-backend":{"servers":{"service-0":{"url":"http://<IP_ADDRESS>:8888","weight":0}},"loadBalancer":{"method":"wrr"}},"backend-mailserver-mailserver-mailserver-backend":{"servers":{"service-0":{"url":"http://<IP_ADDRESS>:11334","weight":0}},"loadBalancer":{"method":"wrr"}},"backend-postfixadmin-postfixadmin-mailserver-backend":{"servers":{"service-0":{"url":"http://<IP_ADDRESS>:8888","weight":0}},"loadBalancer":{"method":"wrr"}},"backend-rainloop-rainloop-mailserver-backend":{"servers":{"service-0":{"url":"http://<IP_ADDRESS>:8888","weight":0}},"loadBalancer":{"method":"wrr"}},"backend-selfoss-selfoss-mailserver-backend":{"servers":{"service-0":{"url":"http://<IP_ADDRESS>:8888","weight":0}},"loadBalancer":{"method":"wrr"}},"backend-traefik-traefik-mailserver-backend":{"servers":{"service-0":{"url":"http://<IP_ADDRESS>:8080","weight":0}},"loadBalancer":{"method":"wrr"}}},"frontends":{"frontend-adminer-adminer-mailserver-backend":{"entryPoints":["http","https"],"backend":"backend-adminer-adminer-mailserver-backend","routes":{"service-backend":{"rule":"Host:adminer.domain.tld"}},"passHostHeader":true,"priority":0,"basicAuth":[]},"frontend-flarum-flarum-mailserver-backend":{"entryPoints":["http","https"],"backend":"backend-flarum-flarum-mailserver-backend","routes":{"service-backend":{"rule":"Host:flarum.domain.tld"}},"passHostHeader":true,"priority":0,"basicAuth":[]},"frontend-mailserver-mailserver-mailserver-backend":{"entryPoints":["http","https"],"backend":"backend-mailserver-mailserver-mailserver-backend","routes":{"service-backend":{"rule":"Host:spam.domain.tld"}},"passHostHeader":true,"priority":0,"basicAuth":[]},"frontend-postfixadmin-postfixadmin-mailserver-backend":{"entryPoints":["http","https"],"backend":"backend-postfixadmin-postfixadmin-mailserver-backend","routes":{"service-backend":{"rule":"Host:postfixadmin.domain.tld"}},"passHostHeader":true,"priority":0,"basicAuth":[]},"frontend-rainloop-rainloop-mailserver-backend":{"entryPoints":["http","https"],"backend":"backend-rainloop-rainloop-mailserver-backend","routes":{"service-backend":{"rule":"Host:webmail.domain.tld"}},"passHostHeader":true,"priority":0,"basicAuth":[]},"frontend-selfoss-selfoss-mailserver-backend":{"entryPoints":["http","https"],"backend":"backend-selfoss-selfoss-mailserver-backend","routes":{"service-backend":{"rule":"Host:selfoss.domain.tld"}},"passHostHeader":true,"priority":0,"basicAuth":[]},"frontend-traefik-traefik-mailserver-backend":{"entryPoints":["http","https"],"backend":"backend-traefik-traefik-mailserver-backend","routes":{"service-backend":{"rule":"Host:mail.domain.tld"}},"passHostHeader":true,"priority":0,"basicAuth":[]}}}"
time="2018-03-10T17:54:23Z" level=debug msg="Creating frontend frontend-adminer-adminer-mailserver-backend"
time="2018-03-10T17:54:23Z" level=debug msg="Wiring frontend frontend-adminer-adminer-mailserver-backend to entryPoint http"
time="2018-03-10T17:54:23Z" level=debug msg="Creating route service-backend Host:adminer.domain.tld"
time="2018-03-10T17:54:23Z" level=debug msg="Creating entryPoint redirect http -> https : ^(?:https?:\/\/)?([\w\._-]+)(?::\d+)?(.*)$ -> https://${1}:443${2}"
time="2018-03-10T17:54:23Z" level=debug msg="Creating backend backend-adminer-adminer-mailserver-backend"
time="2018-03-10T17:54:23Z" level=debug msg="Creating load-balancer wrr"
time="2018-03-10T17:54:23Z" level=debug msg="Creating server service-0 at http://<IP_ADDRESS>:8888 with weight 0"
time="2018-03-10T17:54:23Z" level=debug msg="Wiring frontend frontend-adminer-adminer-mailserver-backend to entryPoint https"
time="2018-03-10T17:54:23Z" level=debug msg="Creating route service-backend Host:adminer.domain.tld"
time="2018-03-10T17:54:23Z" level=debug msg="Creating backend backend-adminer-adminer-mailserver-backend"
time="2018-03-10T17:54:23Z" level=debug msg="Creating load-balancer wrr"
time="2018-03-10T17:54:23Z" level=debug msg="Creating server service-0 at http://<IP_ADDRESS>:8888 with weight 0"
time="2018-03-10T17:54:23Z" level=debug msg="Creating frontend frontend-flarum-flarum-mailserver-backend"
time="2018-03-10T17:54:23Z" level=debug msg="Wiring frontend frontend-flarum-flarum-mailserver-backend to entryPoint http"
time="2018-03-10T17:54:23Z" level=debug msg="Creating route service-backend Host:flarum.domain.tld"
time="2018-03-10T17:54:23Z" level=debug msg="Creating backend backend-flarum-flarum-mailserver-backend"
time="2018-03-10T17:54:23Z" level=debug msg="Creating load-balancer wrr"
time="2018-03-10T17:54:23Z" level=debug msg="Creating server service-0 at http://<IP_ADDRESS>:8888 with weight 0"
time="2018-03-10T17:54:23Z" level=debug msg="Wiring frontend frontend-flarum-flarum-mailserver-backend to entryPoint https"
time="2018-03-10T17:54:23Z" level=debug msg="Creating route service-backend Host:flarum.domain.tld"
time="2018-03-10T17:54:23Z" level=debug msg="Creating backend backend-flarum-flarum-mailserver-backend"
time="2018-03-10T17:54:23Z" level=debug msg="Creating load-balancer wrr"
time="2018-03-10T17:54:23Z" level=debug msg="Creating server service-0 at http://<IP_ADDRESS>:8888 with weight 0"
time="2018-03-10T17:54:23Z" level=debug msg="Creating frontend frontend-mailserver-mailserver-mailserver-backend"
time="2018-03-10T17:54:23Z" level=debug msg="Wiring frontend frontend-mailserver-mailserver-mailserver-backend to entryPoint http"
time="2018-03-10T17:54:23Z" level=debug msg="Creating route service-backend Host:spam.domain.tld"
time="2018-03-10T17:54:23Z" level=debug msg="Creating backend backend-mailserver-mailserver-mailserver-backend"
time="2018-03-10T17:54:23Z" level=debug msg="Creating load-balancer wrr"
time="2018-03-10T17:54:23Z" level=debug msg="Creating server service-0 at http://<IP_ADDRESS>:11334 with weight 0"
time="2018-03-10T17:54:23Z" level=debug msg="Wiring frontend frontend-mailserver-mailserver-mailserver-backend to entryPoint https"
time="2018-03-10T17:54:23Z" level=debug msg="Creating route service-backend Host:spam.domain.tld"
time="2018-03-10T17:54:23Z" level=debug msg="Creating backend backend-mailserver-mailserver-mailserver-backend"
time="2018-03-10T17:54:23Z" level=debug msg="Creating load-balancer wrr"
time="2018-03-10T17:54:23Z" level=debug msg="Creating server service-0 at http://<IP_ADDRESS>:11334 with weight 0"
time="2018-03-10T17:54:23Z" level=debug msg="Creating frontend frontend-postfixadmin-postfixadmin-mailserver-backend"
time="2018-03-10T17:54:23Z" level=debug msg="Wiring frontend frontend-postfixadmin-postfixadmin-mailserver-backend to entryPoint http"
time="2018-03-10T17:54:23Z" level=debug msg="Creating route service-backend Host:postfixadmin.domain.tld"
time="2018-03-10T17:54:23Z" level=debug msg="Creating backend backend-postfixadmin-postfixadmin-mailserver-backend"
time="2018-03-10T17:54:23Z" level=debug msg="Creating load-balancer wrr"
time="2018-03-10T17:54:23Z" level=debug msg="Creating server service-0 at http://<IP_ADDRESS>:8888 with weight 0"
time="2018-03-10T17:54:23Z" level=debug msg="Wiring frontend frontend-postfixadmin-postfixadmin-mailserver-backend to entryPoint https"
time="2018-03-10T17:54:23Z" level=debug msg="Creating route service-backend Host:postfixadmin.domain.tld"
time="2018-03-10T17:54:23Z" level=debug msg="Creating backend backend-postfixadmin-postfixadmin-mailserver-backend"
time="2018-03-10T17:54:23Z" level=debug msg="Creating load-balancer wrr"
time="2018-03-10T17:54:23Z" level=debug msg="Creating server service-0 at http://<IP_ADDRESS>:8888 with weight 0"
time="2018-03-10T17:54:23Z" level=debug msg="Creating frontend frontend-rainloop-rainloop-mailserver-backend"
time="2018-03-10T17:54:23Z" level=debug msg="Wiring frontend frontend-rainloop-rainloop-mailserver-backend to entryPoint http"
time="2018-03-10T17:54:23Z" level=debug msg="Creating route service-backend Host:webmail.domain.tld"
time="2018-03-10T17:54:23Z" level=debug msg="Creating backend backend-rainloop-rainloop-mailserver-backend"
time="2018-03-10T17:54:23Z" level=debug msg="Creating load-balancer wrr"
time="2018-03-10T17:54:23Z" level=debug msg="Creating server service-0 at http://<IP_ADDRESS>:8888 with weight 0"
time="2018-03-10T17:54:23Z" level=debug msg="Wiring frontend frontend-rainloop-rainloop-mailserver-backend to entryPoint https"
time="2018-03-10T17:54:23Z" level=debug msg="Creating route service-backend Host:webmail.domain.tld"
time="2018-03-10T17:54:23Z" level=debug msg="Creating backend backend-rainloop-rainloop-mailserver-backend"
time="2018-03-10T17:54:23Z" level=debug msg="Creating load-balancer wrr"
time="2018-03-10T17:54:23Z" level=debug msg="Creating server service-0 at http://<IP_ADDRESS>:8888 with weight 0"
time="2018-03-10T17:54:23Z" level=debug msg="Creating frontend frontend-selfoss-selfoss-mailserver-backend"
time="2018-03-10T17:54:23Z" level=debug msg="Wiring frontend frontend-selfoss-selfoss-mailserver-backend to entryPoint http"
time="2018-03-10T17:54:23Z" level=debug msg="Creating route service-backend Host:selfoss.domain.tld"
time="2018-03-10T17:54:23Z" level=debug msg="Creating backend backend-selfoss-selfoss-mailserver-backend"
time="2018-03-10T17:54:23Z" level=debug msg="Creating load-balancer wrr"
time="2018-03-10T17:54:23Z" level=debug msg="Creating server service-0 at http://<IP_ADDRESS>:8888 with weight 0"
time="2018-03-10T17:54:23Z" level=debug msg="Wiring frontend frontend-selfoss-selfoss-mailserver-backend to entryPoint https"
time="2018-03-10T17:54:23Z" level=debug msg="Creating route service-backend Host:selfoss.domain.tld"
time="2018-03-10T17:54:23Z" level=debug msg="Creating backend backend-selfoss-selfoss-mailserver-backend"
time="2018-03-10T17:54:23Z" level=debug msg="Creating load-balancer wrr"
time="2018-03-10T17:54:23Z" level=debug msg="Creating server service-0 at http://<IP_ADDRESS>:8888 with weight 0"
time="2018-03-10T17:54:23Z" level=debug msg="Creating frontend frontend-traefik-traefik-mailserver-backend"
time="2018-03-10T17:54:23Z" level=debug msg="Wiring frontend frontend-traefik-traefik-mailserver-backend to entryPoint http"
time="2018-03-10T17:54:23Z" level=debug msg="Creating route service-backend Host:mail.domain.tld"
time="2018-03-10T17:54:23Z" level=debug msg="Creating backend backend-traefik-traefik-mailserver-backend"
time="2018-03-10T17:54:23Z" level=debug msg="Creating load-balancer wrr"
time="2018-03-10T17:54:23Z" level=debug msg="Creating server service-0 at http://<IP_ADDRESS>:8080 with weight 0"
time="2018-03-10T17:54:23Z" level=debug msg="Wiring frontend frontend-traefik-traefik-mailserver-backend to entryPoint https"
time="2018-03-10T17:54:23Z" level=debug msg="Creating route service-backend Host:mail.domain.tld"
time="2018-03-10T17:54:23Z" level=debug msg="Creating backend backend-traefik-traefik-mailserver-backend"
time="2018-03-10T17:54:23Z" level=debug msg="Creating load-balancer wrr"
time="2018-03-10T17:54:23Z" level=debug msg="Creating server service-0 at http://<IP_ADDRESS>:8080 with weight 0"
time="2018-03-10T17:54:23Z" level=info msg="Server configuration reloaded on :80"
time="2018-03-10T17:54:23Z" level=info msg="Server configuration reloaded on :443"
time="2018-03-10T17:54:23Z" level=info msg="Server configuration reloaded on :8080"
time="2018-03-10T17:54:24Z" level=debug msg="Provider event received {Status:health_status: healthy ID:caee2ef98b18b1ad5de5da30b00bcb8d1e08f89899db2ba2f2c827d53a0a8a70 From:willfarrell/autoheal Type:container Action:health_status: healthy Actor:{ID:caee2ef98b18b1ad5de5da30b00bcb8d1e08f89899db2ba2f2c827d53a0a8a70 Attributes:map[name:autoheal com.docker.compose.config-hash:59adb2bae5cd5d5836df5ef403c7b9da274163affb71396c72564d8b9a3dce35 com.docker.compose.container-number:1 com.docker.compose.oneoff:False com.docker.compose.project:mailserver com.docker.compose.service:autoheal com.docker.compose.version:1.19.0 image:willfarrell/autoheal]} Scope:local Time:1520704464 TimeNano:1520704464357940999}"
time="2018-03-10T17:54:24Z" level=debug msg="Filtering disabled container /mariadb"
time="2018-03-10T17:54:24Z" level=debug msg="Filtering disabled container /mariadb-flarum"
time="2018-03-10T17:54:24Z" level=debug msg="Filtering disabled container /redis"
time="2018-03-10T17:54:24Z" level=debug msg="Filtering disabled container /autoheal"
time="2018-03-10T17:54:24Z" level=debug msg="Could not load traefik.frontend.whitelistSourceRange labels"
time="2018-03-10T17:54:24Z" level=debug msg="Could not load traefik.frontend.entryPoints labels"
time="2018-03-10T17:54:24Z" level=debug msg="Could not load traefik.frontend.auth.basic labels"
time="2018-03-10T17:54:24Z" level=debug msg="Could not load traefik.frontend.whitelistSourceRange labels"
time="2018-03-10T17:54:24Z" level=debug msg="Could not load traefik.frontend.entryPoints labels"
time="2018-03-10T17:54:24Z" level=debug msg="Could not load traefik.frontend.auth.basic labels"
time="2018-03-10T17:54:24Z" level=debug msg="Could not load traefik.frontend.whitelistSourceRange labels"
time="2018-03-10T17:54:24Z" level=debug msg="Could not load traefik.frontend.entryPoints labels"
time="2018-03-10T17:54:24Z" level=debug msg="Could not load traefik.frontend.auth.basic labels"
time="2018-03-10T17:54:24Z" level=debug msg="Could not load traefik.frontend.whitelistSourceRange labels"
time="2018-03-10T17:54:24Z" level=debug msg="Could not load traefik.frontend.entryPoints labels"
time="2018-03-10T17:54:24Z" level=debug msg="Could not load traefik.frontend.auth.basic labels"
time="2018-03-10T17:54:24Z" level=debug msg="Could not load traefik.frontend.whitelistSourceRange labels"
time="2018-03-10T17:54:24Z" level=debug msg="Could not load traefik.frontend.entryPoints labels"
time="2018-03-10T17:54:24Z" level=debug msg="Could not load traefik.frontend.auth.basic labels"
time="2018-03-10T17:54:24Z" level=debug msg="Could not load traefik.frontend.whitelistSourceRange labels"
time="2018-03-10T17:54:24Z" level=debug msg="Could not load traefik.frontend.entryPoints labels"
time="2018-03-10T17:54:24Z" level=debug msg="Could not load traefik.frontend.auth.basic labels"
time="2018-03-10T17:54:24Z" level=debug msg="Could not load traefik.frontend.whitelistSourceRange labels"
time="2018-03-10T17:54:24Z" level=debug msg="Could not load traefik.frontend.entryPoints labels"
time="2018-03-10T17:54:24Z" level=debug msg="Could not load traefik.frontend.auth.basic labels"
time="2018-03-10T17:54:24Z" level=debug msg="Validation of load balancer method for backend backend-traefik-traefik-mailserver-backend failed: invalid load-balancing method ''. Using default method wrr."
time="2018-03-10T17:54:24Z" level=debug msg="Validation of load balancer method for backend backend-adminer-adminer-mailserver-backend failed: invalid load-balancing method ''. Using default method wrr."
time="2018-03-10T17:54:24Z" level=debug msg="Validation of load balancer method for backend backend-flarum-flarum-mailserver-backend failed: invalid load-balancing method ''. Using default method wrr."
time="2018-03-10T17:54:24Z" level=debug msg="Validation of load balancer method for backend backend-mailserver-mailserver-mailserver-backend failed: invalid load-balancing method ''. Using default method wrr."
time="2018-03-10T17:54:24Z" level=debug msg="Validation of load balancer method for backend backend-postfixadmin-postfixadmin-mailserver-backend failed: invalid load-balancing method ''. Using default method wrr."
time="2018-03-10T17:54:24Z" level=debug msg="Validation of load balancer method for backend backend-rainloop-rainloop-mailserver-backend failed: invalid load-balancing method ''. Using default method wrr."
time="2018-03-10T17:54:24Z" level=debug msg="Validation of load balancer method for backend backend-selfoss-selfoss-mailserver-backend failed: invalid load-balancing method ''. Using default method wrr."
time="2018-03-10T17:54:24Z" level=debug msg="Configuration received from provider docker: {"backends":{"backend-adminer-adminer-mailserver-backend":{"servers":{"service-0":{"url":"http://<IP_ADDRESS>:8888","weight":0}},"loadBalancer":{"method":"wrr"}},"backend-flarum-flarum-mailserver-backend":{"servers":{"service-0":{"url":"http://<IP_ADDRESS>:8888","weight":0}},"loadBalancer":{"method":"wrr"}},"backend-mailserver-mailserver-mailserver-backend":{"servers":{"service-0":{"url":"http://<IP_ADDRESS>:11334","weight":0}},"loadBalancer":{"method":"wrr"}},"backend-postfixadmin-postfixadmin-mailserver-backend":{"servers":{"service-0":{"url":"http://<IP_ADDRESS>:8888","weight":0}},"loadBalancer":{"method":"wrr"}},"backend-rainloop-rainloop-mailserver-backend":{"servers":{"service-0":{"url":"http://<IP_ADDRESS>:8888","weight":0}},"loadBalancer":{"method":"wrr"}},"backend-selfoss-selfoss-mailserver-backend":{"servers":{"service-0":{"url":"http://<IP_ADDRESS>:8888","weight":0}},"loadBalancer":{"method":"wrr"}},"backend-traefik-traefik-mailserver-backend":{"servers":{"service-0":{"url":"http://<IP_ADDRESS>:8080","weight":0}},"loadBalancer":{"method":"wrr"}}},"frontends":{"frontend-adminer-adminer-mailserver-backend":{"entryPoints":["http","https"],"backend":"backend-adminer-adminer-mailserver-backend","routes":{"service-backend":{"rule":"Host:adminer.domain.tld"}},"passHostHeader":true,"priority":0,"basicAuth":[]},"frontend-flarum-flarum-mailserver-backend":{"entryPoints":["http","https"],"backend":"backend-flarum-flarum-mailserver-backend","routes":{"service-backend":{"rule":"Host:flarum.domain.tld"}},"passHostHeader":true,"priority":0,"basicAuth":[]},"frontend-mailserver-mailserver-mailserver-backend":{"entryPoints":["http","https"],"backend":"backend-mailserver-mailserver-mailserver-backend","routes":{"service-backend":{"rule":"Host:spam.domain.tld"}},"passHostHeader":true,"priority":0,"basicAuth":[]},"frontend-postfixadmin-postfixadmin-mailserver-backend":{"entryPoints":["http","https"],"backend":"backend-postfixadmin-postfixadmin-mailserver-backend","routes":{"service-backend":{"rule":"Host:postfixadmin.domain.tld"}},"passHostHeader":true,"priority":0,"basicAuth":[]},"frontend-rainloop-rainloop-mailserver-backend":{"entryPoints":["http","https"],"backend":"backend-rainloop-rainloop-mailserver-backend","routes":{"service-backend":{"rule":"Host:webmail.domain.tld"}},"passHostHeader":true,"priority":0,"basicAuth":[]},"frontend-selfoss-selfoss-mailserver-backend":{"entryPoints":["http","https"],"backend":"backend-selfoss-selfoss-mailserver-backend","routes":{"service-backend":{"rule":"Host:selfoss.domain.tld"}},"passHostHeader":true,"priority":0,"basicAuth":[]},"frontend-traefik-traefik-mailserver-backend":{"entryPoints":["http","https"],"backend":"backend-traefik-traefik-mailserver-backend","routes":{"service-backend":{"rule":"Host:mail.domain.tld"}},"passHostHeader":true,"priority":0,"basicAuth":[]}}}"
time="2018-03-10T17:54:24Z" level=info msg="Skipping same configuration for provider docker"

Hi and thanks for taking the time to report an issue :-)
Your problem is a bit tricky and is not (per se) a bug (though it would have worked in the next version -- I won't dive into the details here).
TL;DR
change
traefik.backend.port=8888

to
traefik.port=8888

The label traefik.port is the correct option to define the port Træfik uses on your container (you can refer to the Traefik's documentation on labels and containers to see the full list of available options).
More details
The syntax you used (traefik.backend.port=8888) tells Træfik to create a "service" named backend which port is 8888. This syntax is useful when you need Træfik to deal with containers that expose multiple ports. You can refer to the Traefik's documentation for more information about Traefik and service labels, and read the list of available options for services in Traefik's documentation on labels and services.
Feel free to join our Slack workspace for more community #support.
Enjoy Træfik!


A little issue about RPN box loss

I wonder why u calculate the RPN class loss just use 256 example bboxes with 1:1（pos : neg）
But for bbox loss, u consider all the bbox that generated by def generate_anchors_pre? why don't u choose the same 256 example boxes like RPN class loss?
thx for your reply!
@ruotianluo

https://github.com/ruotianluo/pytorch-faster-rcnn/blob/master/lib/layer_utils/anchor_target_layer.py#L109
Because apparently we want to have more training data; however the positive and negative are still balanced.


[CAPI] Add ml_train_layer_set_property_with_single_param() internally

… for C# DllImport
ml_train_layer_set_property() has va_list and this is a problem with DllImport in C#.
va_list must be passed dynamically for each architect, this is not guaranteed to
work for some architects. This api receive layer property param as a single string
from C# DllImport.
Self evaluation:

Build test:   [X]Passed [ ]Failed [ ]Skipped
Run test:     [X]Passed [ ]Failed [ ]Skipped

Signed-off-by: Hyunil<EMAIL_ADDRESS>

:memo: TAOS-CI Version: 1.5.20200925. Thank you for submitting PR #1929. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://ci.nnstreamer.ai/.

How about remove the ... in the commit message?


Dependency update

Please, merge this PR.
It's fix security issue.

Can Any body fix the deprecated package issue.

This is not really a security issue as it's only the devDependencies and the code wasn't adopted to the new standard convention in here.
It needs some more work and an official breaking change (var -> const -> drop older node versions).


how do you use programatically precompiled templates with helpers in them?

i'm precompiling using the handlebars/handlebars.runtime's Handlebars.precompile()
and helpers aren't being called

Closing this out as there is nothing actionable here. Glad to reopen if you post a fiddle (see CONTRIBUTING.md for link to template) or other reduced test case that demonstrates the issue that you're having.

ah yeah, i figured it out. thanks!

Generally it's best to include specific details when making open source issue request and updating if you found the solution. This prevents the maintainers from wasting their time.

Gotcha, thanks for the tips


Fdai/add scala profile 2.12

What is this PR for?
Add scala 2.12 support for interpreters
What type of PR is it?
[Improvement]
Todos

[ ] - Task

What is the Jira issue?
https://issues.apache.org/jira/browse/ZEPPELIN-4582
How should this be tested?
Passed CI https://travis-ci.org/fred521/zeppelin
Screenshots (if appropriate)
Questions:

Does the licenses files need update?
Is there breaking changes for older versions?
Does this needs documentation?

@fred521 This PR is pretty big, could you elaborate what this PR do ?

sorry, my bad, I will cancel this.


No more connection can be made to this remote computer

followed article exactly, but getting error on vpn client "No more connection can be made to this remote computer at this time because there are already as many connections as the computer can accept."
adjusting "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\cachedlogonscount" doesnt help.

@wchucgf
Thanks for your feedback! We will investigate and update as appropriate.


Abort() at AGProxySession.cpp:585

Sentry link: https://sentry.adguard.com/adg/adguard-android-rs/issues/30263/

core/pull-requests/1407
no need to test


how to know that audio played finished using send_audio

I have following sequence:

Caller calls a number (inbound call)
it is answered
we have another api from where we get the text and convert it to speech and then give that audio to play in call using client.send_audio
So our api may send End call command and a sentence , so if i receive that i need to first play the audio (Converted from that sentence(text) to speech and give it client.send_audio) and then end the call (hangup)
so in above, how can we know that audio is finished playing so that i can then End the call. currenly what happend that i do get a response from play_audio as stream started but i don't have any status whether audio is finished playing

following is my piece of code:
def on_final_result(self, text):
                if len(api_response["data"]["system_output"])>0:
                    text_to_speech = api_response["data"]["system_output"] # Receive sentence to speak from my api
                    file_url = self.pollyaudio(text_to_speech) # this will convert text to speech using polly
                    response = client.send_audio(os.environ['uuid'], stream_url=[file_url])
                    if response is not None:
                        time.sleep(10) # i am trying this but it is not working as expected

                command = api_response["data"]["commands"][0]
                # End of call command
                if command is not None and command['name'] == 'EOC':
                    client.update_call(os.environ['uuid'], action='hangup')

( see also similar/related issue https://github.com/Nexmo/nexmo-python/issues/125 )

@lornajane It is also open by me. :)

The previous issue that was opened was resolved. I will close this one too.


Subscription filtering

The engine currently (as of PR #11) provides the ability to subscribe for an event type.  However, do we need finer grained subscriptions?
For example, imagine the component controlling a bottle of water.  It wants to subscribe for when it is consumed; the current structure would only allow for it to subscribe for when anything or at best any drink is consumed.
This might be a non-issue if the same component is responsible for handling the consumption of any drink, but if the components are finer grained, do we need the ability to predicate the events?

I can't think of this being an issue at the moment. When we have something that breaks this, we can reevaluate


Config Flow could not be loaded

Version of the custom_component  1.40
Configuration
configuration.yaml
Configure a default setup of Home Assistant (frontend, api, etc)
default_config:
Text to speech
tts:

platform: google_translate

group: !include groups.yaml
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
light:

platform: group
name: LivingRoomLights
unique_id: lrlights
entities:

light.yeelight_color4_0x12ae47c8
light.yeelight_color4_0x10e32144
light.yeelight_color4_0x1259264d
light.yeelight_color4_0x12ae70d7

platform: group
name: OrangeryLights
unique_id: olights
entities:

light.yeelight_colorc_0x1b184cf0
light.yeelight_colorc_0x1b3e31bb
light.yeelight_colorc_0x1b3dc755
light.yeelight_colorc_0x1b3d6613
light.yeelight_colorc_0x1b3d7cde
light.yeelight_colorc_0x1b3d9704
light.yeelight_colorc_0x1b3da686
light.yeelight_colorc_0x1b3db7c5
light.yeelight_colorc_0x1b3ddd78
light.yeelight_colorc_0x1b3e0959
light.yeelight_colorc_0x1b3e26d7

platform: group
name: OutsideLights
unique_id: outlights
entities:

light.yeelight_colora_0xea6ebe8
light.yeelight_colora_0xe9f955a
light.yeelight_colora_0xe9f5daf
light.yeelight_colora_0xeda43e2
light.yeelight_colora_0xed80d98
light.yeelight_colora_0xeda93dc
light.yeelight_colora_0xeda9014
light.yeelight_colora_0xeda8913
light.yeelight_colora_0xe9f6023
light.yeelight_colora_0xeda81a6
light.yeelight_colora_0xe3e7e19
light.yeelight_colora_0xedaf8e1
light.yeelight_colora_0xeda511c
light.yeelight_colora_0xea6837a
light.yeelight_colora_0xea7b0ca
light.yeelight_colora_0xe9f9486
light.yeelight_colora_0xe9f83e1
light.yeelight_colora_0xe9f9012
light.yeelight_colora_0xeda8ada
light.yeelight_colora_0xe3e84fb
light.yeelight_colora_0xeda9023
light.yeelight_colora_0xed804ef
light.yeelight_colora_0xed807da

influxdb:
host: a0d7b954-influxdb
port: 8086
database: HomeAssistant
username: homeassistant
password: apasswordishere
max_retries: 3
default_measurement: state
Describe the bug
An inability to install the component. Following the instructions
Debug log

2021-12-15 11:47:35 ERROR (SyncWorker_0) [homeassistant.loader] The custom integration 'tesla_cc' does not have a version key in the manifest file and was blocked from loading. See https://developers.home-assistant.io/blog/2021/01/29/custom-integration-changes#versions for more details

Sorry, my bad - getting 2 software repos confused !


"Please match the requested format"?

Installed "Send To Kindle" on Firefox 105.0.1 (64-bit). Added my kindle to "Send to Address" and selected<EMAIL_ADDRESS>Copied and pasted (Ctrl-C, Ctrl-V) a 320-page .pdf to "Paste content here" and selected "Send." Got "Please match the requested format." Tried again with same document, but from .docx source with same result. What does "Please match the requested format" mean? How do I fix this?

This site cannot be used to send entire files directly.
To send a pdf file, please use https://www.amazon.com/sendtokindle/email


Add: MITMediaLab.Scratch.3 version 3.24.0

[ ] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.0 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Different scopes do not seem possible.

The bot is having a bad day/week, hopefully they fix it before the weekend


setValue does not check min/max

Currently, I have the following observation:
VSS Client> getMetaData Vehicle.Speed
{
    "action": "getMetaData",
    "metadata": {
        "Vehicle": {
            "children": {
                "Speed": {
                    "datatype": "int32",
                    "description": "Vehicle speed, as sensed by the gearbox.",
                    "max": 250,
                    "min": -250,
                    "type": "sensor",
                    "unit": "km/h",
                    "uuid": "1efc9a11943b5a15ac159786051c5836"
                }
            },
            "description": "High-level vehicle data.",
            "type": "branch",
            "uuid": "1c72453e738511e9b29ad46a6a4b77e9"
        }
    },
    "requestId": "1236",
    "timestamp":<PHONE_NUMBER>
}
VSS Client> setValue Vehicle.Speed 366
{
    "action": "set",
    "requestId": "1235",
    "timestamp":<PHONE_NUMBER>
}
VSS Client> getValue Vehicle.Speed
{
    "action": "get",
    "path": "Vehicle.Speed",
    "requestId": "1234",
    "timestamp":<PHONE_NUMBER>,
    "value": "366"
}

But I do not expect the setValue  Vehicle.Speed 366 can be successful, because the defined max value is 250.

The observation is correct, currently the min, max are ignored. I am not sure what we want here in the short term, as not all limit(as in speed) in the core data model make sense. If it is a "general" limitation for all land vehicles it shoudl be more like 600, but how useful it is? Mire useful would be the max of the current vehicle, but that would be a matter of a concrete deployment of the data model.
We might track what Genivi is doing here, a related discussion is https://github.com/GENIVI/vehicle_signal_specification/issues/166
But let's keep this open, because we should do "something" with min/max eventually


Table Functionality

Properly insert golf course objects to table for functionality

Functionality exists and can load course objects easily into the table. setvoid in maincontroller gives good example of this! its dead code that is there to be expanded upon once I finish API functionality


convert_model.mnist_eg.tf errors, possibly due to different TF versions

> python3 --version
Python 3.11.8
> pip list | grep tensorflow
tensorflow                   2.16.1

I encountered errors executing python3 -m convert_model.mnist_eg.tf. Since the version of  tensorflow is unspecified in convert_model/requirements.txt, perhaps tensorflow works differently in my version. (The version of coremltools is also unspecified, which might also be problematic)
2024-04-17 15:25:44.036395: I external/local_tsl/tsl/cuda/cudart_stub.cc:32] Could not find cuda drivers on your machine, GPU will not be used.
2024-04-17 15:25:44.040311: I external/local_tsl/tsl/cuda/cudart_stub.cc:32] Could not find cuda drivers on your machine, GPU will not be used.
2024-04-17 15:25:44.091677: I tensorflow/core/platform/cpu_feature_guard.cc:210] This TensorFlow binary is optimized to use available CPU instructions in performance-critical operations.
To enable the following instructions: AVX2 FMA, in other operations, rebuild TensorFlow with the appropriate compiler flags.
2024-04-17 15:25:46.018733: W tensorflow/compiler/tf2tensorrt/utils/py_utils.cc:38] TF-TRT Warning: Could not find TensorRT
2024-04-17 15:25:47.542628: I external/local_xla/xla/stream_executor/cuda/cuda_executor.cc:998] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero. See more at https://github.com/torvalds/linux/blob/v6.0/Documentation/ABI/testing/sysfs-bus-pci#L344-L355
2024-04-17 15:25:47.544149: W tensorflow/core/common_runtime/gpu/gpu_device.cc:2251] Cannot dlopen some GPU libraries. Please make sure the missing libraries mentioned above are installed properly if you would like to use GPU. Follow the guide at https://www.tensorflow.org/install/gpu for how to download and setup the required libraries for your platform.
Skipping registering GPU devices...
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/data/dku/fedcampus/FedKit/convert_model/mnist_eg/tf.py", line 32, in <module>
    tflite()
  File "/data/dku/fedcampus/FedKit/convert_model/mnist_eg/tf.py", line 25, in tflite
    save_model(model, SAVED_MODEL_DIR)
  File "/data/dku/fedcampus/FedKit/convert_model/tflite.py", line 66, in save_model
    parameters = model.parameters.get_concrete_function()
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/dku/fedcampus/FedKit/backend/.venv/lib/python3.11/site-packages/tensorflow/python/eager/polymorphic_function/polymorphic_function.py", line 1251, in get_concrete_function
    concrete = self._get_concrete_function_garbage_collected(*args, **kwargs)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/dku/fedcampus/FedKit/backend/.venv/lib/python3.11/site-packages/tensorflow/python/eager/polymorphic_function/polymorphic_function.py", line 1221, in _get_concrete_function_garbage_collected
    self._initialize(args, kwargs, add_initializers_to=initializers)
  File "/data/dku/fedcampus/FedKit/backend/.venv/lib/python3.11/site-packages/tensorflow/python/eager/polymorphic_function/polymorphic_function.py", line 696, in _initialize
    self._concrete_variable_creation_fn = tracing_compilation.trace_function(
                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/dku/fedcampus/FedKit/backend/.venv/lib/python3.11/site-packages/tensorflow/python/eager/polymorphic_function/tracing_compilation.py", line 178, in trace_function
    concrete_function = _maybe_define_function(
                        ^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/dku/fedcampus/FedKit/backend/.venv/lib/python3.11/site-packages/tensorflow/python/eager/polymorphic_function/tracing_compilation.py", line 283, in _maybe_define_function
    concrete_function = _create_concrete_function(
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/dku/fedcampus/FedKit/backend/.venv/lib/python3.11/site-packages/tensorflow/python/eager/polymorphic_function/tracing_compilation.py", line 310, in _create_concrete_function
    traced_func_graph = func_graph_module.func_graph_from_py_func(
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/dku/fedcampus/FedKit/backend/.venv/lib/python3.11/site-packages/tensorflow/python/framework/func_graph.py", line 1059, in func_graph_from_py_func
    func_outputs = python_func(*func_args, **func_kwargs)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/dku/fedcampus/FedKit/backend/.venv/lib/python3.11/site-packages/tensorflow/python/eager/polymorphic_function/polymorphic_function.py", line 599, in wrapped_fn
    out = weak_wrapped_fn().__wrapped__(*args, **kwds)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/dku/fedcampus/FedKit/backend/.venv/lib/python3.11/site-packages/tensorflow/python/eager/polymorphic_function/polymorphic_function.py", line 1719, in bound_method_wrapper
    return wrapped_fn(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/dku/fedcampus/FedKit/backend/.venv/lib/python3.11/site-packages/tensorflow/python/eager/polymorphic_function/autograph_util.py", line 52, in autograph_handler
    raise e.ag_error_metadata.to_exception(e)
  File "/data/dku/fedcampus/FedKit/backend/.venv/lib/python3.11/site-packages/tensorflow/python/eager/polymorphic_function/autograph_util.py", line 41, in autograph_handler
    return api.converted_call(
           ^^^^^^^^^^^^^^^^^^^
  File "/data/dku/fedcampus/FedKit/backend/.venv/lib/python3.11/site-packages/tensorflow/python/autograph/impl/api.py", line 439, in converted_call
    result = converted_f(*effective_args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/__autograph_generated_file__ud6qml.py", line 12, in tf__parameters
    retval_ = {f'a{ag__.ld(index)}': ag__.converted_call(ag__.ld(weight).read_value, (), None, fscope) for index, weight in ag__.converted_call(ag__.ld(enumerate), (ag__.ld(self).model.weights,), None, fscope)}
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/__autograph_generated_file__ud6qml.py", line 12, in <dictcomp>
    retval_ = {f'a{ag__.ld(index)}': ag__.converted_call(ag__.ld(weight).read_value, (), None, fscope) for index, weight in ag__.converted_call(ag__.ld(enumerate), (ag__.ld(self).model.weights,), None, fscope)}
                                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: in user code:

    File "/data/dku/fedcampus/FedKit/convert_model/tflite.py", line 31, in parameters  *
        f"a{index}": weight.read_value()

    AttributeError: 'Variable' object has no attribute 'read_value'

After changing
https://github.com/FedCampus/FedKit/blob/e203312add2c9fc1ebb5511bae8a52eb384814c4/convert_model/tflite.py#L31
to
f"a{index}": weight.value.read_value()

this error is resolved, but I then encountered another error
2024-04-17 15:54:33.916521: I external/local_tsl/tsl/cuda/cudart_stub.cc:32] Could not find cuda drivers on your machine, GPU will not be used.
2024-04-17 15:54:33.920357: I external/local_tsl/tsl/cuda/cudart_stub.cc:32] Could not find cuda drivers on your machine, GPU will not be used.
2024-04-17 15:54:33.969224: I tensorflow/core/platform/cpu_feature_guard.cc:210] This TensorFlow binary is optimized to use available CPU instructions in performance-critical operations.
To enable the following instructions: AVX2 FMA, in other operations, rebuild TensorFlow with the appropriate compiler flags.
2024-04-17 15:54:35.695073: W tensorflow/compiler/tf2tensorrt/utils/py_utils.cc:38] TF-TRT Warning: Could not find TensorRT
2024-04-17 15:54:37.321051: I external/local_xla/xla/stream_executor/cuda/cuda_executor.cc:998] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero. See more at https://github.com/torvalds/linux/blob/v6.0/Documentation/ABI/testing/sysfs-bus-pci#L344-L355
2024-04-17 15:54:37.322647: W tensorflow/core/common_runtime/gpu/gpu_device.cc:2251] Cannot dlopen some GPU libraries. Please make sure the missing libraries mentioned above are installed properly if you would like to use GPU. Follow the guide at https://www.tensorflow.org/install/gpu for how to download and setup the required libraries for your platform.
Skipping registering GPU devices...
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/data/dku/fedcampus/FedKit/convert_model/mnist_eg/tf.py", line 32, in <module>
    tflite()
  File "/data/dku/fedcampus/FedKit/convert_model/mnist_eg/tf.py", line 25, in tflite
    save_model(model, SAVED_MODEL_DIR)
  File "/data/dku/fedcampus/FedKit/convert_model/tflite.py", line 71, in save_model
    tf.saved_model.save(
  File "/data/dku/fedcampus/FedKit/backend/.venv/lib/python3.11/site-packages/tensorflow/python/saved_model/save.py", line 1392, in save
    save_and_return_nodes(obj, export_dir, signatures, options)
  File "/data/dku/fedcampus/FedKit/backend/.venv/lib/python3.11/site-packages/tensorflow/python/saved_model/save.py", line 1427, in save_and_return_nodes
    _build_meta_graph(obj, signatures, options, meta_graph_def))
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/dku/fedcampus/FedKit/backend/.venv/lib/python3.11/site-packages/tensorflow/python/saved_model/save.py", line 1642, in _build_meta_graph
    return _build_meta_graph_impl(obj, signatures, options, meta_graph_def)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/dku/fedcampus/FedKit/backend/.venv/lib/python3.11/site-packages/tensorflow/python/saved_model/save.py", line 1566, in _build_meta_graph_impl
    asset_info, exported_graph = _fill_meta_graph_def(
                                 ^^^^^^^^^^^^^^^^^^^^^
  File "/data/dku/fedcampus/FedKit/backend/.venv/lib/python3.11/site-packages/tensorflow/python/saved_model/save.py", line 933, in _fill_meta_graph_def
    signatures = _generate_signatures(signature_functions, object_map, defaults)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/dku/fedcampus/FedKit/backend/.venv/lib/python3.11/site-packages/tensorflow/python/saved_model/save.py", line 655, in _generate_signatures
    outputs = object_map[function](**{
              ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/dku/fedcampus/FedKit/backend/.venv/lib/python3.11/site-packages/tensorflow/python/eager/polymorphic_function/saved_model_exported_concrete.py", line 45, in __call__
    export_captures = _map_captures_to_created_tensors(
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/dku/fedcampus/FedKit/backend/.venv/lib/python3.11/site-packages/tensorflow/python/eager/polymorphic_function/saved_model_exported_concrete.py", line 74, in _map_captures_to_created_tensors
    _raise_untracked_capture_error(function.name, exterior, interior)
  File "/data/dku/fedcampus/FedKit/backend/.venv/lib/python3.11/site-packages/tensorflow/python/eager/polymorphic_function/saved_model_exported_concrete.py", line 98, in _raise_untracked_capture_error
    raise AssertionError(msg)
AssertionError: Tried to export a function which references an 'untracked' resource. TensorFlow objects (e.g. tf.Variable) captured by functions must be 'tracked' by assigning them to an attribute of a tracked object or assigned to an attribute of the main object directly. See the information below:
	Function name = b'__inference_signature_wrapper_1685'
	Captured Tensor = <ResourceHandle(name="loss/total/10", device="/job:localhost/replica:0/task:0/device:CPU:0", container="Anonymous", type="tensorflow::Var", dtype and shapes : "[ DType enum: 1, Shape: [] ]")>
	Trackable referencing this tensor = <tf.Variable 'loss/total:0' shape=() dtype=float32>
	Internal Tensor = Tensor("1637:0", shape=(), dtype=resource)
8 restore test results.

According to answers such as https://stackoverflow.com/questions/73416907/model-save-tried-to-export-a-function-which-references-untracked-resource-eve, the use of static members might cause this problem, but I don't know how to fix it in this project's case.

Did reproduce. Unfortunately, I don't know how to solve this.
Ideas:

Try with the version here: https://github.com/adap/flower/blob/main/examples/android-kotlin/gen_tflite/pyproject.toml
Check out TFLite's latest on-device training example and compare it to the 2022 one (which this converter is based on).


No signal with GPIO

I have installed MMM-ModuleToggleButton.
The module hides the specific modules as wanted.
I have activated the GPIO in Raspberry pi menu.
Iam using pin 20 (GND) and 22 (GPIO 6) to my momentary switch.
Using Raspbeery pi 2 model B.
No response when i press the switch. Anyone have any idea?
This is the config iam using.
{
	      module: 'MMM-ModuleToggleButton',
	      config: {
		buttonGpioPin: 6,
		moduleNames: [
		  'clock',
		  'calendar'
		]
	      }
 },

Hello @nee0,
There is nothing in the code that would prevent the module to work with your settings, actually I'm using it with the same configuration.
But according to this page GPIO 6 is on pin 31, not on 22.
Could you please double check your wiring?

I'm closing this issue because it was not updated for more than 4 years.


Should we provide parameters for 'data_dir' or 'untar' to cifar10.load_data?

https://github.com/tensorflow/tensorflow/blob/d7409d32bba5ffa89141ec5427780f68a3b6942d/tensorflow/python/keras/_impl/keras/datasets/cifar10.py#L30
This is maybe really a trivial issue for such a brilliant framework,
but it would be great more friendly to add this flexibility to load data from somewhere that I already have it and unpacked. Or it will fixed me to dig into the source to find where and in which format should this data be stored.
Hope that make sense.
Thanks a lot for you time.

Sounds fine by me. This will need to go through an API review.
CC @martinwicke

@drpngx @uZeroJ I think it's reasonable. I'd like to make a PR to add the flexibility.

@DjangoPeng Thanks!

I think @fchollet  has given a reasonable explaination in the PR. I agree on his point and suggest to close the issue, cause there is already a function for using local data files.
@uZeroJ @drpngx  What do you think?

@DjangoPeng , Got it. Anyway thanks again.


Undead headless chrome browsers are hanging around

We found several Chrome browsers hanging around in someone's container. I believe sometimes ALKiln test are interrupted and don't close the browser properly. Two things to do:

Help people who are currently using this package to close the ghost browsers. If they don't have their own chrome instances that they need, I'm looking at sudo killall -e chrome. I did research it, but I also use it regularly (for Reasons) and it may sound extreme, but it's ok.
Figure out how to take care of it in the future. Here's what I'm thinking, using this stackoverflow as a starting point:

Save the browser PID to a list of browser PIDs in the ALKiln runtime config.
When starting the AitP interview, loop through that list and try to close the processes with those IDs that have also been running for more than a day. We can think about adding an env var for max time for a test run.

There might be other things we can do, for example I'm looking into try/catch/finally for closing the browser. I'm not sure where  in cucumber to put it. In Before() where we first create the browser? Currently we don't kill it till AfterAll(), so maybe we should move the start into BeforeAll() and also use a timeout that errors after 1 day.
I think that would probably be good practice, but also unlikely to solve what I think are more likely sources for the problem - internal un-terminated timeouts or the background action ending early/getting interrupted early by the server reloading and doing something funky. Need to experiment a bit.

We may need to take care of this in ALKiln itself with process.

Currently pursuing using .Popen() with start_new_session, getting the pid, and then using os to kill the new process group.


Integration test flakiness?

==> v1beta1/Deployment
NAME             DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
httpbin-httpbin  1        1        1           0          0s

==> v1/Pod(related)
NAME                              READY  STATUS             RESTARTS  AGE
httpbin-httpbin-7777dd96b5-d2sxw  0/1    ContainerCreating  0         0s

Waiting for rollout to finish: 0 of 1 updated replicas are available...
deployment "httpbin-httpbin" successfully rolled out
curl: (7) Failed to connect to <IP_ADDRESS> port 31556: Connection refused
FAIL: (Bhttpbin failed to return 200 OK
namespace "helmfile-tests-20180409-132441" deleted
make: *** [integration] Error 1
Exited with code 2

Didn't dig deep but the error can be seen at https://circleci.com/gh/roboll/helmfile/285?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

#128 might help to avoid this failure mode by retrying upon the initial curl exiting with code <> 0.

Another example: https://circleci.com/gh/roboll/helmfile/466
deployment "httpbin-httpbin" successfully rolled out
curl: (7) Failed to connect to <IP_ADDRESS> port 32753: Connection refused
FAIL: (Bhttpbin failed to return 200 OK

Another 2 examples:
https://circleci.com/gh/roboll/helmfile/tree/pull%2F171


Documentation: Extend the Debugging article with many more details

[ ] Fix the usage of __debugbreak() to be debugger;
[ ] document how node inspector works
[ ] document the common debugging cases:
[ ] - set/remove breakpoint
[ ] - step, step into, step out, continue
[ ] - how to break on unhandled exception
[ ] - inspect local variables

As this is a core functionality please make it as detailed as possible so that even non experienced developers to be able to debug an app - use screenshots for most of the things. We can run it by @ikoevska as well.

moved to https://github.com/NativeScript/android-runtime-docs/issues/5


xcode 8.3 Warnings

Hello,
xcode 8.3 is displaying 11 new warnings :

SpringIndicator.swift:28:30: Method 'initialize()' defines Objective-C class method 'initialize', which is not guaranteed to be invoked by Swift and will be disallowed in future versions

SpringIndicator.swift:42:40: 'M_PI' is deprecated: Please use 'Double.pi' or '.pi' to get the value of correct type and avoid casting.

SpringIndicator.swift:42:47: 'M_PI_2' is deprecated: Please use 'Double.pi / 2' or '.pi / 2' to get the value of correct type and avoid casting.

SpringIndicator.swift:232:29: 'M_PI_2' is deprecated: Please use 'Double.pi / 2' or '.pi / 2' to get the value of correct type and avoid casting.

SpringIndicator.swift:233:27: 'M_PI_2' is deprecated: Please use 'Double.pi / 2' or '.pi / 2' to get the value of correct type and avoid casting.

SpringIndicator.swift:348:28: 'M_PI' is deprecated: Please use 'Double.pi' or '.pi' to get the value of correct type and avoid casting.

SpringIndicator.swift:348:35: 'M_PI_4' is deprecated: Please use 'Double.pi / 4' or '.pi / 4' to get the value of correct type and avoid casting.

SpringIndicator.swift:349:24: 'M_PI' is deprecated: Please use 'Double.pi' or '.pi' to get the value of correct type and avoid casting.

SpringIndicator.swift:349:31: 'M_PI_4' is deprecated: Please use 'Double.pi / 4' or '.pi / 4' to get the value of correct type and avoid casting.

SpringIndicator.swift:499:85: 'M_PI' is deprecated: Please use 'Double.pi' or '.pi' to get the value of correct type and avoid casting.

SpringIndicator.swift:499:92: 'M_PI_4' is deprecated: Please use 'Double.pi / 4' or '.pi / 4' to get the value of correct type and avoid casting.

@ergunkocak You can fix all the M_PI / M_PI_2 / M_PI_4 errors by replacing M_PI with Double.pi, M_PI_2 with Double.pi / 2, and M_PI_4 with Double.pi / 4. I'm having a lot more trouble with fixing the initialize() warning though. initialize() is called by the Objective C runtime once per class, before that class is sent any messages whatsoever. I tried 2, both of which were from this StackOverflow answer, but I still haven't been able to resolve this issue.
@KyoheiG3 Do you have any input?

@ergunkocak @KyoheiG3 Quick update. When changing the M_PI constants to Double.pi values, I made some mistakes with parentheses. This took forever to track down, so I recommend that you wrap statements like Double.pi / 2 in parentheses: (Double.pi / 2) to avoid bugs.

@KyoheiG3 Do you have any input?

@ergunkocak I'm having the same problem. Did you solve it?

@pranjalsatija @burhanaksendir Hi.
I solved these warnings in 1.5.0
Thank you, guys.

@KyoheiG3 Thanks


InteractItemEvent and InteractBlockEvent behave incorrectly

I am currently running

SpongeVanilla version: spongevanilla-1.12.2-7.1.0-BETA-93
Java version: OpenJDK Version "1.8.0_171"
Operating System: Linux Mint 18.3 Sylvia (Kernel: x86_64 Linux 4.13.0-45-generic)
Plugins/Mods: Empty (Only one my experimental plugin)

Issue Description
At the last build for version 1.12.2, the following bugs are observed:
1. InteractBlockEvent is not called when the right mouse button is clicked (this is a SECONDARY event for both hands).
2. InteractBlockEvent for the left hand (PRIMARY event) does not contain data about the used item when the player clicked into the air. EventContext is empty.

Right button to air: Does not fired. Perhaps also there is no context.
Left button to block: Missing data about used item.
Right button to block: Fired SECONDARY event with full data. However, also fired SECONDARY event of the off hand.

Updated report...

@Lignium Have you tested SpongeForge?

@bloodmc No, I tested only SpongeVanilla.

Test this with SF, if you can.

Right button to block: Fired SECONDARY event with full data. However, also fired SECONDARY event of the off hand.
This will happen no matter the platform as we have no idea what you're right clicking with as Vanilla doesn't even know and just sends the packet for both of them.
@bloodmc ^

Yes, the right click on block is not a bug and is working as intended.

Similarly with the InteractItemEvent... :(

@Lignium I suspect there's some confusing at the result you expect.
Are you complaining about lack of context of what the player is holding?
Who is doing the clicking?
Essentially, for the 4 above, can you outline what you see (on each platform), what you expect, and why you have made the issue?
Originally (before your edits) it seemed you believed they wern't being fired at all.
A test plugin would help.

I can confirm that its not acting correctly, one can not throw items like enderpearls, eggs, and snowballs when they are looking at a block.

Full analysis of interaction events:

Red - Missing data.
Blue - "UsedItem" context, probably should be present (in InteractItemEvent.Secondary.MainHand is present).
Orange - Bad data. Should be NONE and Optional.empty.

@ImMorpheus
Green: Well, look carefully at the values of this data. There should not be integers. There must be coordinates of an intersection point with a block surface, logically.

I am not sure what was already discussed about InteractItemEvent, but it is not fired at all when I am doing a right click on a block.
Tested on "spongeforge-1.12.2-2768-7.1.6-RC3561.jar" and "spongeforge-1.12.2-2768-7.1.5.jar", works fine with "spongeforge-1.12.2-2768-7.1.5-RC3515.jar"...

@GreWeMa that is intentional when the hand is empty https://github.com/SpongePowered/SpongeCommon/pull/2125#issuecomment-453771117

@phit I tested it with an item in hand

@GreWeMa Open an issue with a the step to reproduce the issue. (minimal code snippet + instructions).

@ImMorpheus
SF spongeforge-1.12.2-2768-7.1.5-RC3515.jar:
Works as expected, InteractItemEvent is fired whenever I'm doing a right click.
SF spongeforge-1.12.2-2768-7.1.6-RC3561.jar/spongeforge-1.12.2-2768-7.1.5.jar:
InteractItemEvent is fired when I'm doing a right click at air, it is also fired when I'm doing a right click at a block with a "non-placeable" item in hand (stick, arrow, feather etc.), but when I'm doing a right click at a block with a "placeable" item in hand (dirt, stone, skull etc.) - event is not fired.
Is it a bug, or is it just how the new API works? If its second, then it's not quite comfortable and now I need to use both "InteractItemEvent" and "InteractBlockEvent" in order to do things that I was able to do using only "InteractItemEvent"...

@ImMorpheus If everything else is fixed, then everything is fine.

@ImMorpheus Has the "green" and "blue" problems been fixed? I cannot find the code that reflects this in your pull request.

So I tested it again... This time I made two tests, with an item stack in my hand and without.

Red - Missing data about the player. Owner and notifier cannot be used as a source of this data.
Violet - Invalid data.
Blue - Last time I wrote about it, but you did not fix it. Please look carefully at these values and see what is wrong here.
Orange - How did it turn out?!

With an item stack (stick):

Empty hand:

@bloodmc As I understand you already fixed the red problem? https://github.com/SpongePowered/SpongeCommon/commit/7de73b25245c0f7d8a5e24091095ab758874ebc0

Only now I noticed that InteractBlockEvent.Primary.MainHand has block_hit context that is not equal to BlockSnapshot.NONE.
Already 8 months have passed, but bugs with these two events are still not fixed. I can’t make a properly working wand to highlight regions (similar to WorldEdit), but with 2 additional functions when air clicks. I am already losing hope that this issue will ever be closed.

From BLOCK_HIT javadoc:

Used when an {@link Entity} interacts with a block.

https://github.com/SpongePowered/SpongeAPI/blob/b2736425ce386018267484f3fed65c9950e5d984/src/main/java/org/spongepowered/api/event/cause/EventContextKeys.java#L78
InteractItemEvent is NOT fired because you've interacted with a block.
If anything, the bug is that EventContextKeys.BLOCK_HIT shouldn't be present

InteractItemEvent is NOT fired because you've interacted with a block.

Yes indeed, everything is correct.

If anything, the bug is that EventContextKeys.BLOCK_HIT shouldn't be present

Do you mean that you need to remove EventContextKeys.BLOCK_HIT from events that involve click to air? If yes, then I agree, it will be logical.
The fact is that left click to air and right click to block lead to firing of parasitic events, such as InteractBlockEvent and InteractItemEvent, for them accordingly. If you cannot remove them for any reason, I will have to distinguish them from useful events. For example, look at the image on the events InteractItemEvent when player right clicks to air and to block. At the moment, they are absolutely indistinguishable from each other, as a result it is impossible to know where a player hit, to block or to air.
Here is my code, which, if these events work correctly, should properly filter out parasitic events:
@Listener
public void onInteractItem(InteractItemEvent event) {
    Objects.requireNonNull(event, "event");

    EventContext context = event.getContext();
    Optional<BlockSnapshot> blockHitBox = context.get(EventContextKeys.BLOCK_HIT);

    // When right click to block the block hit will be BlockSnapshot.NONE.
    // The filter will not be work.

    if (blockHitBox.isPresent() && !blockHitBox.get().equals(BlockSnapshot.NONE)) {
        return;
    }

    // Check item and etc...

    Optional<ItemStackSnapshot> usedItemBox = context.get(EventContextKeys.USED_ITEM);
}

@Listener
public void onInteractBlock(InteractBlockEvent event) {
    Objects.requireNonNull(event, "event");

    EventContext context = event.getContext();
    Optional<BlockSnapshot> blockHitBox = context.get(EventContextKeys.BLOCK_HIT);

    // When left click to air the block hit will be a block snapshot of air.
    // The filter also will not be work.
    // I can certainly check this snapshot for air, but this is a very ugly way.

    if (blockHitBox.isPresent() && blockHitBox.get().equals(BlockSnapshot.NONE)) {
        return;
    }

    // Check item and etc...

    Optional<ItemStackSnapshot> usedItemBox = context.get(EventContextKeys.USED_ITEM);
}

Do you mean that you need to remove EventContextKeys.BLOCK_HIT from events that involve click to air? If yes, then I agree, it will be logical.

It means I'm thinking of removing EventContextKeys.BLOCK_HIT from all InteractItemEvents

For example, look at the image on the events InteractItemEvent when player right clicks to air and to block. At the moment, they are absolutely indistinguishable from each other, as a result it is impossible to know where a player hit, to block or to air.

That's correct. You're using the wrong event.
InteractItemEvent is linked to CPacketPlayerTryUseItem, it doesn't hold the information of whether you've hit a block or not, thus they are indistinguishable.

@ImMorpheus What about interaction points of InteractItemEvents? It is also not presented in the packet? If so, how can explain the existence of an appropriate API access method.

What about interaction points of InteractItemEvents? It is also not presented in the packet? If so, how can explain the existence of an appropriate API access method.
It's not, but we raytrace to provide the interaction point.
I will fix this.

@ImMorpheus So you propose to artificially calculate the point of intersection with a block? To do this, you need to know the standard distance from the game at which player can "reach" blocks, in order to determine when the interaction point should be specified, and when not. However, in this case, it is possible at the same time to provide information about the block, why not?


'Unknown symbol in module' when trying to load custom kernel backend in Jetson

Required Info

Camera Model
435i

Firmware Version
NA

Operating System & Version
Linux Ubuntu 20.04

Kernel Version (Linux Only)
4.9.140 and l4t-r32.4.2

Platform
NVIDIA Jetson AGX

SDK Version
v2.41.0

Language
NA

Segment
Robot

In addition, I am running everything in a Docker container using Balena platform https://www.balena.io/. In a nutshell it runs in the host device a basic Yocto linux distribution with the l4t necessary files and runs a custom Docker image.
Issue Description
I'm trying to build from source using the native backend following this tutorial. I am running this script.
Everything runs smoothly and the kernels are successfully compiled. The resulting .ko files are these:
root@0a57d74:~# ls
tegra-l4t-r32.3.1-hid-sensor-accel-3d.ko    tegra-l4t-r32.3.1-hid-sensor-trigger.ko  tegra-l4t-r32.3.1-videobuf-vmalloc.ko
tegra-l4t-r32.3.1-hid-sensor-gyro-3d.ko     tegra-l4t-r32.3.1-uvcvideo.ko
tegra-l4t-r32.3.1-hid-sensor-iio-common.ko  tegra-l4t-r32.3.1-videobuf-core.ko

Nonetheless, I am having trouble in the last part of the script where the kernel modules are supposed to be loaded with depmod. Since we are running inside a docker container and using Balena, they do not allow the user to use depmod or modprob because /lib/modules/4.9.140-l4t-r32.4.2 is read-only. They propose instead that the user loads the kernel using insmod. So I tried to load manually the .ko. I was able to load all modules except for the ones corresponding to hid-sensor*.
The error for example looks like:
root@0a57d74:~# insmod tegra-l4t-r32.3.1-hid-sensor-trigger.ko
insmod: ERROR: could not insert module tegra-l4t-r32.3.1-hid-sensor-trigger.ko: Unknown symbol in module

Inspecting the errors with dmesg we get:
[ 1575.470310] USB Video Class driver (1.1.1)
[ 1578.284849] hid_sensor_accel_3d: Unknown symbol hid_sensor_parse_common_attributes (err 0)
[ 1578.284943] hid_sensor_accel_3d: Unknown symbol hid_sensor_write_raw_hyst_value (err 0)
[ 1578.284961] hid_sensor_accel_3d: Unknown symbol hid_sensor_setup_trigger (err 0)
[ 1578.284989] hid_sensor_accel_3d: Unknown symbol sensor_hub_register_callback (err 0)
[ 1578.285012] hid_sensor_accel_3d: Unknown symbol hid_sensor_remove_trigger (err 0)
[ 1578.285030] hid_sensor_accel_3d: Unknown symbol hid_sensor_read_raw_hyst_value (err 0)
[ 1578.285079] hid_sensor_accel_3d: Unknown symbol sensor_hub_remove_callback (err 0)
[ 1578.285141] hid_sensor_accel_3d: Unknown symbol sensor_hub_input_attr_get_raw_value (err 0)
[ 1578.285216] hid_sensor_accel_3d: Unknown symbol sensor_hub_input_get_attribute_info (err 0)
[ 1578.285426] hid_sensor_accel_3d: Unknown symbol hid_sensor_pm_ops (err 0)
[ 1578.285472] hid_sensor_accel_3d: Unknown symbol hid_sensor_power_state (err 0)
[ 1578.285521] hid_sensor_accel_3d: Unknown symbol hid_sensor_format_scale (err 0)
[ 1578.285637] hid_sensor_accel_3d: Unknown symbol hid_sensor_write_samp_freq_value (err 0)
[ 1578.285686] hid_sensor_accel_3d: Unknown symbol hid_sensor_read_samp_freq_value (err 0)
[ 1950.815702] hid_sensor_trigger: Unknown symbol sensor_hub_set_feature (err 0)
[ 1950.815771] hid_sensor_trigger: Unknown symbol hid_sensor_get_usage_index (err 0)
[ 1950.815803] hid_sensor_trigger: Unknown symbol sensor_hub_device_close (err 0)
[ 1950.815823] hid_sensor_trigger: Unknown symbol hid_sensor_read_poll_value (err 0)
[ 1950.815873] hid_sensor_trigger: Unknown symbol sensor_hub_device_open (err 0)
[ 1950.815888] hid_sensor_trigger: Unknown symbol sensor_hub_get_feature (err 0)
[ 2002.158082] hid_sensor_iio_common: Unknown symbol sensor_hub_set_feature (err 0)
[ 2002.158111] hid_sensor_iio_common: Unknown symbol sensor_hub_input_get_attribute_info (err 0)
[ 2002.158133] hid_sensor_iio_common: Unknown symbol sensor_hub_get_feature (err 0)
[ 2196.647894] hid_sensor_gyro_3d: Unknown symbol hid_sensor_parse_common_attributes (err 0)
[ 2196.647978] hid_sensor_gyro_3d: Unknown symbol hid_sensor_write_raw_hyst_value (err 0)
[ 2196.648004] hid_sensor_gyro_3d: Unknown symbol hid_sensor_setup_trigger (err 0)
[ 2196.648042] hid_sensor_gyro_3d: Unknown symbol sensor_hub_register_callback (err 0)
[ 2196.648071] hid_sensor_gyro_3d: Unknown symbol hid_sensor_remove_trigger (err 0)
[ 2196.648092] hid_sensor_gyro_3d: Unknown symbol hid_sensor_read_raw_hyst_value (err 0)
[ 2196.648126] hid_sensor_gyro_3d: Unknown symbol sensor_hub_remove_callback (err 0)
[ 2196.648196] hid_sensor_gyro_3d: Unknown symbol sensor_hub_input_attr_get_raw_value (err 0)
[ 2196.648219] hid_sensor_gyro_3d: Unknown symbol sensor_hub_input_get_attribute_info (err 0)
[ 2196.648241] hid_sensor_gyro_3d: Unknown symbol hid_sensor_pm_ops (err 0)
[ 2196.648264] hid_sensor_gyro_3d: Unknown symbol hid_sensor_power_state (err 0)
[ 2196.648310] hid_sensor_gyro_3d: Unknown symbol hid_sensor_format_scale (err 0)
[ 2196.648347] hid_sensor_gyro_3d: Unknown symbol hid_sensor_write_samp_freq_value (err 0)
[ 2196.648375] hid_sensor_gyro_3d: Unknown symbol hid_sensor_read_samp_freq_value (err 0)

Can anyone guess how to properly load those modules? Or any hint on the other kernel needed to load these?

Update
I was missing the right Module.symvers because my system didn't have any /usr/src/linux-headers-4.9.140-tegra-ubuntu18.04_aarch64/kernel-4.9 folder. Also the patch script was downloading the wrong L4T version (32.3.1) because there is also no /etc/nv_tegra_release so I set it that manually. I fixed it to download the right version (32.4.2) that matches the uname -r. Also the Module.symvers file was downloaded from https://developer.nvidia.com/embedded/L4T/r32_Release_v4.2/t186ref_release_aarch64/Tegra186_Linux_R32.4.2_aarch64.tbz2. Nonetheless I am having a different problem.
when trying to insert de module I got:
insmod: ERROR: could not insert module tegra-l4t-r32.4.2-hid-sensor-iio-common.ko: Invalid module format

And dmesg shows:
[  180.874804] hid_sensor_iio_common: disagrees about version of symbol module_layout

I really don't understand really well how kernel compilation works so maybe I am doing something wrong. It would be of much help if someone that manages this topic could help. thanks!

@charlielito hello,
We do not run and test "containerized" Jetson , so we cannot check and address it directly.
Based on experience with AGX Xavier, the specific error was fired when trying to insert the newly compiled module without performing depmod first. As you've noticed it may be indeed prohibited in Docker.
On the other hand, D435i have received native kernel support with the release of L4T 4.4.1 (rev 32.4.4)  and 4.5, as the specific Librealsense patches were integrated into the kernel.
Thus if you upgrade the revision you might not need to perform the patching process. #8254

Thanks @ev-mp for the helpful information! I tried with L4T 4.4.1 (rev 32.4.4) and it works like a charm!


Using API Key

Is it possible to implement the authentification with plesk API Keys instead of Username and Password?

Hi huabor,
I can update/add this behaviour this weekend.

Hey nickurt, are you able to implement the feature?

Yes, I will try to do it in the coming days, sadly I didn't had time last weekend.
If possible, feel free to make a PR/suggestion.

Hi huabor,
I added support for secret/key based auth in the latest master-commit, you can use it when you add
'key' => env('PLESK_DEFAULT_KEY'),

to your existing config-file


redirect help -> support to the GitHub page for support

This was left as TBW and now we fill it out

done


performantly redeploying PEX files by sharding their requirements

This issue should be conclusively resolved before #787 can be reviewed.
From that PR:
Problem
Redeploying pex files full of many extremely large 3rdparty requirements (tensorflow, etc) into our datacenter at Twitter currently takes a very long time, since we upload them all at once into an internal artifact resolution utility, and then pull down the entire pex file before executing it. This slowness to redeploy then also affects multiple of our internal python development workflows and tooling for machine learning (including a Jupyter wrapper developed by @kwlzn) which depend on executing a pex file within the datacenter -- in that case, modifying any python source files in our monorepo currently requires waiting several minutes for changes to be usable within that Jupyter notebook.
As far as we are aware, other users of pex who package large machine learning applications also suffer from this issue and do not have an easy workaround.
(Initial) Proposed Solution
This is implemented in #787.
We would like to be able to ship around "dehydrated" pex files without 3rdparty requirements embedded in the pex, and resolve ("hydrate") them before executing the pex. This removes one half of the current process of synchronously waiting to upload and download 3rdparty requirements, and moves the remaining download part off the critical path of the entire redeploy process. Because the requirements to hydrate were already resolved when building the pex, we know all the exact versions of all the transitive dependencies to resolve at bootstrap time.
There are many ways we could potentially make the bootstrap resolve process faster -- #787 just uses a CachingResolver, with the idea that the machines that execute our pex files will eventually have most of the large distributions cached and won't need to redownload them on every redeploy (or that we can provision machines to have these requirements already contained within their local pex cache).
An alternative implementation of "hydration" that was considered was to use a virtualenv to hydrate requirements before running the pex with PEX_INHERIT_PATH=fallback, but it would be extremely helpful for us to avoid having to maintain separate tooling with virtualenv, and it would be really nice if pex could do that itself at bootstrap.
Feedback
From https://github.com/pantsbuild/pex/pull/787#issuecomment-552219882:

This changes a fundamental bit of the informal pex contract. You no-longer ship an app, you resolve it at runtime and allow in all manner of non-reproduceabilities that need to be carefully excluded or contended with.

Alternative Solutions
From https://github.com/pantsbuild/pex/pull/787#issuecomment-552219882:

Doesn't use of PEX_PATH already solve this? Build 2 pexes, one with the highly variable bits - maybe just sources and resources, and one with the more stable bits - large dependencies. Then on the deploy side, of the 2 pexes that now compose the app, only deploy the ones that have changed. To make this work well, we may need to enhance the build-side of pex; i.e.: have the pex tool / API understand how to resolve from other pexes as 1st-class indexes / find-links repos; but, crucially, this leaves the runtime unchanged. The same guarantees apply.

Responses to the above feedback to follow as comments in this issue.

@jsirois:

Doesn't use of PEX_PATH already solve this? Build 2 pexes, one with the highly variable bits - maybe just sources and resources, and one with the more stable bits - large dependencies. Then on the deploy side, of the 2 pexes that now compose the app, only deploy the ones that have changed.

This is precisely how multiple of our machine learning teams are working around the problem internally. A few issues with that which spurred this new approach:

"The dependencies between split pex files are not formally defined anywhere in the build graph or the pex files themselves."

This was feedback from the team who developed the current workaround.

This means we have to maintain separate tooling which:

is aware of which pex files to deploy at build time
makes sure that all are deployed (and avoid rebuilding/redeploying the 3rdparty requirements pex if it's up to date)
at runtime, pulls down the correct pex files, organizes them via PEX_PATH, then executes it.

Currently, this also still means that our developers still need to both wait for:

if the 3rdparty requirements pex is invalidated, to resolve massive requirements at build time, then to push those massive requirements to our distributed file store. This can take several minutes.
pulling down the massive 3rdparty requirements pex from our file store onto our datacenter machine (somewhat faster)

As mentioned above, we were considering using a virtualenv created via pip containing 3rdparty requirements with PEX_INHERIT_PATH=fallback to implement this, in order to make use of pip's local cache. We were thinking that either we could:

provision machines with most large requirements beforehand,
or that after downloading requirements once to a machine, that we could expect a fleet to be eventually consistent and have large requirements in their local pip cache,
depending upon whether we're running this in kubernetes or not.

Either way, downloading maybe-cached individual requirements in parallel from within the datacenter seemed easier to implement and likely to be more performant than stuffing all of that into a monolithic pex which always has to be copied over in full to each machine before being able to run the user's job.
The reason why the current approach (of resolving "dehydrated" requirements in pex at runtime) was considered useful enough to make a PR out of is because:

It avoids having to maintain any separate tooling in our CI at runtime, since the pex resolve logic is always stored in the .bootstrap/ dir of the generated pex. Executing the pex no longer requires extra scripting or tooling as required by the multi-pex or virtualenv setup.
It avoids having to manually separate pants targets into different pex files. Separately, it also avoids having to introduce any logic into pants.
It avoids pushing the burden of (checking whether each pex file in the multi-pex setup is invalidated, and downloading massive requirements and uploading if so) into wrapper scripts maintained by multiple separate teams that execute on the developer's laptop. Allowing this functionality to be part of the pex runtime means that our users can write the pants targets they'd expect to, instead of having to worry about the implementation details of how they get uploaded.

Two trains of thought we've been thinking of adopting are:

to adopt the convention of suffixing pex files with dehydrated_requirements in PEX-INFO with .ipex instead of .pex (and making sure that pants respects this convention when creating "dehydrated" pex files).
to introduce a PEX_ALLOW_LATE_HYDRATION env var, defaulting to False, which would mean that without explicitly specifying PEX_ALLOW_LATE_HYDRATION=True in their environment, running the pex file would immediately and loudly fail with a clear error message.

Both of these are intended to make the fact that this different type of "dehydrated" pex file isn't reproducible much more evident.
Finally, it's important to note that the current implementation in #787 specifically makes sure to resolve all transitive requirements fully, then storing them into the pex file. This ensures that the intransitive "resolve" at runtime (with transitive=False) should produce a pex file with the exact same requirements as if at build time. While this still introduces non-reproducibility (in case the contents of requirements with the same version have changed), we actually consider that to be a positive, because it also means that we can potentially hot-patch requirements with security vulnerabilities (for example) without having to do a redeploy. In any case, freezing versions of all transitive requirements felt like it ensured the exact kind of reproducibility we were looking for. I'd love to know whether there are issues with introducing that kind of reproducibility in pex at all, or if we can build in appropriate safeguards that allow us to overcome these issues.

Thinking about it now, one alternative approach that might let us iterate on this idea internally that doesn't require explicit pex support or separate wrapper scripts at runtime is to make an internal pants task which modifies the bootstrap script in the generated pex file instead of doing the resolve within pex itself.
However, support within the pex tool would still be required for the first commit of #787 (https://github.com/pantsbuild/pex/pull/787/commits/6390b490689f261869586b15fdf3107180620b91), to produce "dehydrated" pex files with the --dehydrated flag. Being able to create "dehydrated" pex files from within pex seems to be key to a lot of the benefits of the approach proposed in #787 -- it means users don't have to manually shard their pex files into 3rdparty and source pexes, for example.
There are a lot of alternatives we have to the actual runtime resolve, but separating out the diff to cover just introducing the --dehydrated option seems like it would avoid tying the pex project to supporting any specific runtime behavior. If that's desirable, we could then open up a separate discussion for the best implementation of the runtime hydration (and whether that part could or should be farmed out to a separate tool).

I'm still stuck back on why PEX is the right tool for the job at all here. It sounds like your requirements / acceptable actions include:

It's ok to resolve pinned artifactson the target host at PEX boot time.
You want to resolve the minimal set of things.
You want an isolated virtual environment.

A virtualenv + a pinned requirements file with hashes and a pip install --no-deps --only-binary :all: does exactly what you want. Is it perhaps the case that its only because Pants does not support this that you want to jam this functionality into pex?

To put a finer point on the last - with #781 in flight, the pex resolver will == the pip resolver. When Pants upgrades to pex 2.0.0 with the pip resolver, would pants generating a lockfile with hashes be enough here? You deploy the lockfile and run pip install .. which will do the minimal update.

Yes, specifically pex using the pip resolver as per #781 would make virtualenv a much more feasible solution!
However, the reason for focusing on the --dehydrated option separately from the implementation of whatever does the "late hydration" is so that we can avoid pulling down large requirements into pex files on the user's laptop. That part seems difficult to avoid, unless we simply make pants do the same logic we see in https://github.com/pantsbuild/pex/commit/6390b490689f261869586b15fdf3107180620b91 using pex-as-a-library. However, it's not possible to use pex-as-a-library in pants's v2 process execution API, and we'd like to be able to eventually make this process remotely executable.
It's possible, however, that pants v2 + remote execution may be able to replace this entirely, as it:
(1) Occurs inside the datacenter.
(2) Makes use of a distributed caching scheme.
That's something @stuhood has been discussing, but we haven't delved into super thoroughly yet. A previous implementation of this idea (at https://github.com/cosmicexplorer/pex/tree/incremental-pex-production-with-fingerprinting) was intended to be more v2-friendly, which attempted to fingerprint individual source modules and requirements. There would need to be some design work to understand how to hook up pex to the pants v2 distributed file store, since the only reason that could be useful is if each requirement could be downloaded separately, in parallel, at runtime.
Currently, pex resolving and downloading all requirements monolithically is not something we are able to break down post hoc, and we continue to pay the cost of uploading and downloading a massive pex each time. The --dehydrated approach allows any number of ways to pull down individual requirements separately, in parallel, and can make use of a cache containing individual requirements, which is where we (currently) see the opportunity for a maintainable speedup.
@stuhood also mentioned that rsync is supposed to be able to smartly handle diffs of files like this. The teams making use of the current multi-pex workaround are using rsync, and still seeing these issues. If there's reason to think that rsync or something else would be able to automatically shard large pex files into their constituent changed sources or requirements, we would be very interested in pursuing that, as it likely means we can avoid any pex changes to support this workflow.

To put a finer point on the last - with #781 in flight, the pex resolver will == the pip resolver. When Pants upgrades to pex 2.0.0 with the pip resolver, would pants generating a lockfile with hashes be enough here? You deploy the lockfile and run pip install .. which will do the minimal update.

Yes. Fundamentally, we're looking for a way to separate layers. And fundamentally what we need is a requirements.txt or Pipfile.lock either inside or alongside the pex. It sounds like we're all agreed that this is a reasonable thing to want to do (as long as it's clear that these files operate differently to ordinary pex files, by virtue of not being self-contained, perhaps by a different file extension).
Where we're not so clear is preferences between (at least) three ways of using that information:

Have an external script make a virtualenv and run the pip install from your previous comment to bootstrap. This adds complexity to the user (an external script needs to make sure things like virtualenv are present), but keeps pex itself beautifully simple.
Have the pex bootstrap script make and populate the virtualenv, rather than in an external script. This loads a bunch more logic (and potentially dependencies) into pex (and the pex file itself), but provides a simple and clear user experience.
Have the pex bootstrap script hydrate the files to where it would happen to do so if they were in the zipfile, rather than a separate virtualenv. This maybe is the best of both worlds; we only add "how to download deps" logic to pex - we don't need to introduce virtualenvs and instead use pex's existing directory conventions.

I don't have a strong preference, I think we can make any of the three work. Does anyone else have a strong preference (looking specifically at @jsirois and @kwlzn for this one :))
A separate axis of decision-making is whether the file downloads should be done by using pip, or by additionally adorning the lockfile additionally with content digests per requirement, and using something like fs_util to fetch the files from a remote execution CAS server, rather than fetching them from a flat repo / pypi index mirror. This feels like it adds complexity, rather than simplifying, to me, but I'm willing to be convinced otherwise.

additionally adorning the lockfile additionally with content digests per requirement, and using something like fs_util to fetch the files from a remote execution CAS server

My first attempt at addressing this issue did something like this, but adorning the PEX-INFO with content digests for source files. While that might be interesting later, it doesn’t address the issue we’re actually concerned about, which is downloading the 3rdparty requirements piece by piece (it still revolves requirements monolithically).
So I don’t think this work should be used at all, but it did introduce a model that is potentially similar to what you’re describing here, just for source files instead of requirements. While this branch is incredibly complex, I believe that scoping the changes to just cover digesting 3rdparty requirements might be a way to support the fs_util approach. (https://github.com/pantsbuild/pex/compare/master...cosmicexplorer:incremental-pex-production-with-fingerprinting?expand=1)
It’s definitely possible to do that entirely outside of pex, but in investigating this type of implementation, I might at first experiment with having pex itself shard + digest 3rdparty requirements. I’ll post to this issue if we follow that route and find that it works.

I've created a google doc to discuss the alternate implementations of this idea in greater depth at https://docs.google.com/document/d/1B_g0Ofs8aQsJtrePPR1PCtSAKgBG1o59AhS_NwfFnbI/edit?usp=sharing!

Since work is well underway to implement all this on top if pex in https://github.com/pantsbuild/pants/pull/8793 I'm going to close. Thanks for working through this @cosmicexplorer.


Convert CP437 to UTF8

Fix #5

Thanks!
I'll merge this, since it's more correct than the current behaviour. Hopefully iconv does not become an issue.
I'm expecting we will need a whole lot more code to get UTF8 out correctly in the presence of commands like ESC t for example, but this is a good start.


⚠ Bofrost.at has degraded performance

In 971b36e, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1053 ms

Resolved: Bofrost.at performance has improved in 07fe82f after 13 minutes.