slurmctld enters a spawn-kill loop

I observe a loop in my fork (NB: I run docker-compute in a Travis instance) ; when all services in steady state, slurmctld keeps restarting, and the following two lines appear continuosly in the second part of the log:
slurmctld_1 | 2016-03-17 14:32:00,617 INFO spawned: 'slurmctld' with pid 9203
slurmctld_1 | 2016-03-17 14:32:00,652 INFO exited: slurmctld (exit status 0; not expected)

Full log, up to the beginning of the loop:
Pulling consul (qnib/consul:latest)...
latest: Pulling from qnib/consul
Digest: sha256:53b8ea7af183312ba70917f4b0f68d5631fced9ae3559d6e29923de78c7bdd52
Status: Downloaded newer image for qnib/consul:latest
Creating dockercompute_consul_1...
Pulling slurmctld (qnib/slurmctld:latest)...
latest: Pulling from qnib/slurmctld
Digest: sha256:81f8c2f2b8f07c92a2c1adca2bc2e2e70ef713ce2bee86cba845761e0254245a
Status: Downloaded newer image for qnib/slurmctld:latest
Creating dockercompute_slurmctld_1...
Pulling compute (qnib/compute:latest)...
latest: Pulling from qnib/compute
Digest: sha256:ce03ba5acd061dfa0aaaeeb48b2b72e9f802ef09df3dfda93c5f7f149ddc609a
Status: Downloaded newer image for qnib/compute:latest
Creating dockercompute_compute_1...
Attaching to dockercompute_consul_1, dockercompute_slurmctld_1, dockercompute_compute_1
consul_1    | 2016-03-17 14:20:15,886 CRIT Supervisor running as root (no user in config file)
consul_1    | 2016-03-17 14:20:15,887 WARN Included extra file "/etc/supervisord.d/consul.ini" during parsing
consul_1    | 2016-03-17 14:20:15,905 INFO RPC interface 'supervisor' initialized
consul_1    | 2016-03-17 14:20:15,905 CRIT Server 'unix_http_server' running without any HTTP authentication checking
consul_1    | 2016-03-17 14:20:15,905 INFO supervisord started with pid 13
consul_1    | 2016-03-17 14:20:16,907 INFO spawned: 'consul' with pid 16
consul_1    | 2016-03-17 14:20:22,447 INFO success: consul entered RUNNING state, process has stayed up for > than 5 seconds (startsecs)
compute_1   | 2016-03-17 14:21:39,568 CRIT Supervisor running as root (no user in config file)
compute_1   | 2016-03-17 14:21:39,568 WARN Included extra file "/etc/supervisord.d/slurmd.ini" during parsing
compute_1   | 2016-03-17 14:21:39,568 WARN Included extra file "/etc/supervisord.d/slurm_update.ini" during parsing
compute_1   | 2016-03-17 14:21:39,568 WARN Included extra file "/etc/supervisord.d/munged.ini" during parsing
compute_1   | 2016-03-17 14:21:39,568 WARN Included extra file "/etc/supervisord.d/watchpsutil.ini" during parsing
compute_1   | 2016-03-17 14:21:39,569 WARN Included extra file "/etc/supervisord.d/diamond.ini" during parsing
compute_1   | 2016-03-17 14:21:39,569 WARN Included extra file "/etc/supervisord.d/sensu-api.ini" during parsing
compute_1   | 2016-03-17 14:21:39,569 WARN Included extra file "/etc/supervisord.d/sensu-client.ini" during parsing
compute_1   | 2016-03-17 14:21:39,569 WARN Included extra file "/etc/supervisord.d/sensu-server.ini" during parsing
compute_1   | 2016-03-17 14:21:39,569 WARN Included extra file "/etc/supervisord.d/rsyslog_conf.ini" during parsing
compute_1   | 2016-03-17 14:21:39,569 WARN Included extra file "/etc/supervisord.d/rsyslog.ini" during parsing
compute_1   | 2016-03-17 14:21:39,569 WARN Included extra file "/etc/supervisord.d/consul.ini" during parsing
compute_1   | 2016-03-17 14:21:39,593 INFO RPC interface 'supervisor' initialized
compute_1   | 2016-03-17 14:21:39,593 CRIT Server 'unix_http_server' running without any HTTP authentication checking
compute_1   | 2016-03-17 14:21:39,593 INFO supervisord started with pid 13
slurmctld_1 | 2016-03-17 14:21:12,438 CRIT Supervisor running as root (no user in config file)
slurmctld_1 | 2016-03-17 14:21:12,438 WARN Included extra file "/etc/supervisord.d/scratchsetup.ini" during parsing
slurmctld_1 | 2016-03-17 14:21:12,438 WARN Included extra file "/etc/supervisord.d/slurmstats.ini" during parsing
slurmctld_1 | 2016-03-17 14:21:12,438 WARN Included extra file "/etc/supervisord.d/slurmctld.ini" during parsing
slurmctld_1 | 2016-03-17 14:21:12,438 WARN Included extra file "/etc/supervisord.d/slurm_update.ini" during parsing
slurmctld_1 | 2016-03-17 14:21:12,438 WARN Included extra file "/etc/supervisord.d/munged.ini" during parsing
slurmctld_1 | 2016-03-17 14:21:12,438 WARN Included extra file "/etc/supervisord.d/watchpsutil.ini" during parsing
slurmctld_1 | 2016-03-17 14:21:12,438 WARN Included extra file "/etc/supervisord.d/diamond.ini" during parsing
slurmctld_1 | 2016-03-17 14:21:12,438 WARN Included extra file "/etc/supervisord.d/sensu-api.ini" during parsing
slurmctld_1 | 2016-03-17 14:21:12,438 WARN Included extra file "/etc/supervisord.d/sensu-client.ini" during parsing
slurmctld_1 | 2016-03-17 14:21:12,438 WARN Included extra file "/etc/supervisord.d/sensu-server.ini" during parsing
slurmctld_1 | 2016-03-17 14:21:12,439 WARN Included extra file "/etc/supervisord.d/rsyslog_conf.ini" during parsing
slurmctld_1 | 2016-03-17 14:21:12,439 WARN Included extra file "/etc/supervisord.d/rsyslog.ini" during parsing
slurmctld_1 | 2016-03-17 14:21:12,439 WARN Included extra file "/etc/supervisord.d/consul.ini" during parsing
slurmctld_1 | 2016-03-17 14:21:12,463 INFO RPC interface 'supervisor' initialized
slurmctld_1 | 2016-03-17 14:21:12,463 CRIT Server 'unix_http_server' running without any HTTP authentication checking
slurmctld_1 | 2016-03-17 14:21:12,464 INFO supervisord started with pid 13
slurmctld_1 | 2016-03-17 14:21:13,465 INFO spawned: 'diamond' with pid 16
slurmctld_1 | 2016-03-17 14:21:13,467 INFO spawned: 'slurmctld' with pid 17
slurmctld_1 | 2016-03-17 14:21:13,468 INFO spawned: 'slurmstats' with pid 18
slurmctld_1 | 2016-03-17 14:21:13,474 INFO spawned: 'consul' with pid 19
slurmctld_1 | 2016-03-17 14:21:13,478 INFO spawned: 'sratchsetup' with pid 21
slurmctld_1 | 2016-03-17 14:21:13,481 INFO spawned: 'rsyslog-conf' with pid 22
slurmctld_1 | 2016-03-17 14:21:13,487 INFO spawned: 'sensu-api' with pid 23
slurmctld_1 | 2016-03-17 14:21:13,488 INFO spawned: 'sensu-client' with pid 24
slurmctld_1 | 2016-03-17 14:21:13,509 INFO spawned: 'slurm_update' with pid 28
slurmctld_1 | 2016-03-17 14:21:13,515 INFO spawned: 'rsyslog' with pid 32
slurmctld_1 | 2016-03-17 14:21:13,524 INFO spawned: 'munged' with pid 34
slurmctld_1 | 2016-03-17 14:21:13,532 INFO spawned: 'watchpsutil' with pid 40
slurmctld_1 | 2016-03-17 14:21:13,534 INFO spawned: 'sensu-server' with pid 44
slurmctld_1 | 2016-03-17 14:21:13,543 INFO success: diamond entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
slurmctld_1 | 2016-03-17 14:21:13,554 INFO exited: sratchsetup (exit status 1; not expected)
slurmctld_1 | 2016-03-17 14:21:13,610 INFO exited: sensu-server (exit status 0; not expected)
slurmctld_1 | 2016-03-17 14:21:13,615 INFO exited: slurmctld (exit status 0; not expected)
slurmctld_1 | 2016-03-17 14:21:14,519 INFO success: sensu-api entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
slurmctld_1 | 2016-03-17 14:21:14,519 INFO success: sensu-client entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
slurmctld_1 | 2016-03-17 14:21:14,519 INFO success: slurm_update entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
slurmctld_1 | 2016-03-17 14:21:14,519 INFO success: rsyslog entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
slurmctld_1 | 2016-03-17 14:21:14,519 INFO success: munged entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
slurmctld_1 | 2016-03-17 14:21:14,529 INFO success: watchpsutil entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
slurmctld_1 | 2016-03-17 14:21:14,537 INFO exited: diamond (exit status 0; expected)
slurmctld_1 | 2016-03-17 14:21:14,959 INFO spawned: 'slurmctld' with pid 412
slurmctld_1 | 2016-03-17 14:21:14,961 INFO spawned: 'sratchsetup' with pid 413
slurmctld_1 | 2016-03-17 14:21:14,962 INFO spawned: 'sensu-server' with pid 414
slurmctld_1 | 2016-03-17 14:21:15,030 INFO exited: sensu-server (exit status 0; not expected)
slurmctld_1 | 2016-03-17 14:21:15,057 INFO exited: sratchsetup (exit status 1; not expected)
slurmctld_1 | 2016-03-17 14:21:15,100 INFO exited: slurmctld (exit status 0; not expected)
slurmctld_1 | 2016-03-17 14:21:15,545 INFO exited: sensu-api (exit status 0; expected)
slurmctld_1 | 2016-03-17 14:21:17,847 INFO spawned: 'slurmctld' with pid 464
slurmctld_1 | 2016-03-17 14:21:17,876 INFO spawned: 'sratchsetup' with pid 465
slurmctld_1 | 2016-03-17 14:21:17,878 INFO spawned: 'sensu-server' with pid 466
slurmctld_1 | 2016-03-17 14:21:17,894 INFO exited: sratchsetup (exit status 1; not expected)
slurmctld_1 | 2016-03-17 14:21:17,905 INFO exited: sensu-server (exit status 0; not expected)
slurmctld_1 | 2016-03-17 14:21:17,907 INFO exited: slurmctld (exit status 0; not expected)
slurmctld_1 | 2016-03-17 14:21:18,543 INFO success: consul entered RUNNING state, process has stayed up for > than 5 seconds (startsecs)
slurmctld_1 | 2016-03-17 14:21:20,983 INFO spawned: 'slurmctld' with pid 520
slurmctld_1 | 2016-03-17 14:21:20,984 INFO spawned: 'sratchsetup' with pid 523
slurmctld_1 | 2016-03-17 14:21:20,986 INFO spawned: 'sensu-server' with pid 524
slurmctld_1 | 2016-03-17 14:21:21,024 INFO exited: sratchsetup (exit status 1; not expected)
slurmctld_1 | 2016-03-17 14:21:21,026 INFO gave up: sratchsetup entered FATAL state, too many start retries too quickly
slurmctld_1 | 2016-03-17 14:21:21,030 INFO exited: sensu-server (exit status 0; not expected)
slurmctld_1 | 2016-03-17 14:21:21,042 INFO gave up: sensu-server entered FATAL state, too many start retries too quickly
slurmctld_1 | 2016-03-17 14:21:21,047 INFO exited: slurmctld (exit status 0; not expected)
slurmctld_1 | 2016-03-17 14:21:25,615 INFO spawned: 'slurmctld' with pid 594
slurmctld_1 | 2016-03-17 14:21:25,665 INFO exited: slurmctld (exit status 0; not expected)
slurmctld_1 | 2016-03-17 14:21:28,545 INFO success: slurmstats entered RUNNING state, process has stayed up for > than 15 seconds (startsecs)
slurmctld_1 | 2016-03-17 14:21:28,545 INFO success: rsyslog-conf entered RUNNING state, process has stayed up for > than 15 seconds (startsecs)
slurmctld_1 | 2016-03-17 14:21:31,479 INFO spawned: 'slurmctld' with pid 682
slurmctld_1 | 2016-03-17 14:21:31,520 INFO exited: slurmctld (exit status 0; not expected)
slurmctld_1 | 2016-03-17 14:21:37,581 INFO spawned: 'slurmctld' with pid 770
slurmctld_1 | 2016-03-17 14:21:37,615 INFO exited: slurmctld (exit status 0; not expected)
compute_1   | 2016-03-17 14:21:40,596 INFO spawned: 'diamond' with pid 16
compute_1   | 2016-03-17 14:21:40,597 INFO spawned: 'consul' with pid 17
compute_1   | 2016-03-17 14:21:40,599 INFO spawned: 'rsyslog-conf' with pid 18
compute_1   | 2016-03-17 14:21:40,601 INFO spawned: 'sensu-api' with pid 19
compute_1   | 2016-03-17 14:21:40,603 INFO spawned: 'sensu-client' with pid 20
compute_1   | 2016-03-17 14:21:40,604 INFO spawned: 'slurm_update' with pid 21
compute_1   | 2016-03-17 14:21:40,614 INFO spawned: 'rsyslog' with pid 23
compute_1   | 2016-03-17 14:21:40,624 INFO spawned: 'slurmd' with pid 32
compute_1   | 2016-03-17 14:21:40,631 INFO spawned: 'munged' with pid 36
compute_1   | 2016-03-17 14:21:40,636 INFO spawned: 'watchpsutil' with pid 40
compute_1   | 2016-03-17 14:21:40,638 INFO spawned: 'sensu-server' with pid 44
compute_1   | 2016-03-17 14:21:40,639 INFO success: diamond entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
compute_1   | 2016-03-17 14:21:40,700 INFO exited: sensu-server (exit status 0; not expected)
compute_1   | 2016-03-17 14:21:41,627 INFO success: sensu-api entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
compute_1   | 2016-03-17 14:21:41,627 INFO success: sensu-client entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
compute_1   | 2016-03-17 14:21:41,627 INFO success: slurm_update entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
compute_1   | 2016-03-17 14:21:41,628 INFO success: rsyslog entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
compute_1   | 2016-03-17 14:21:41,628 INFO success: slurmd entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
compute_1   | 2016-03-17 14:21:41,630 INFO success: munged entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
compute_1   | 2016-03-17 14:21:41,631 INFO exited: diamond (exit status 0; expected)
compute_1   | 2016-03-17 14:21:41,727 INFO success: watchpsutil entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
compute_1   | 2016-03-17 14:21:41,728 INFO spawned: 'sensu-server' with pid 693
compute_1   | 2016-03-17 14:21:41,742 INFO exited: sensu-server (exit status 0; not expected)
compute_1   | 2016-03-17 14:21:42,656 INFO exited: sensu-api (exit status 0; expected)
compute_1   | 2016-03-17 14:21:43,812 INFO spawned: 'sensu-server' with pid 748
compute_1   | 2016-03-17 14:21:43,824 INFO exited: sensu-server (exit status 0; not expected)
slurmctld_1 | 2016-03-17 14:21:45,050 INFO spawned: 'slurmctld' with pid 866
slurmctld_1 | 2016-03-17 14:21:45,091 INFO exited: slurmctld (exit status 0; not expected)
compute_1   | 2016-03-17 14:21:45,650 INFO success: consul entered RUNNING state, process has stayed up for > than 5 seconds (startsecs)
compute_1   | 2016-03-17 14:21:47,000 INFO spawned: 'sensu-server' with pid 800
compute_1   | 2016-03-17 14:21:47,018 INFO exited: sensu-server (exit status 0; not expected)
compute_1   | 2016-03-17 14:21:47,047 INFO gave up: sensu-server entered FATAL state, too many start retries too quickly
slurmctld_1 | 2016-03-17 14:21:53,551 INFO spawned: 'slurmctld' with pid 981
slurmctld_1 | 2016-03-17 14:21:53,591 INFO exited: slurmctld (exit status 0; not expected)
compute_1   | 2016-03-17 14:21:55,652 INFO success: rsyslog-conf entered RUNNING state, process has stayed up for > than 15 seconds (startsecs)
slurmctld_1 | 2016-03-17 14:22:03,534 INFO spawned: 'slurmctld' with pid 1119
slurmctld_1 | 2016-03-17 14:22:03,570 INFO exited: slurmctld (exit status 0; not expected)
slurmctld_1 | 2016-03-17 14:22:13,937 INFO spawned: 'slurmctld' with pid 1263
slurmctld_1 | 2016-03-17 14:22:13,978 INFO exited: slurmctld (exit status 0; not expected)
slurmctld_1 | 2016-03-17 14:22:25,045 INFO spawned: 'slurmctld' with pid 1415
slurmctld_1 | 2016-03-17 14:22:25,082 INFO exited: slurmctld (exit status 0; not expected)
slurmctld_1 | 2016-03-17 14:22:37,589 INFO spawned: 'slurmctld' with pid 1593
slurmctld_1 | 2016-03-17 14:22:37,629 INFO exited: slurmctld (exit status 0; not expected)
slurmctld_1 | 2016-03-17 14:22:50,951 INFO spawned: 'slurmctld' with pid 1782
slurmctld_1 | 2016-03-17 14:22:50,985 INFO exited: slurmctld (exit status 0; not expected)
slurmctld_1 | 2016-03-17 14:23:05,760 INFO spawned: 'slurmctld' with pid 1976
slurmctld_1 | 2016-03-17 14:23:05,798 INFO exited: slurmctld (exit status 0; not expected)
slurmctld_1 | 2016-03-17 14:23:16,647 INFO exited: sensu-client (exit status 1; not expected)
slurmctld_1 | 2016-03-17 14:23:17,649 INFO spawned: 'sensu-client' with pid 2134
slurmctld_1 | 2016-03-17 14:23:19,084 INFO success: sensu-client entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
slurmctld_1 | 2016-03-17 14:23:21,320 INFO spawned: 'slurmctld' with pid 2173
slurmctld_1 | 2016-03-17 14:23:21,354 INFO exited: slurmctld (exit status 0; not expected)
slurmctld_1 | 2016-03-17 14:23:37,887 INFO spawned: 'slurmctld' with pid 2399
slurmctld_1 | 2016-03-17 14:23:37,922 INFO exited: slurmctld (exit status 0; not expected)
compute_1   | 2016-03-17 14:23:43,122 INFO exited: sensu-client (exit status 1; not expected)
compute_1   | 2016-03-17 14:23:43,477 INFO spawned: 'sensu-client' with pid 2395
compute_1   | 2016-03-17 14:23:44,824 INFO success: sensu-client entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
slurmctld_1 | 2016-03-17 14:23:55,099 INFO spawned: 'slurmctld' with pid 2642
slurmctld_1 | 2016-03-17 14:23:55,133 INFO exited: slurmctld (exit status 0; not expected)
slurmctld_1 | 2016-03-17 14:24:13,569 INFO spawned: 'slurmctld' with pid 2886
slurmctld_1 | 2016-03-17 14:24:13,604 INFO exited: slurmctld (exit status 0; not expected)

I took the freedom to format you quotes. I'll have a look.
This week-end I am on my way to a conference and I have to take care of the slides first.
I hope to get to it at the end of next week. Please remind me if I haven't done so.
Thx for the feed-back! I appreciate it...

Hey @ocramz,
I renamed the fig.yml file to docker-compose.yml and fixed Consul environment variables.
Problem was, the Consul was not running a server, which blew up the slurm.conf creation.
➜  docker-compute git:(master) docker-compose up -d                                                                                git:(master|)
Creating dockercompute_consul_1
Creating dockercompute_slurmctld_1
Creating dockercompute_compute_1
➜  docker-compute git:(master) docker exec -ti dockercompute_compute_1 sinfo                                                                                git:(master|)
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
all*         up   infinite      1   idle 2cafd9b00079
odd          up   infinite      1   idle 2cafd9b00079
➜  docker-compute git:(master) docker-compose scale compute=5                                                                                git:(master|)
Creating and starting 2 ... done
Creating and starting 3 ... done
Creating and starting 4 ... done
Creating and starting 5 ... done
➜  docker-compute git:(master) docker exec -ti dockercompute_compute_1 sinfo                                                                                git:(master|)
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
all*         up   infinite      1   idle 2cafd9b00079
all*         up   infinite      1    unk e3586b65af05
odd          up   infinite      1   idle 2cafd9b00079
odd          up   infinite      1    unk e3586b65af05
➜  docker-compute git:(master) docker exec -ti dockercompute_compute_1 sinfo                                                                                git:(master|)
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
all*         up   infinite      2   idle 0a0c3ede689e,ee478ce106b1
all*         up   infinite      3    unk 2cafd9b00079,6cb0e426299f,e3586b65af05
odd          up   infinite      2   idle 0a0c3ede689e,ee478ce106b1
odd          up   infinite      2    unk 2cafd9b00079,e3586b65af05
even         up   infinite      1    unk 6cb0e426299f
➜  docker-compute git:(master) docker exec -ti dockercompute_compute_1 sinfo                                                                                git:(master|)
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
all*         up   infinite      5   idle 0a0c3ede689e,2cafd9b00079,6cb0e426299f,e3586b65af05,ee478ce106b1
odd          up   infinite      4   idle 0a0c3ede689e,2cafd9b00079,e3586b65af05,ee478ce106b1
even         up   infinite      1   idle 6cb0e426299f
➜  docker-compute git:(master) docker exec -ti dockercompute_compute_1 srun -N5 hostname                                                                                git:(master|)
ee478ce106b1
0a0c3ede689e
6cb0e426299f
e3586b65af05
2cafd9b00079
➜  docker-compute git:(master)

Please close the issue if it is solved for you as well.
Thx again for the feed-back - I am depending on it!

I enhanced the README, if you could walk through it and check if it's consistend... I am a bit biased. :)


pycairo: fix build with Python 3.6

Addresses #24501.
Motivation for this change
pycairo was not building using Python 3.6
Things done
Apply the same patch as for Python 3.5 so that this builds correctly.

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[x] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Thanks. I've pushed d9b36c36c5e56c6e2e70f620313008c6ed2407a1


Asset landing page links

Once Carbon React is indexed, update the assets landing page so the feature card's href takes you to that library.

@andreancardona I updated the description and set an issue dependency. This accurate?


Backend Team's Company Business Card Design

Business card design for Backend Team's company "Posinowa".
The size of the card should be 8,5 x 5 cm.
There should be a photo of OctopOSPrime website on the back of the card and contact information and the logo on the front.
Desired design and color codes.
#b8bbc7
#141e46


Add support for rankers in retrieve and rank

@kshasan will be testing the changes and updating the documentation. We should not merge this until he is done.

@kshasan seems like there are some broken tests


Redelivery count field addition to message

Fix for https://github.com/nats-io/stan.java/issues/155
As this is supported by server, just need to add field for redeliveryCount. Tested locally within my project.

I'm not sure the build failures on this PR are relate to the change.
Can anyone please review it?

bump – any news on this?
is there maybe something where I could support?

I'm not sure the build failures on this PR are relate to the change.
Can anyone please review it?

Should only be due to version. Otherwise it works, I have tried it locally...
I let version for repo owners to set it as they wish before releasing.

ping again…
Would it be possible to bump the version number? We would actually need this feature.
But aside from from just the version number – any chance this also gets released soon?


Controls being cleared before being triggered

The grace period seems off, or at least controls get triggered or cleared before they should even enter the loop — here the ✕ control is cleared before it should even be known by the loop, no ?
console.play LEFT LEFT LEFT LEFT CROSS
  # INFO : running command: console.play ← ← ← ← ✕
  # INFO : Keeping PSX Control ← Triggered for 12 cycles
  # INFO : Keeping PSX Control ✕ Cleared for 12 cycles
  # INFO : Keeping PSX Control ← Triggered for 11 cycles
  # INFO : Keeping PSX Control ✕ Cleared for 11 cycles
  # INFO : Keeping PSX Control ← Triggered for 10 cycles
  # INFO : Keeping PSX Control ✕ Cleared for 10 cycles
  # INFO : Keeping PSX Control ← Triggered for 9 cycles
  # INFO : Keeping PSX Control ✕ Cleared for 9 cycles
  # INFO : Keeping PSX Control ← Triggered for 8 cycles
  # INFO : Keeping PSX Control ✕ Cleared for 8 cycles
  # INFO : Keeping PSX Control ← Triggered for 7 cycles
  # INFO : Keeping PSX Control ✕ Cleared for 7 cycles
  # INFO : Keeping PSX Control ← Triggered for 6 cycles
  # INFO : Keeping PSX Control ✕ Cleared for 6 cycles
  # INFO : Keeping PSX Control ← Triggered for 5 cycles
  # INFO : Keeping PSX Control ✕ Cleared for 5 cycles
  # INFO : Keeping PSX Control ← Triggered for 4 cycles
  # INFO : Keeping PSX Control ✕ Cleared for 4 cycles
  # INFO : Keeping PSX Control ← Triggered for 3 cycles
  # INFO : Keeping PSX Control ✕ Cleared for 3 cycles
  # INFO : Keeping PSX Control ← Triggered for 2 cycles
  # INFO : Keeping PSX Control ✕ Cleared for 2 cycles
  # INFO : Keeping PSX Control ← Triggered for 1 cycles
  # INFO : Keeping PSX Control ✕ Cleared for 1 cycles
  # INFO : Clearing PSX Control ←
  # INFO : Clearing PSX Control ✕
  # INFO : Keeping PSX Control ✕ Triggered for 3 cycles
  # INFO : Keeping PSX Control ✕ Triggered for 2 cycles
  # INFO : Keeping PSX Control ✕ Triggered for 1 cycles
  # INFO : Clearing PSX Control ✕

Not really a bug, but kinda fixed in the last commit with the refactoring of logs


Accurate Tensor.device for TFEager backends

This modifies Tensor.device for TFEager backends to retrieve device details from the underlying eager libraries. This is more accurate than returning Device.defaultTFEager and reflects the actual location of eager operations.
This was tested by building a CUDA toolchain and verifying that TFE_TensorHandleDeviceName() returns:
/job:localhost/replica:0/task:0/device:GPU:0

and a GPU device is returned by Tensor.device:
Device(kind: .GPU, ordinal: 0, backend: .TF_EAGER)

On a device without GPU, TFE_TensorHandleDeviceName() returns:
/job:localhost/replica:0/task:0/device:CPU:0

and a CPU device is returned by Tensor.device:
Device(kind: .CPU, ordinal: 0, backend: .TF_EAGER)

Fixes tensorflow/swift#524.

Different approach coming. Closing this PR


poky: update submodule from jethro-14.0.1 to jethro-14.0.2

Signed-off-by: Fathi Boudra<EMAIL_ADDRESS>

@agherzan @willnewton dependency for https://github.com/resin-os/meta-resin/pull/629

Can one of the admins verify this patch?

Can one of the admins verify this patch?

@willnewton already pushed a morty update. Wouldn't that fix this issue?

@agherzan I haven't tried with Will's PR for Morty. I just tried a less intrusive change to confirm we need a newer kernel-arch.bbclass. If you're fine with the upgrade from Jethro to Morty, that works for me. Sugar on top, we can get QEMU Aarch64 by moving to Morty.

I thinking moving to morty is a better long term fix. So I'd say we should go that way.

The poky submodule has been upgraded to morty.


Fix build on ubuntu with chris-lea repository.

We are moving away from the SCons build system in favor of node-waf. Please try the develop branch and see if that doesn't fix your build issues.

You are right it's work great with develop version.


HtmlInfoWindow to follow marker on position change

I'm submitting a ...  (check one with "x")
[x] question
[ ] any problem or bug report
[ ] feature request
The plugin version:  (check one with "x")
[ ] 2.0-beta3 (github)
[x] 2.0 (npm)
If you choose 'problem or bug report', please select OS:  (check one with "x")
[x] Android
[x] iOS
Current behavior:
Is there any way for HtmlInfoWindow to follow marker when marker position change?
HtmlInfoWindow position is only updated when map is changed.
i am using latest stable version.

Please create a demo project in order to reproduce your issue.

It seems the plugin works fine (using the multiple_maps branch, and the PR)
import { Component } from '@angular/core';
import { IonicPage, NavController, NavParams } from 'ionic-angular';
import {
  GoogleMaps,
  GoogleMap,
  GoogleMapsEvent,
  HtmlInfoWindow,
  Marker,
  ILatLng
} from '@ionic-native/google-maps';

@IonicPage()
@Component({
  selector: 'page-new-html-info-window',
  templateUrl: 'new-html-info-window.html',
})
export class NewHtmlInfoWindowPage {
  map: GoogleMap;

  constructor(
    public navCtrl: NavController,
    public navParams: NavParams,
    private googleMaps: GoogleMaps) {
  }

  ionViewDidLoad() {
    console.log('ionViewDidLoad NewHtmlInfoWindowPage');
    this.loadMap();
  }

  loadMap() {
    this.map = this.googleMaps.create('map_canvas');
    this.map.one(GoogleMapsEvent.MAP_READY).then(() => {
      let htmlInfoWindow = new HtmlInfoWindow();

      let html: string = [
        'This is Html InfoWindow',
        '
',
        '<button onclick="javascript:alert(\'clicked!\');">click here</button>',
      ].join("");
      htmlInfoWindow.setContent(html);

      this.map.addMarker({
        position: {lat: 0, lng: 0},
        draggable: true
      }).then((marker: Marker) => {

        marker.on(GoogleMapsEvent.MARKER_CLICK).subscribe(() => {
          htmlInfoWindow.open(marker);
        });
        marker.trigger(GoogleMapsEvent.MARKER_CLICK);

      });
    });
  }
}

Maybe i described my problem wrongly.
I do not touch or move the map.
Only clicked on marker once (to activate htmlinfowindow)
Marker is object that is in constant motion for example, and update the position every X seconds.
All i want is when marker change position, htmlinfowindow to track marker,
(see gif below)
This is very basic pure cordova demo that reproduce my problem.
https://github.com/stormwin/maptest

Ah, I see. HtmlInfoWindow does not follow for that case. You need to execute htmlInfoWindow.open(marker) again when the marker position is moved, or use the regular infoWindow

Thanks, it work with htmlInfoWindow.open(marker)


Git clean before and after checkout

Coincidentally, my first go code!
Resolves #417

Considering this is your first Go code, it's pretty much spot on! However I don't think this is the solution to this problem, so I'll close for now. See my comment here for more info! https://github.com/buildkite/agent/issues/417#issuecomment-267479867
I hope there's another way!


Tried one more time to upgrade 4.5 > 4.6

Tried one more time to upgrade 7.5 > 7.6.
The Nodes have been upgraded (see attached).
But after waiting for hour and half authentication, console , monitoring & operator-lifecycle-manager-packageserver operators seem stalled (see below)
I generated a log bundle and took snapshots (oc get nodes & oc get operators) of the cluster state.
The site didn't allow me to upload the full tar bundle, so I broke it up into individual zip file
NOTE: operator-lifecycle-manager-packageserver seems to keep restarting every few seconds

bootstrap.zip
okd4-control-plane-0.okd4-2.apptecinc.com.zip
okd4-control-plane-1.okd4-2.apptecinc.com.zip
okd4-control-plane-3.okd4-2.apptecinc.com.zip
failed-units.zip
rendered-assets.zip
resources.zip
unit-status.zip

HAPROXY Reporting everything is running

Nothing has changed in over three hours

After 4 Plus Hours, no change to Operator status.
Going to shutdown the cluster and restart and see what happens

ShutDown & Restarted The Cluster without any difference.
All the nodes come up and are in the ready state.
But the same operators are stalled.
I created another log bundle and like before needed to break it up to upload
Going to restore my cluster back to 7.5 and wait for a solution

bootstrap.tar.gz
okd4-control-plane-0.okd4-2.apptecinc.com.tar.gz
okd4-control-plane-1.okd4-2.apptecinc.com.tar.gz
okd4-control-plane-3.okd4-2.apptecinc.com.tar.gz
rendered-assets.tar.gz
resources.tar.gz
unit-status.tar.gz
failed-units.txt

I guess you mean you tried to upgrade from OKD 4.5 > OKD 4.6 ?

I tried and restored and then tried again and restored, this was my last shot at it.

I had the exact same behavior as described here multiple times with fresh installs of 4.6.0-0.okd-2020-11-27-200126 on bare metal. Exact behavior as above each time.

Tried the newest release (see below), same issue authentication, console , monitoring never comes up
oc adm upgrade --force --to=4.5.0-0.okd-2020-10-15-235428 --allow-upgrade-with-warnings

I was stupid to start this update on our cluster without doing an etcd backup.. is there anyway to recover from this without re-setup'ing the cluster? if a new release comes out? or is there any workaround?

I backup the whole cluster, it was pretty easy to get back to 4.5. Went through this exercise at least 4 times.

I'm really not the person to ask, I don't have that much background when it comes to OKD I don't want to give you the wrong info. I would open up a new thread and ask that question and see what comes out of that.

Dupe of https://github.com/openshift/okd/issues/430 - 4.5 -> 4.6 upgrade with OpenshiftSDN is currently broken


Facebook usernames corrected (issue #51)

Facebook usernames corrected.
Problem was that onCompleted() in newmerequest() was never called.

@shubhamgrg04 It'll take me sometime to check this PR.
I'll suggest you work on this issue in the meantime: https://github.com/privly/privly-android/issues/30
Previous relevant discussion : https://github.com/privly/privly-android/pull/53

@vshivam I am cleaning up pull requests. Since your master has diverged, should we close this one?

@smcgregor Yep, I guess so.


Reorganized the repo, moved the new data_api code to the top

Simplifying installation of the new data_api code by migrating it to the top, pushed the previous top level code under experiments.  Tried to keep the docs folder for ghpages, travis and coveralls files, requirements.txt, etc.

Travis is going to fail here because the tests currently are dependent on having a deployment of workspace, kbase auth token, etc.

Merging to move things forward.


Add System.version

References https://github.com/wren-lang/wren-cli/issues/95
System.version

It returns WREN_VERSION_NUMBER. Was thinking of retrieving the string, or having version.major, version.minor, but I think keeping it dead simple like this is best.

I think it's better to decompose the version. Not sure if a list or a custom class, though tend towards a class.

Could do this to make it a map...
  ObjMap* map = wrenNewMap(vm);
  wrenMapSet(vm, map, wrenNewString(vm, "major"), wrenNumToValue(WREN_VERSION_MAJOR));
  wrenMapSet(vm, map, wrenNewString(vm, "minor"), wrenNumToValue(WREN_VERSION_MINOR));
  wrenMapSet(vm, map, wrenNewString(vm, "patch"), wrenNumToValue(WREN_VERSION_PATCH));
  RETURN_OBJ(map);

System.version["minor"]

Both ineffecient, not type-safe and unclear.

Note they're not much less efficient then a class and the version is not used in hot code paths, efficiency is not super relevant.
A class also would allocate, but elegance wise a System.version.minor or similar would be better. A static method that returns a constant would be ideal, but requires a bit more thinking. It would also be useful to have a canonical version string exposed on the same object.
Also undecided if System is the spot for it...

It would also be useful to have a canonical version string exposed on the same object.

Can override toString.

Agreed that a static class would likely be best syntax-wise :+1:
System.version.major
System.version.minor
System.version.patch
System.version.toString

While I agree a System.version should exist, the decomposition class is a little too much to exist as a class in core. I can explain the details, but the addition of the class in core would waste of too much global symbols for a too narrowed usage.

I can explain the details, but the addition of the class in core would waste too many global symbols for a too narrowed usage.

Could you please explain a bit further?  Is this because of the 64k limit on classes/methods (I forget details)... I've seen some Wren classes with 100s of methods just serving as enums... so some people are acting like the supply is limitless. :-)

Would System.versions["wren"].toString be a good idea?
System.register("own_thingy", [1, 2, 6])
System.register("own_thingy", [1, 3, 6]) // abort: own_thingy already registered

basically adding an option to add multiple versions and check if "components" exist

While I agree a System.version should exist, the decomposition class is a little too much to exist as a class in core. I can explain the details, but the addition of the class in core would waste of too much global symbols for a too narrowed usage.

If the symbols limit limits us, then we should lift it (for example, using 4 bytes for symbols instead of two). This should not be a reason to worse design.

Lets starts with global symbols and then methods.
Global symbols (like module top level class/variable) of the core module has the side effect to linearly infect sub-modules. So basically in terms of numbers, if n is the numbers of symbols in core an m is the numbers of loaded module, there is exactly n*m entries already taken, by the auto-loading of core. This is by design as the way import works, and as an interesting effect trying to packing all symbols of a module next to each other for to reduce cache misses.
Methods on other hands is use a shared global virtual table layout. So basically each time you add a new method name, you expand the lookup space for every object in the system. While this is good organisation wise, you want to keep the number low, or at least make sure that the first entered entries are the hottest in term of usage, again to minimize cache misses.
It means you want to keep core as small as possible, and that it reuse the maximum number of method names. That way one user could make room for its own class & protocols nearest the hottest cache space.
I understand the impression of having an unlimited space. But I would like to avoid a situation where core will be forced to be shrunk. The problems lies in the fact that everyone to put a lots of stuff in core, while exploding the number of modules defining a single class on the user side for readability/clarity/maintenance. This makes a space high taxing cost per module that is pretty alarming.

The modules' n*m is not a problem, since there are little modules and little core names.
The real problems is methods, where adding a new method name to the core means adding it to every class ever defined after, which pretty much means every user-defined class. This uses some space. However, this is true also to user-defined class. I remembers some time ago I measured the space overhead of a new class if you use all @PureFox48's RosettaCode modules, and got to some KiB IIRC. This is the overhead of the symbols approach Wren uses. We need to remember, however, that this is per-class and not per-instance, so this is still quite low overhead. And again, I don't think this should influence our design decisions.

The better solution to this problem would be to do a local import from an auxiliary core module. It would reduce the speed of the access to some functions, but would allow to shrink a little the size of core.
This proposition is a good example that would benefit from it, we want a class that ease version access, but its usage is to much limited, that we don't want core to the implementation and details when we don't use that functionality.

I do support a separate module, say "version" with a class:
class Version {
  foreign static major
  foreign static minor
  foreign static patch
  toString { "%(major).%(minor).%(patch)" }
}

But not because of why you describe, because exposing a class Version (or even WrenVersion) in the core would pollute the global namespace with a class that is rarely used.

@ChayimFriedman2 it is pollution in both cases, you see from the accessibility point of view, I see it from the occupation it takes.

Lets starts with global symbols and then methods. ... ... ...

Wow, so glad I asked. Thanks for the detailed write-up.  So much more complex than I imagined.

Global symbols (like module top level class/variable) of the core module has the side effect to linearly infect sub-modules.

So just to be clear, this is a unique issue of the Core module because it is auto-injected into every single other module (to make them available), correct?  IE, if we have large outside-core modules they don't suffer from this in the same way as they would only to added to things they were explicitly imported into.  Did I get it right?
Couldn't analysis be done at compile-time of every module such that only Core global symbols that were actually used/referenced were imported rather than just importing them all by default?

Couldn't analysis be done at compile-time of every module such that only Core global symbols that were actually used/referenced were imported rather than just importing them all by default?

The answer to the question "Can we analyze ...?" is almost always "Not with a single pass compiler".

"Not with a single pass compiler".

Why do we need multiple passes?  As we lex/parser the code we just keep track of which symbols have been referenced... at the very end import only those symbols into the fresh new module. Or you could add them to the symbol table as they were seen during the parsing.  No?

Because we already wrote them into the symbol table and emit bytecode based on this assumption.

I don't think you answered my question at all.

Because we already wrote them into the symbol table

Before the source of a NEW module is parsed this cannot be true since that source has never even been seen yet.  Well I suppose perhaps it could be done preemptively before parsing beings - but if so I'm asking WHY... why can't the Core symbols be added as they are seen during the parsing process.  I don't see that you've explained this.

Oh, you meant appending the core instead if prepending it?
That can't be done for another reason. Imagine:
System.print("hello wren")

Yes, the simplest program. It won't work, for the same reason the following program does not:
Printer.print("hello wren")
class Printer {
  print(msg) { System.print(msg) }
}

Causing Null does not implement print(_), because until we reached Printer's declaration it's null.

Oh, you meant appending the core instead if prepending it?

Yes. I'm only now learning how these pieces of the compiler work.  It's clear now why we can't append it at the end (we need those symbols for byte code output), but why can't we append it incrementally as we encounter symbols?

Starting out the table is empty.
When we see System for the very first time that symbol from core is added to the modules symbol table.

First, it will require a very tight coupling between the compiler and the core, meaning that changing something in the core will probably require changing the compiler too. This is very bad.
Second, this is impossible too, because of the nature of single pass compilers. When we see that we need some symbol, we may be in the middle of an expression, and we already emitted its start, so we cannot pause.

Ok, we took this onto the Discord for a bit: https://discord.com/channels/484796661751873554/484796759437213716/838402615343316993
And now I have a better idea if what is happening in the compiler.  We need the class definition byte code outputted BEFORE we encounter references later that need to be resolved.  IE, for a given module:
// Prepend all core libs bytecode
CODE_CLASS
CODE_METHOD_INSTANCE
CODE_METHOD_STATIC
...
CODE_END_CLASS
CODE_CLASS
...
CODE_END_CLASS
CODE_CLASS
...
CODE_END_CLASS
// non-core module byte code begins here

And all those CODE_CLASS byte codes when executed fill up our symbol table, the n*m problem.  So what about changing the output to something like:
// RESERVE SPACE for core libs byte code
// only a single class was referenced, so only a single class is output
CODE_CLASS
CODE_METHOD_INSTANCE
CODE_METHOD_STATIC
...
CODE_END_CLASS
CODE_JUMP BEGIN
NO-OP
NO-OP
NO-OP
NO-OP
NO-OP
BEGIN:
// non-core byte code begins here

Instead of emitting byte code for the entire Core we store a second pointer to the current position in the byte code stream. I'll call it the "core header".
Next we emit a bunch of NOOPs (I don't think we have a NOOP, but this could be anything to waste space that doesn't pollute the symbol table) to fill the space we MIGHT need for the core class definitions and any code
We continue parsing and emitting byte code at the BEGIN: label
When we come across a reference to a core class for the first time, we emit that classes definition into the "core header"

At the end we'll either have a full header (ie, every core module was actually used - so we need each and every global symbol created) or we'll have a bunch of empty space. You might object this is wasting space in the byte stream, but equal space is wasted in BOTH cases.  It's either filled with NOOPs or it's filled with class definitions that we will never use that only serving to pollute the symbol table.
@ChayimFriedman2 Was worried about the complexity of this (and it's definitely a valid concern) but said it was an interesting idea so I wanted to post it here so others could think on it.

It maybe that my idea is impossible for reasons not yet understood - and if so, then it is what it is.  Even if possible I'm not suggesting we rush out to implement this just so we can have the version API of our dreams, but if one day comes when programs are larger, Core is larger and we hit the ceiling and we're debating having to shrink Core to survive... perhaps at that point some investment into this idea might prove worthwhile.
Yet... if those more familiar with the compiler internals look and go "oh we could totally do that, that's a viable path forward when needed" then perhaps we could ease up on how concerned we are about polluting core with additional modules knowing that at any time we have the easy fix in our back pocket.

This is something I would like to experiment with when I will have time, but the version API should be in a different module anyway because of name pollution, and the potential memory save does not worth it.

but the version API should be in a different module anyway

This is referring back to what mhermier suggested, right? :

The better solution to this problem would be to do a local import from an auxiliary core module.

Making the version symbols private to core rather than shared with all other modules.

Note that the core module has no bytecode in other modules, not sure why bytecode was mentioned in context. The core is executed once before anything else during vm initialization, the bytecode already exists before any other code is executed. See here, which executed wrenInterpet.
When a module is loaded the names from the core are simply declared as variables pointing to the existing classes

@joshgoebel about appending core as they are used: with some reserve it is possible to do so. There are 2 critical actions to add to the compiler:

before defining any new variable in the global scope, a conflict with the core module must be performed.
if a lookup for a variable in the module scope fails we should search in core.
The first one is trivial, since it result in error, the result will get discarded so it is not a big deal.
The Second one is the problematic one. Since lookup can happens everywhere, we have to register these access, to prepend loading code in the bytecode.

@ruby0x1 basically we are discussing about moving from an implicit loading of core to an automated loading of core, and it results in the module bytecode being responsible of getting core variables in the submodule. (If I understood correctly)

Note that the core module has no bytecode in other modules, not sure why bytecode was mentioned in context.

Sorry.  That would quite likely be my misunderstanding of the moving pieces.

The core is executed once before anything else during vm initialization, the bytecode already exists before any other code is executed. ... When a module is loaded the names from the core are simply declared as variables pointing to the existing classes

This makes sense... I realized that we only need the variable reference, but I wasn't sure how that is accomplished, I thought perhaps there are bytecodes to do that - and what's what I was trying to express.

basically we are discussing about moving from an implicit loading of core to an automated loading of core

Yes, although I'd perhaps call it JIT. Lets not add them all prematurely, let's first wait until we see they are actually referenced/needed and then add the variable reference at that time.

I think I'm going to close this as there are still some design decisions that need to be worked out. Thanks for the feedback, all! :+1:


qemu: 8.2.2 -> 9.0.0

Description of changes

ChangeLog
Planning (ETA: 2024-04-16)

The Darwin patches have stopped applying again. (cc @willcohen)
Things done

Built on platform(s)

[ ] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Might it be time to set MACOSX_DEPLOYMENT_TARGET to something >= 10.14 for qemu?

I don't use or understand macOS, so I don't really have an opinion, except that something needs to be done in the next two weeks.

I'm told the fixes needed to make this work on darwin are currently in staging. Haven't been able to do a staging bootstrap yet to test this.

staging-next has merged now, so am I understanding correctly that if I rebase this it should build on Darwin without the patches?

Still not building on x86_64-darwin.  Is there something else that needs to happen?

I no longer have access to an x86 mac (moved on to arm64) and so can't actually run the relevant builds. However, unless https://github.com/NixOS/nixpkgs/issues/101229 and similar issues happen, it would surprise me to not need these anymore. The patches are basically undoing 10.13+ stuff that is being added to QEMU to allow it to keep building on x86. At this point, 10.13 came out in 2017, and I think we're reaching the point where it's unreasonable to backport software to require an OS's API that has to be 7+ years old.
If only because I don't know anyone else who is invested in qemu on darwin x86 on nix, I'm not sure how to test that functionality short of me trial-and-erroring blindly by trying to fix diffs and with ofborg as my guinea pig.

staging-next has merged now, so am I understanding correctly that if I rebase this it should build on Darwin without the patches?

No, I'm told it missed this staging cycle.

Have tried with the new staging-next cycle, and still no luck :(

9.0 (non RC) is out now, if you can and want to pursue this.

I still need somebody to tell me what to do about x86_64-darwin, unless we just mark it broken?

Unless we can find someone with an x86-darwin machine who wants to rebase and test, I think broken is the best bet, but that's just me.

@ofborg test cage cagebreak cloud-init-hostname cloud-init mtp os-prober phosh sway systemd-initrd-luks-fido2 tinywl virtualbox

Ugh, apparently QEMU is release-critical for x86_64-darwin, so we can't just mark it broken without blocking the channel.
@roberth @Enzime seems like you were involved in that — can you help here?

If it's okay to get it removed out of being release critical, that makes the most sense to me. If it's considered release critical, then we'll need to find a volunteer from darwin maintainers who's still on x86 and doesn't mind rebasing the patches (not pinging them yet...)

@NixOS/darwin-maintainers does anybody care about QEMU on x86_64-darwin?  If nobody steps up there's not much we can do apart from remove it from the tested set…

Their is an effort to port nixos test on macos so I think we should repair it. I will try to fix it.

I'm also looking into this but won't have time to finish until tomorrow. Feel free to beat me to it.

I'm also working on this.

Thanks a lot @wegank!

libvirt doesn't build (with sandbox enabled) on x86_64-darwin. It doesn't build on master
error: builder for '/nix/store/7h0ma9nwqn2kvk2lazq6w2mrwslf65ip-python3.11-nixops-gce-unstable-2023-05-26.drv' failed with exit code 1;
       last 10 log lines:
       > Creating a wheel...
       > * Getting build dependencies for wheel...
       > * Building wheel...
       > Successfully built nixops_gcp-1.0-py3-none-any.whl
       > Finished creating a wheel...
       > Finished executing pypaBuildPhase
       > Running phase: pythonRuntimeDepsCheckHook
       > Executing pythonRuntimeDepsCheck
       > Checking runtime dependencies for nixops_gcp-1.0-py3-none-any.whl
       >   - cryptography==40.0.1 not satisfied by version 42.0.5
       For full logs, run 'nix log /nix/store/7h0ma9nwqn2kvk2lazq6w2mrwslf65ip-python3.11-nixops-gce-unstable-2023-05-26.drv'.
error: builder for '/nix/store/d3z4nx44bqzj2l2d5zga6q1p1mfbg4rc-python3.11-nixops-hetzner-unstable-2022-04-23.drv' failed with exit code 1;
       last 10 log lines:
       > Creating a wheel...
       > * Getting build dependencies for wheel...
       > * Building wheel...
       > Successfully built nixops_hetzner-1.0-py3-none-any.whl
       > Finished creating a wheel...
       > Finished executing pypaBuildPhase
       > Running phase: pythonRuntimeDepsCheckHook
       > Executing pythonRuntimeDepsCheck
       > Checking runtime dependencies for nixops_hetzner-1.0-py3-none-any.whl
       >   - typing-extensions<4.0.0,>=3.7.4 not satisfied by version 4.11.0
       For full logs, run 'nix log /nix/store/d3z4nx44bqzj2l2d5zga6q1p1mfbg4rc-python3.11-nixops-hetzner-unstable-2022-04-23.drv'.
error: builder for '/nix/store/4pay3bg9f3bjgdgbdmb8j6pjkfyffzy1-python3.11-nixops-hetznercloud-unstable-2023-02-19.drv' failed with exit code 1;
       last 10 log lines:
       > * Getting build dependencies for wheel...
       > * Building wheel...
       > Successfully built nixops_hetznercloud-0.1.3-py3-none-any.whl
       > Finished creating a wheel...
       > Finished executing pypaBuildPhase
       > Running phase: pythonRuntimeDepsCheckHook
       > Executing pythonRuntimeDepsCheck
       > Checking runtime dependencies for nixops_hetznercloud-0.1.3-py3-none-any.whl
       >   - hcloud==1.18.2 not satisfied by version 1.35.0
       >   - typing-extensions<4.0.0,>=3.7.4 not satisfied by version 4.11.0
       For full logs, run 'nix log /nix/store/4pay3bg9f3bjgdgbdmb8j6pjkfyffzy1-python3.11-nixops-hetznercloud-unstable-2023-02-19.drv'.
error: builder for '/nix/store/jcdw0nxwwn530l4gbzipin0dwz5qhpav-python3.11-qemu-<IP_ADDRESS>a1.drv' failed with exit code 1;
       last 10 log lines:
       > Traceback (most recent call last):
       >   File "/nix/store/lfsz3kkk1gbs2cq58lkyn9f8mfdijin6-python3.11-qemu-<IP_ADDRESS>a1/bin/.qom-wrapped", line 6, in <module>
       >     from qemu.utils.qom import main
       >   File "/nix/store/lfsz3kkk1gbs2cq58lkyn9f8mfdijin6-python3.11-qemu-<IP_ADDRESS>a1/lib/python3.11/site-packages/qemu/utils/qom.py", line 41, in <module>
       >     from .qom_fuse import QOMFuse
       >   File "/nix/store/lfsz3kkk1gbs2cq58lkyn9f8mfdijin6-python3.11-qemu-<IP_ADDRESS>a1/lib/python3.11/site-packages/qemu/utils/qom_fuse.py", line 48, in <module>
       >     import fuse
       >   File "/nix/store/2gkw9jgh3f533lydjsf3n1ipxwdzhglx-python3.11-fusepy-3.0.1/lib/python3.11/site-packages/fuse.py", line 115, in <module>
       >     raise EnvironmentError('Unable to find libfuse')
       > OSError: Unable to find libfuse
       For full logs, run 'nix log /nix/store/jcdw0nxwwn530l4gbzipin0dwz5qhpav-python3.11-qemu-<IP_ADDRESS>a1.drv'.
error: builder for '/nix/store/7s782bsqjapyzf0fn303x68wm5cwzjbd-diffoscope-265.drv' failed with exit code 1;
       last 10 log lines:
       >     def test_diff(differences):
       >         expected_diff = get_data("wasm_expected_diff")
       > >       actual_diff = differences[0].unified_diff
       > E       IndexError: list index out of range
       >
       > tests/comparators/test_wasm.py:50: IndexError
       > =========================== short test summary info ============================
       > FAILED tests/comparators/test_wasm.py::test_diff - IndexError: list index out of range
       > = 1 failed, 624 passed, 55 skipped, 15 deselected, 1 xfailed, 1 xpassed in 7929.02s (2:12:09) =
       > /nix/store/79qly7vi6mjpmbmgivn4dfzl69f0f1sy-stdenv-darwin/setup: line 1588: pop_var_context: head of shell_variables not a function context
       For full logs, run 'nix log /nix/store/7s782bsqjapyzf0fn303x68wm5cwzjbd-diffoscope-265.drv'.
error: builder for '/nix/store/08vypajjpzwjvnaavyixc55m6dqhb4kx-libvirt-10.0.0.drv' failed with exit code 1;
       last 10 log lines:
       >
       >
       > Ok:                 108
       > Expected Fail:      0
       > Fail:               0
       > Unexpected Pass:    0
       > Skipped:            13
       > Timeout:            1
       >
       > Full log written to /private/tmp/nix-build-libvirt-10.0.0.drv-0/source/build/meson-logs/testlog.txt
       For full logs, run 'nix log /nix/store/08vypajjpzwjvnaavyixc55m6dqhb4kx-libvirt-10.0.0.drv'.
error: 1 dependencies of derivation '/nix/store/z32kp9vrfih3dknv42yr1fhhbw15wc8i-libvirt-glib-5.0.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/53bx2n82bcaz5syn64vs5l4h8xvm8dqd-mgmt-unstable-2022-10-24.drv' failed to build
error: 1 dependencies of derivation '/nix/store/4y9sj44dfa9mi587mc5pvab6r9q76bgy-ocaml-libvirt-<IP_ADDRESS>.drv' failed to build
error: 1 dependencies of derivation '/nix/store/mhalk47sj12mvdzs3izdwzwbmjjq9ik3-python3.11-libvirt-10.0.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/pxkp9g9lzgb262j7nx67ssm5mhylkha2-ruby3.1-ruby-libvirt-0.8.2.drv' failed to build
error: 1 dependencies of derivation '/nix/store/cns1i5nmwcic7gyrnhc20ah3prcfknp1-ruby3.2-ruby-libvirt-0.8.2.drv' failed to build
error: 1 dependencies of derivation '/nix/store/sy0a9yilhpd5ajrq4rl4zjqxzkbjaslw-ruby3.3-ruby-libvirt-0.8.2.drv' failed to build
error: 1 dependencies of derivation '/nix/store/vl5cbc0ihds0cl36n081vynvr6rjf68s-python3.11-nixops-libvirtd-unstable-2023-09-01.drv' failed to build
error: 3 dependencies of derivation '/nix/store/ma6crmv3r1rp9m7016w8ncw0j7zqkkb1-virt-manager-4.1.0.drv' failed to build
error: 2 dependencies of derivation '/nix/store/92i3g6znggb6972c27h8igic7scaz4d4-virt-viewer-11.0.drv' failed to build
error: 2 dependencies of derivation '/nix/store/c1agaklfgpbc4bf9bk6y1bdizqsgqfmx-virt-viewer-11.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/sk9skjphqjppy1k01p2gnf1mgcn14zxb-appvm-unstable-2021-12-20.drv' failed to build
error: 4 dependencies of derivation '/nix/store/mkjn9ny88zjn0v4y3i7g8s1x78hqinqs-nixops-unstable-2024-02-28.drv' failed to build
error: builder for '/nix/store/535c3f1zvw6gypijm3by9q3i9xg2bsgf-python3.12-cot-2.2.1.drv' failed with exit code 1;
       last 10 log lines:
       >     return get_versions()["version"]
       >            ^^^^^^^^^^^^^^
       >   File "/private/tmp/nix-build-python3.12-cot-2.2.1.drv-0/cot-2.2.1/versioneer.py", line 1408, in get_versions
       >     cfg = get_config_from_root(root)
       >           ^^^^^^^^^^^^^^^^^^^^^^^^^^
       >   File "/private/tmp/nix-build-python3.12-cot-2.2.1.drv-0/cot-2.2.1/versioneer.py", line 342, in get_config_from_root
       >     parser = configparser.SafeConfigParser()
       >              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       > AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. Did you mean: 'RawConfigParser'?
       > /nix/store/79qly7vi6mjpmbmgivn4dfzl69f0f1sy-stdenv-darwin/setup: line 1588: pop_var_context: head of shell_variables not a function context
       For full logs, run 'nix log /nix/store/535c3f1zvw6gypijm3by9q3i9xg2bsgf-python3.12-cot-2.2.1.drv'.
error: 16 dependencies of derivation '/nix/store/h6grs7gbcvflpknipid22d1pyafrbljs-review-shell.drv' failed to build

nix build nixpkgs#libvirt --out-link /dev/null --rebuild
error: builder for '/nix/store/fwngvfmylb17js2p7r96fkj5s2phfj87-libvirt-10.0.0.drv' failed with exit code 1;
       last 10 log lines:
       >
       >
       > Ok:                 108
       > Expected Fail:      0
       > Fail:               0
       > Unexpected Pass:    0
       > Skipped:            13
       > Timeout:            1
       >
       > Full log written to /private/tmp/nix-build-libvirt-10.0.0.drv-1/source/build/meson-logs/testlog.txt
       For full logs, run 'nix log /nix/store/fwngvfmylb17js2p7r96fkj5s2phfj87-libvirt-10.0.0.drv'.

Other error are not related. I think diffoscope is already broken in master (or wait for hydra)

It doesn't build on master

So the build failure is unrelated to this PR?

libvirt doesn't build (with sandbox enabled) on x86_64-darwin. It doesn't build on master

I have found Meson-based tests to be annoyingly unreliable on Darwin. Try using sudo. I have no idea why that does anything, but it often works for me.

Result of nixpkgs-review pr 298097 run on x86_64-linux 1

15 packages marked as broken and skipped:

mkosi-full
mkosi-full.dist
mkosi-full.man
qemu_xen
qemu_xen-light
qemu_xen-light.debug
qemu_xen-light.ga
qemu_xen.debug
qemu_xen.ga
qemu_xen_4_15
qemu_xen_4_15-light
qemu_xen_4_15-light.debug
qemu_xen_4_15-light.ga
qemu_xen_4_15.debug
qemu_xen_4_15.ga

33 packages failed to build:

linuxKernel.packages.linux_4_19.virtualbox
linuxPackages_4_19_hardened.virtualbox (linuxKernel.packages.linux_4_19_hardened.virtualbox)
linuxKernel.packages.linux_5_10.virtualbox
linuxPackages_5_10_hardened.virtualbox (linuxKernel.packages.linux_5_10_hardened.virtualbox)
linuxKernel.packages.linux_5_15.virtualbox
linuxPackages_5_15_hardened.virtualbox (linuxKernel.packages.linux_5_15_hardened.virtualbox)
linuxKernel.packages.linux_5_4.virtualbox
linuxPackages_5_4_hardened.virtualbox (linuxKernel.packages.linux_5_4_hardened.virtualbox)
linuxKernel.packages.linux_6_1.virtualbox
linuxPackages_6_1_hardened.virtualbox (linuxKernel.packages.linux_6_1_hardened.virtualbox)
linuxPackages.virtualbox (linuxKernel.packages.linux_6_6.virtualbox)
linuxPackages_hardened.virtualbox (linuxPackages_6_6_hardened.virtualbox)
linuxKernel.packages.linux_6_8.virtualbox
linuxPackages_latest-libre.virtualbox (linuxKernel.packages.linux_latest_libre.virtualbox)
linuxPackages-libre.virtualbox (linuxKernel.packages.linux_libre.virtualbox)
linuxPackages_lqx.virtualbox (linuxKernel.packages.linux_lqx.virtualbox)
linuxPackages_xanmod.virtualbox (linuxKernel.packages.linux_xanmod.virtualbox)
linuxPackages_xanmod_latest.virtualbox (linuxKernel.packages.linux_xanmod_latest.virtualbox ,linuxPackages_xanmod_stable.virtualbox)
linuxPackages_zen.virtualbox (linuxKernel.packages.linux_zen.virtualbox)
linuxPackages_latest.virtualbox
python312Packages.cot
python312Packages.cot.dist
solo5
solo5.debug
virtualbox
virtualbox.modsrc
virtualboxHardened
virtualboxHardened.modsrc
virtualboxHeadless
virtualboxHeadless.modsrc
virtualboxKvm
virtualboxWithExtpack
virtualboxWithExtpack.modsrc

56 packages built:

OVMFFull
OVMFFull.fd
alpine-make-vm-image
cloud-init
cloud-init.dist
cloud-utils
cloud-utils.guest
colima
cot (python311Packages.cot)
cot.dist (python311Packages.cot.dist)
diffoscope
diffoscope.dist
diffoscope.man
gnome.gnome-boxes
guestfs-tools
libguestfs
lima
lima-bin
lxd-lts
multipass
nemu
open-watcom-bin
open-watcom-bin-unwrapped
out-of-tree
python311Packages.guestfs
python311Packages.guestfs.dist
python311Packages.qemu
python311Packages.qemu.dist
python312Packages.guestfs
python312Packages.guestfs.dist
python312Packages.qemu
python312Packages.qemu.dist
qemu
qemu-python-utils
qemu-python-utils.dist
qemu-utils
qemu-utils.debug
qemu.debug
qemu.ga
qemu_full
qemu_full.debug
qemu_full.ga
qemu_kvm
qemu_kvm.debug
qemu_kvm.ga
qemu_test
qemu_test.debug
qemu_test.ga
qtemu
quickemu
quickgui
tests.testers.nixosTest-example
tests.testers.runNixOSTest-example
tests.trivial-builders.references
vagrant
zpool-auto-expand-partitions

@ofborg build solo5

@ofborg build virtualbox


Get AUTHSTRATEGY_URL and AUTHSTRATEGY from OS_ENV

Setting environment variables( OS_AUTH_AUTHSTRATEGY and AUTHSTRATEGY_URL) at deployment
time
Get environment variables( OS_AUTH_AUTHSTRATEGY and AUTHSTRATEGY_URL) when starting service

@lijuncloud
I think using command sed to substitute authentication information maybe better.
        sed -i "s,OS_AUTH_AUTHSTRATEGY:.*$,OS_AUTH_AUTHSTRATEGY: \"keystone\"," $compose_file
        sed -i "s,OS_AUTH_URL:.*$,OS_AUTH_URL: \"http://$HOST_IP/identity\"," $compose_file
        sed -i "s,OS_USERNAME:.*$,OS_USERNAME: \"$MULTICLOUD_SERVER_NAME\"," $compose_file
        sed -i "s,OS_PASSWORD:.*$,OS_PASSWORD: \"$MULTICLOUD_PASSWORD\"," $compose_file

Use the sed tool to pass variables to the docker-compose.yml file at deployment time, no longer needed for this PR


Image Details - Hyperlink to the web page related to the image on the registry

**Is your feature request related to a problem? No
Describe the solution you'd like
I used to use Openmediavault linux distro with its builtin docker interface, one of the nice features it had was when you click on the docker image details it would take you to the webpage for that docker image.
I found this useful for keeping up with changes to the images I am running (I use WatchTower to automate update of images)
Could we get a link somewhere in the details view for an image that links back to the images webpage from the registry it was pulled from (I mostly pull from DockerHub)
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Not sure if we need to add this, might be easy to add for DockerHub hosted images but for images hosted on other registries we are not aware of the URL used to browse the image repository details.
cc @ncresswell

Can add for dockerhub images only
Rgds,
Neil Cresswell
On 21/06/2018, at 7:02 PM, Anthony Lapenna <notifications<EMAIL_ADDRESS>wrote:
Not sure if we need to add this, might be easy to add for DockerHub hosted images but for images hosted on other registries we are not aware of the URL used to browse the image repository details.
cc @ncresswellhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ncresswell&d=DwMCaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=0fx0h4vB56iTLpw2McH1ZD6TqG_QGpbggVOB-PfMJpM&m=Xayr2kXgm89CvSCLQq57p6LxKg0Pa_o6Dz5unpXUntk&s=yrP-OWHqUU9Z0Bl0xJA3gU90sHGpFtn9taClcs4ZVQA&e=
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_portainer_portainer_issues_1956-23issuecomment-2D398997707&d=DwMCaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=0fx0h4vB56iTLpw2McH1ZD6TqG_QGpbggVOB-PfMJpM&m=Xayr2kXgm89CvSCLQq57p6LxKg0Pa_o6Dz5unpXUntk&s=EVOYd7MH4TFau-bDoXSRagg4o4zo_Cnl-_NN8Atxdr4&e=, or mute the threadhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AWGrlXMVGh-5Fds7yu0eyvpVwasGjGSPB8ks5t-2D0T6gaJpZM4Ud6b-5F&d=DwMCaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=0fx0h4vB56iTLpw2McH1ZD6TqG_QGpbggVOB-PfMJpM&m=Xayr2kXgm89CvSCLQq57p6LxKg0Pa_o6Dz5unpXUntk&s=HNdASH0rPhUSJUn8WH6Qs1lCsyFxkNjubUuutygXvnY&e=.


Remove unnecessary headers to fix ABI checker

🦟 Bug fix
Summary
https://github.com/gazebosim/gz-sim/pull/2019 added the files
include/ignition/gazebo/ign/gazebo/Export.hh and include/ignition/gazebo/ignition/gazebo/Export.hh which link to <gz/sim/ign/Export.hh>, but that header doesn't exist. This is breaking the ABI checker because it checks every header.
I don't think these headers are needed especially since the ign component is not really public API.
Checklist

[ ] Signed all commits for DCO
[ ] Added tests
[ ] Updated documentation (as needed)
[ ] Updated migration guide (as needed)
[ ] Consider updating Python bindings (if the library has them)
[ ] codecheck passed (See contributing)
[ ] All tests passed (See test coverage)
[ ] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

My guess is, the abi checker is failing to build the stable branch, so it won't pass until we merge this. I'll go ahead and do that and test on another PR.


PPE language changes

Overview
Review the language around PPE in the UI and choose the most helpful text. Add popups as required.

@katieashaw Sounds like we're good to continue using the phrase PPE. Would you like a help icon near the PPE only filter? I would suggest:
Personal protective equipment (PPE) includes masks, gloves, gowns, and other equipment.

Yes, I agree @dboyer
And yes please to a help icon. Given the inclusion of data on 3D printed visor makers, could we tweak your suggestion sentence to:
Personal protective equipment (PPE) includes masks, gloves, gowns, visors and other equipment.

Moved back to the queue because we need to make an additional change.


Do not use deprecated lifecycle methods in tests

React 16.9 does not contain breaking changes, and the old names continue to work in this release. But you will now see a warning when using any of the old names:

https://reactjs.org/blog/2019/08/08/react-v16.9.0.html#renaming-unsafe-lifecycle-methods
cWM, cWRP, cWU are deprecated, so I don't see any point in testing them.

I don't mean to be annoying. I just want to let you know that it's ready to review.

Thanks! I could sweat there was no notification when you marked it ready for review. Or I might just miss it...who knows :) Good to have let me know.

I could swear there was no notification when you marked it ready for review.

I was afraid of that :)


hashfile.tree: implement update_tree

I am still thinking of what the high-level API should be for building these upserted files.
We need a way to build the files, with possible expansion of directories/prefixes and ignores applied. Also, would be nice to have a batched build functionality.
But since, build() is already complicated, I'm still thinking of other options for now.
So, I have only created a low-level helper to update a tree.
Related to https://github.com/iterative/dvc/issues/4657.

Codecov Report
Patch coverage: 18.18% and project coverage change: -0.15 :warning:

Comparison is base (a2f9ed9) 57.82% compared to head (6c00c1c) 57.67%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #344      +/-   ##
==========================================
- Coverage   57.82%   57.67%   -0.15%
==========================================
  Files          51       51
  Lines        3395     3405      +10
  Branches      595      596       +1
==========================================
+ Hits         1963     1964       +1
- Misses       1346     1355       +9
  Partials       86       86

Impacted Files
Coverage Δ

src/dvc_data/hashfile/tree.py
53.07% <18.18%> (-1.98%)
:arrow_down:

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

Closing for now, will reopen later if I need it.


[📚] Your documentation feedback title (CHANGE ME)

The FCM documentation for iOS integration should come with a warning that onBackgroundMessage should not be used if the platform is iOS.  This 2019 issue comment saved me from a mysterious error that was throwing an exception that did not reveal its origin in the stacktrace (see the top of that issue thread - basically it was similar to the FcmDartService#initialized one but it was #start instead).
_firebaseMessaging.configure(
        onMessage: (Map<String, dynamic> message) async {
          print("FCM onMessage: $message");
        },
        onBackgroundMessage: Platform.isIOS ? null : myBackgroundMessageHandler,
        onLaunch: (Map<String, dynamic> message) async {
          print("FCM onLaunch: $message");
        },
        onResume: (Map<String, dynamic> message) async {
          print("FCM onResume: $message");
        },
      );

You see where I'm skipping onBackgroundMessage if it's iOS?  It seems like a problem referenced in multiple issues for a long time, so I'm not sure why the documentation does not more clearly warn people that onBackgroundMessage only works for Android right now.
I deploy on both iOS and Android devices.  My pubspec looks like this:

  firebase_core: "^0.5.0"
  firebase_analytics: "^6.0.0"
  firebase_auth: "^0.18.0+1"
  firebase_dynamic_links: "^0.6.0"
  cloud_firestore: "^0.14.0+2"
  cloud_functions: "^0.6.0"
  firebase_remote_config: "^0.4.0"
  firebase_messaging: "^7.0.0"

flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, v1.17.5, on Mac OS X 10.15.4 19E287, locale en-US)
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
[✓] Xcode - develop for iOS and macOS (Xcode 11.5)
[✓] Android Studio (version 3.6)
[✓] VS Code (version 1.48.0)
[!] Connected device

We're yet to work on messaging, however the documentation & implementation will be getting a full overhaul.


new commands

PL (only players!!!)
botlist bl (only for bots)
minionlist ml (only for minions)

@t11tanYT why would you want to list bots and minions? you can already do that with pl

@Megabyte918  My client crash if
fast
all 1000 lines displayed (max 200- 250)


default system vm template version

LGTM. Once Travis is OK with it, I'll merge.

Merged. @DaanHoogland please close PR.


feat: returning coverImage as a File  node

Returning the coverImage as a File to be used by the new gatsby-plugin-image (v3)
BREAKING CHANGE: coverImage field now returns a File and not a string

:tada: This PR is included in version 1.1.0-beta.1 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Feature Request: Vertically center the symbols inside the font.

Comparing with Fontawesome https://fontawesome.com/icons?d=gallery all symbols are vertically centered. This is necessary when a symbol is not using the whole height while others do. In the case of fantasticon all symbols are bottom aligned, this makes it impossible to align the symbol with others next-to-next vertically centered.
The -n (normalize) unfort. is not a solution since it also scales line width of symbol.
Would be great to have an option to vertically center the symbols inside the font.
thx

Hi @tec-lab - while vertical alignment seems to be a tad unpredictable, you can use the descent option to adjust it manually - may be a bit tedious but once you picked the right value you won't have to worry about it anymore
Hope this helps, let me know if it fixes it for you

Hi, I already played with the descent option but have seen no effect at all. Finally I added a frame around every symbol so that all gets centered vertically. Not sure exactly how SVG handles this, either the frame is 100% transparent or it defines a kind of page size where the symbol is drawn. Anyhow the frame is not visible in font.
Thx for your support. This issue can be closed.

@teclab-at Do you care to explain how you solved this issue?

Thanks you so much for your reply!


Copy hook files instead of linking them

As explained in #400, creating symlinks on Windows with mklink requires admin privileges, which makes Overcommit unusable for non-admin users. Our handling of symlinks on Windows is already brittle enough, so we may as well switch to copying.
We could symlink on *nix and copy on Windows, but that would unnecessarily complicate the code and specs, and I think it's better to keep behavior consistent across platforms anyway.

Thanks a ton for this, @jawshooah!


TypeError: buffer is too small for requested array

Traceback (most recent call last):
File "convert.py", line 173, in
yolo4_model = Yolo4(score, iou, anchors_path, classes_path, model_path, weights_path)
File "convert.py", line 157, in init
self.load_yolo()
File "convert.py", line 130, in load_yolo
buffer=weights_file.read(weights_size * 4))

I meet the problem too.I search in Google,somebody say that it maybe your keras model isn't match yolov4.weights.So I try to figure out.

Traceback (most recent call last):
File "convert.py", line 173, in
yolo4_model = Yolo4(score, iou, anchors_path, classes_path, model_path, weights_path)
File "convert.py", line 157, in init
self.load_yolo()
File "convert.py", line 130, in load_yolo
buffer=weights_file.read(weights_size * 4))

I solve the problem,but I use my code.Here is link.Besides, my keras model is mismatch the AlexeyAB-version.So I just load csp-darknet.

Got the same issue when I tried to convert my tiny-yolov4, trained with AlexeyAB darknet version

I've got this error as well. Did anyone manage to solve it?

any updates?

@Amokstakov I've retrained my data by setting image size to (608,608) in yolov4-custom config file and it works.

@JoshieLim I am struggling converting the downloaded yolo_4.weights file to the yolo4.h5 file using the conver.py
Any insight into this? I am lookign and the convert.py never actually references the .cfg file for yolo4?

@Amokstakov Hmm that's odd. I'm able to convert to .h5 on my end. Did you set the anchors path to a yolo4_anchors? It should look something like this for yolov4 anchors 12, 16,  19, 36,  40, 28,  36, 75,  76, 55,  72, 146,  142, 110,  192, 243,  459, 401.

Still no luck here.
Would it be too much trouble to ask for a direct step-by-step of what you did @JoshieLim
like from Gitclione... what are the next steps into running the detect then test.py code?

Any update?

@Amokstakov Can you try to convert this yolov4.weights from this link. See if it works.
#get yolov4 pre-trained weights
!wget https://github.com/AlexeyAB/darknet/releases/download/darknet_yolo_v3_optimal/yolov4.weights

@ybloch  Hi, Have you managed to convert tiny_yolov4.weights to .h5?  It's pre-trained tiny_yolov4, not custom tiny_yolov4 model.

@MuhammadAsadJaved Hi,
I could not convert it to H5 so I converted it to a TensorFlow model and with it, I use for production.
Here's how I did it:
Using repo: [https://github.com/hunglc007/tensorflow-yolov4-tflite]

git clone https://github.com/hunglc007/tensorflow-yolov4-tflite

cd tensorflow-yolov4-tflite

sudo python3 save_model.py --weights yolov4-tiny-custom_final.weights --output ./checkpoints/yolov4_v1_darknet-416 --input_size 416  --model yolov4 --framework tflite

sudo python3 convert_tflite.py --weights ./checkpoints/yolov4_v1_darknet-416 --quantize_mode fp16  --output ./checkpoints/yolov4_v1_darknet-416_fp16.tflite

You will find in this project an example of using the converted model

@ybloch  OK. Thanks for sharing dear. Actually I need keras model for some other project (tiny_yolov4+deep_sort). It's a project for detection and then applying tracker on detections.

did anyone manage to convert the model? If yes, please help

Same problem here. Tried all possible mirrors for yolov4 weights.
But I've made only one change to convert.py: replaced from keras import backend as K to import tensorflow.python.keras.backend as K, because original import caused another problem:
AttributeError: module 'keras.backend' has no attribute 'get_session'

Same problem here. Tried all possible mirrors for yolov4 weights.
But I've made only one change to convert.py: replaced from keras import backend as K to import tensorflow.python.keras.backend as K, because original import caused another problem:
AttributeError: module 'keras.backend' has no attribute 'get_session'

Thank @Runist for you comment I have converted yolov4.weights file to .h5 file using Runist YOLOV4 Repository "

YOLOV4 Repository

@maazullah96  this shows 404

Having same issue.
Did anyone convert custom trained yolov4 to .h5 model? If yes, then can you please share the steps here?


fix: correct browser export to match node export

If you currently attempt to import AbortController via const { AbortController } = require('abort-controller'), it will work in Node but be undefined in browsers. This updates browser.js to be consistent with the exports from abort-controller.js in the dist folder.

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


collection: Automatically install dependent collection

Solves issue #534.

If we automatically install a dependent collection in this upstream version (GitHub, Galaxy), the installation will be performed even on those platforms which do not use roles from the dependent collection.
Modifying this PR to draft.


Add post deploy job for logs

Adds a new template for a post-depoy job for the RHOBS logs endpoints.

@periklis am I understanding this correctly that we hand-craft the templates rather than generate them via jsonnet?

@periklis am I understanding this correctly that we hand-craft the templates rather than generate them via jsonnet?

To the best of my knowledge yes it  looks we handcraft them.

Let's just quickly get @matej-g to sign-off as the original author of the post-deploy jobs.


[rsm-bsa] Remove vcpkg_fail_port_install.

Separated out because it adds a supports: to a feature.
In support of https://github.com/microsoft/vcpkg/pull/21502

Thanks!


[nrf fromlist] boards: nordic: nrf54l15pdk: PWM is supported by cpuflpr

Add PWM to the list of supported peripherals.
Upstream PR: https://github.com/zephyrproject-rtos/zephyr/pull/76281

I tested on https://github.com/nrfconnect/sdk-nrf/pull/16561

Those are SHIM tests


[Search for Journey] Search Result

As a User (Passenger) I want to see results of a journey search so that I could choose route and time convenient for me.
Mockup
Picture 1

Picture 2. Request/Option panel

Acceptance Criteria

User accesses to this screen from Journey Search page (US#12), only IF system found at least one route.
On the top of the page, there should be the label 'Search Results' and 2 available active buttons: 'Back' for returning to the previous page and 'Request' (pict. 2) for journey request (for journeys that don't exist during the search phase, but could be created till the needed departure time) (US#16).
2.1. WHEN User pushes 'Request', system rolls up request option panel (pic. 2 frame 39) with 2 options: 'With the previous filters' and 'With new filters'.
For option 'With new filters':
2.1.1. If User chooses any option, system shows the corresponding pop-up message 'You're about to create a ride request with new filters.' with 2 buttons: 'Yes, create' and 'No, go back' (pic.2 frame 36).
2.1.2. IF User pushes 'Yes, create', system opens "Create a Ride" Request page (US#16) with data (in search boxes) given for the last search.
2.1.3. IF User pushes 'No, go back', system returns to search results.
For option 'With the previous filters':
2.1.4. IF User chooses 'With the previous filters', system shall create request and inform User with the pop up "Your Ride Request is created".
Each found journey should be circled by the line and consist of such information: N&S of journey organizer, SS position, list of stops during the journey, time of the journey, journey fee (free or paid).
3.1. Requirements to date and time appearance are given in US#376
WHEN User pushes at chosen journey box, the system shall transfer User to Map page (US#14).

Assumptions & Constraints

System shall sort the route search result by two criteria:

time: system shall show on the top of trips results such results which are in the scope of 2 hours of the chosen time;
distance: system shall show on the top of trips results, such results which are in the scope of 1 km of the chosen To/From points.
free of charge journeys shall be placed on the top of the search results (in the case when User chooses fee "All" during the search).

System shall show only journeys with available sitting places.

Epic link
Epic #71
Labels to be added
"User story" ("story"), Priority ("pri: ")
Tasks

[ ] sample task.

2.1.4. IF User chooses 'With the previous filters', system shall create request and inform User with the pop up "Your Ride Request is created".


A.I.M.: Artificial Intelligence Machines - world map is heavy on performance

Frame rate drops significantly when viewing world map.
For comparison, both WineD3D and d3d8to9 + DXVK have similar results.  FPS drops also on MS Windows with D8VK in combination with AMD proprietary drivers. However, on Windows without D8VK there's virtually no FPS loss at all.
https://user-images.githubusercontent.com/27519308/209400921-661576bc-a254-4039-b1c5-f204893cd286.mp4
Software information
A.I.M.: Artificial Intelligence Machines, versions 1.00 to 1.06
System information

GPU: AMD Radeon RX 5700 XT
Driver: Mesa RADV 22.3.1
Wine version: 7.22 Staging
DXVK version: a50de4619a80191d208d73b42c7cc2a10fb4b9e2

Apitrace file(s)

AIM.v1.06.map-perf.trace

Log files

AIM_d3d9.log

Not sure the immediate cause of this issue as the framerate drops even when CopyRects is disabled. It is probably due to the many queue syncs caused by calling LockRect a whole bunch. Not sure if this can easily be fixed without refactoring d3d9 a bunch.

@Kritzmensch can you confirm that the issue doesn't occur if the game is run on Windows with Microsoft D3D8? Or is it just apitrace where it's fast?

@Kritzmensch can you confirm that the issue doesn't occur if the game is run on Windows with Microsoft D3D8?

It does occur, but it's not nearly as taxing as with anything else, including D8VK, that I've tested so far. Although the drop isn't visible (at least on 1080p and lower) without uncapping and monitoring FPS, the overhead is still rather high on pure Windows, too (~45 frames on my setup; though perhaps that's the way the game works and it's the best result that can be hoped in the end).
Also, something I failed to mention at the top is that this Windows' d3d8 implementation is broken in some parts.
https://user-images.githubusercontent.com/27519308/210675875-44e5e63a-6717-4d8f-bf70-8d8fdeff8176.mp4

@Kritzmensch Can you please retest with latest main? There have been some changes done to buffer allocation which might have fixed these performance issues.

Just built the latest commit, the game slows down to a crawl on the map screen. Intel Core i5-7400, Intel HD Graphics 630, Mesa 23.0.2. The game is patched to version 1.04 + 1.06 No-CD.
Menus in general significantly tank performance, and the game seems to constantly hitch when you're on the move, even in the areas that you've been before. It's... not exactly a technological masterpiece. (Although the map didn't tank performance that hard, even on a much weaker Windows configuration.)

@GranMinigun Thank you for retesting.

Just built the latest commit, the game slows down to a crawl on the map screen.

Does setting d3d9.apitraceMode = True help at all?

@WinterSnowfall Unfortunately I have to confirm @GranMinigun's earlier findings. There's no FPS increase.

No worries and thanks again for retesting. We'll keep this on the burner then and hopefully sort it at a later date.

I'm not familiar with either D3D or Vulkan, but some observations, just in case: The number of queue syncs always stays at zero, but the numbers of queue submissions, barriers, and CS chunks considerably increase in menus, and jump drastically at the map screen, skyrocketing frametimes up to 300+ ms on my machine. The game also performs a lot of render passes (around 150, double that on map), but with a relatively digestible number of draw calls (usually less than 1200, much less in menus). Numbers fluctuate a bit. D8VK built from commit 4a7c627.

In-game
Menu
Map

Queue submissions
7
22
232

Barriers
271
326
1339

CS chunks
15
24
231

Not related to this specific issue but I've noticed a significant drop in average FPS over last few months with D8VK when compared to d3d8to9+DXVK combination.
There are many areas in the first game where FPS will always drastically drop for me, all seemingly where there is a lot of foliage around (and particle effects in case of Clan Wars). One of the worst locations is a southern shore of the lake near raw materials base in Tundra Sector. Start from somewhere in the middle of the northern part of the lake and start moving southwards without deviating from the course (coords: x13670 y8100, marked with the red circle on map). You should experience a steady decline in frame rate while approaching.
@GranMinigun can you check if same happens on you setup too?

Observations I've made:

D8VK
d3d8to9+DXVK

FPS in problematic 'hotspots'
~70..110
130..190

FPS normally
~210
250..300

My iGPU suffers greatly from alpha-blending overdraw in general, and it's not unique to this game or DXVK. There's a field of dry grass west of Climate Activator in the Hills Sector, which seems to hit even harder.
In other news, the map screen doesn't tank performance into single digits on my setup any more (still slows down). But I lost the icon for the light weapons, and certain flare billboards don't have correct alpha blending.

Did you try to compare D8VK against d3d8to9+DXVK, was there any noticeable perf. diff. on your setup as well? If I remember correctly the gap used to be much narrower at the start of the year in my case.

alpha-blending overdraw

I guess that might explain why particles also decrease FPS so drastically.

There's a field of dry grass west of Climate Activator in the Hills Sector, which seems to hit even harder.

There are many areas in the first game where FPS will always drastically drop for me, all seemingly where there is a lot of foliage around

I removed foliage models from all terrain materials and it indeed is the cause for the abysmal frame rate. Game runs unbelievably smoothly without them.
Based on the two answers to basically a same issue on upstream (https://github.com/doitsujin/dxvk/issues/1012#issuecomment-482781600, https://github.com/doitsujin/dxvk/issues/1012#issuecomment-493093430) I take that there's no point in opening a new separate issue since the current behaviour is expected and there's unfortunately nothing to do about it.

In other news, the map screen doesn't tank performance into single digits on my setup any more (still slows down).

Funnily enough, for me it's the other way around. It's not single-digit of course, but the frame rate has degraded by some 50 frames in map view (from around 100 FPS, or a bit less, at 1080p seen in the video above).

Did you try to compare D8VK against d3d8to9+DXVK, was there any noticeable perf. diff. on your setup as well?

d3d8to9 with the current DXVK release crashes on first attempt to render water, then doesn't draw it at all in subsequent launches. But yes, I too observe that performance difference, although much less extreme likely due to weaker hardware.

nothing to do about it

Reverse the game, rewrite the renderer. I don't think the developers would mind that. ;)

d3d8to9 with the current DXVK release crashes on first attempt to render water, then doesn't draw it at all in subsequent launches. But yes, I too observe that performance difference, although much less extreme likely due to weaker hardware.

Thank you for testing! d3dx9_43.dll from Wine Project seems to not be 100% compatible with it. If you have A.I.M. 2: Clan Wars or A.I.M.: Racing bought on Steam, look into their _CommonRedist/DirectX/Jun2010 directory. If you haven't, Microsoft probably still directly hosts it on their website. I think disc releases were also shipped with their own copies of DirectX installers but those are probably way older and don't include d3d9.

Reverse the game, rewrite the renderer.

Honestly, no kidding, that is something I might just look into at some point in the future, even if it takes 10 or more years to get on par with the original binaries (considering how long, or fast, it approx. took to RE original binaries of RenderWare engine, 3D GTAs and Morrowind and then rewrite them as librw and re3, and OpenMW). The interest is certainly there.

I don't think the developers would mind that.

Spline, the lead dev, does indeed seem chill on that regard. He's even given some small hints/clarifications about the code and inner workings of the engine. The current IP owners, however, would probably have something to say about that unless the clean way is used. But that's a topic for another time to avoid going too off-topic of the opened issue.

Or, as an option, see if there's a way to replace alpha blending with masked alpha.

Possibly. I know M2 has [non-specular] uses for masks in some places, maybe M1 as well with correct configuration. There's also the way of disabling transparency selectively for commonly occurring spammy textures, including particle effects, entirely in the game's database. It would, of course, have a downside of looking ugly but it would still be a viable way to have higher FPS with foliage for those who're seeking it.
I still find it curious that d3d8to9 is so much more performant in case of alpha-blending.

I still find it curious that d3d8to9 is so much more performant in case of alpha-blending.

It's most likely not. If I had to guess it might be the game is one of the few impacted by our D3DPOOL_MANAGED workaround. At some point I think we'll devise a better system to handle games that read from WRITE_ONLY buffers, but for now it's the best compromise we could come up with and unfortunately other games (which ironically behave properly) are expected to take a hit on performance. Try running it with d3d8.managedBufferPlacement = false and see how it goes.

Getting better performance with that setting. If the game misbehaves, would it crash or just show graphical artefacts? Not seeing anything weird in a brief flythrough.

d3dx9_43.dll from Wine Project seems to not be 100% compatible with it.

winetricks d3dx9_43 it is then. Thanks, will keep that in mind.

current IP owners

I thought Dust, one of the original devs, bought out the rights from 1C? But sure, if you don't want to derail the ticket even further.

Getting better performance with that setting. If the game misbehaves, would it crash or just show graphical artefacts? Not seeing anything weird in a brief flythrough.

The game won't misbehave with this setting, because we're doing what it asks of us in the first place (with it set to false).
The underlying problem is that apparently a lot of d3d8 games read back from DEFAULT resources on the CPU, which tanks performance severely when it happens - these situations are what we're currently mitigating with MANAGED buffer placement. But having an extra local copy around can cause performance regressions with other well behaved games, which seems to be the case here as well.
Since the number of games that have been observed to negatively affected keeps growing, I'll raise an issue to track this problem and hopefully come up with a better solution once d8vk is merged upstream. Feel free to use the above config option for now.

It's most likely not. Try running it with d3d8.managedBufferPlacement = false and see how it goes.

You're right. Frame rate is of course sometimes higher, sometimes lower, between different sessions making it more difficult to compare the two but it seems to be on par with D8VK+d3d8to9 when this setting is disabled.

winetricks d3dx9_43 it is then. Thanks, will keep that in mind.

Since you're using winetricks [I assume it cherry-picks specified dll without pulling in others from the SDK] you'll also have to add d3dcompiler_43.

I thought Dust, one of the original devs, bought out the rights from 1C? But sure, if you don't want to derail the ticket even further.

I don't remember the whole story behind it, I'll have to recheck, but I remember he got the right/license to use A.I.M./Механоиды name again and [some?] assets. I doubt he actually owns them again. The original trilogy (A.I.M., A.I.M. 2: Clan Wars and A.I.M.: Racing) are, however, still property of 1C.
We can continue the discussion on the community Discord group, or in PMs, if you wish.

[...] all seemingly where there is a lot of foliage around (and particle effects in case of Clan Wars).

Scratch the last part. Frame rate doesn't drop half of the times when a lot of spammy particles are spawned at once. And when it does drop it doesn't seem to be affected by whether I'm using d3d8to9+DXVK or d3d8.managedBufferPlacement = false with D8VK.

And when it does drop it doesn't seem to be affected by whether I'm using d3d8to9+DXVK or d3d8.managedBufferPlacement = false with D8VK.

Apart from what Alpyne mentioned at the start (the game abusing LockRect), it could be spamming a lot of ProcessVertices calls at times, which is also known to pose a performance problem with d8vk/dxvk. Unfortunately, there's no way to address that at the moment and as luck would have it older games are more likely to exhibit this behavior, since on hardware at the time it wasn't all that expensive (and done on the CPU).

@GranMinigun I see the person who opened this issue is gone, but can you perhaps retest this on dxvk 2.4 and let us know if it's still a problem?
If so, please also try setting d3d9.allowDirectBufferMapping = False and should game performance be better than way, we can consider making it a builtin default.

Same hardware as before, Linux 6.nice.8, Mesa 24.1.3, freshly built DXVK 2.4.
The map screen used to plummet framerate into a single digit a long time ago, but at some point that improved - 20~30 FPS, not sure whether that's DXVK or Mesa improvements, or something else.
d3d9.allowDirectBufferMapping doesn't seem to affect performance.
DXVK HUD suggests that queue and CS syncs take a lot of time, and this is the only place where I see these values being non-zero, if that helps.

DXVK HUD suggests that queue and CS syncs take a lot of time, and this is the only place where I see these values being non-zero, if that helps.

Setting d3d9.allowDirectBufferMapping to False could've potentially helped with queue syncs, but alas. Thanks for retesting.


Improved TypeScript type definitions

I was using this package in a TypeScript project recently but found that a few functions were missing from the type definitions, so I made the following changes:

Added type definitions for the functions clearAllKeys(), fillPanel() and all visible static functions
Exported type StreamDeck as a class instead of an interface so it can be instantiated directly and added type definition for the constructor
Added typings.d.ts to the files option in package.json to ensure it's included in the package that gets published on NPM

I hope this is useful!

Great!