Agola CPU spikes to 120% and goes into tight futex/nanosleep loop after some time

What happened:
I'm not sure what triggers it, but after some time, agola starts to use 120% CPU and never stops, even though it is functionally doing nothing:

Once it gets into this state, restarting the agola server does not help - it immediately uses 120%+ CPU right after starting back up. Agola still seems to function normally during this time, but the high CPU usage does not drop until I delete all the agola databases and start over with a fresh installation, but then I lose all the build data and history.
What you expected to happen:
Agola should be able to maintain 0% CPU when it's not doing anything.
How to reproduce it (as minimally and precisely as possible):
Unfortunately, I am not sure. It seems to start happening after I push several commits, but I haven't been able to pinpoint an exact cause. Let me know if I can provide any additional debugging details.
This is the second time that this has happened. The first time, I deleted all the databases which cleared all the configuration and history, and it fixed the issue. It worked for a couple weeks until the issue happened again, so I figured I would open a bug to document the findings and hopefully identify a cause.
Environment:

Agola version: git master branch (b179cb2bf06cbb8f59ef1b6c4c5eb4f62ddf11f6)
Agola running environment (if useful to understand the bug): Linux

I ran strace -f -p <pid> and I can see it is stuck in a tight futex/nanosleep loop:
comet ~ # strace -f -p 16530                                                                                18:11:21 [39810/39815]
strace: Process 16530 attached with 23 threads
[pid 16555] futex(0xc000b81148, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 16554] futex(0xc000d86148, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 16551] futex(0xc000c00148, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 16550] futex(0xc000b80148, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 16548] futex(0xc00055e148, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 16546] futex(0xc000a80148, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 16545] futex(0xc000a00148, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 16544] futex(0xc0000ff948, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 16543] futex(0xc000600948, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 16535] futex(0xc000500148, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 16530] futex(0x41d9ea0, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 16547] futex(0xc000c00948, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid 16533] futex(0xc0000d3948, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 16547] <... futex resumed>)        = 0
[pid 16537] futex(0xc000600148, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 16532] futex(0xc0000d3148, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 16531] restart_syscall(<... resuming interrupted futex ...> <unfinished ...>
[pid 16547] fcntl(14, F_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=120, l_len=1} <unfinished ...>
[pid 16553] futex(0xc000b80948, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 16552] futex(0xc000c00948, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 16549] futex(0xc000b00148, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 16539] futex(0xc0006a0148, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 16547] <... fcntl resumed>)        = 0
[pid 16538] futex(0xc0004be148, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 16547] fcntl(14, F_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=124, l_len=1} <unfinished ...>
[pid 16536] epoll_pwait(4,  <unfinished ...>
[pid 16534] futex(0x423bb38, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 16547] <... fcntl resumed>)        = 0
[pid 16547] getrandom("\x00\x80\x8b\x22\x01\xf8\xda\x86\xdc\x7c\x4f\xff\x7e\x7c\x4c\xc8", 16, 0) = 16
[pid 16547] fcntl(14, F_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=124, l_len=1}) = 0
[pid 16547] fcntl(14, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=120, l_len=1}) = 0
[pid 16552] <... futex resumed>)        = -1 EAGAIN (Resource temporarily unavailable)
[pid 16547] fcntl(14, F_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=120, l_len=1} <unfinished ...>
[pid 16536] <... epoll_pwait resumed>[], 128, 0, NULL, 0) = 0
[pid 16547] <... fcntl resumed>)        = 0
[pid 16547] fcntl(14, F_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=124, l_len=1}) = 0
[pid 16547] getrandom("\x68\xff\x7b\xb2\x9f\x12\xa2\xc2\x9f\xe8\x1f\x90\x6c\xa6\xc0\xc3", 16, 0) = 16
[pid 16547] fcntl(14, F_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=124, l_len=1} <unfinished ...>
[pid 16552] epoll_pwait(4,  <unfinished ...>
[pid 16547] <... fcntl resumed>)        = 0
[pid 16552] <... epoll_pwait resumed>[], 128, 0, NULL, 0) = 0
[pid 16547] fcntl(14, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=120, l_len=1} <unfinished ...>
[pid 16536] epoll_pwait(4,  <unfinished ...>
[pid 16547] <... fcntl resumed>)        = 0
[pid 16536] <... epoll_pwait resumed>[], 128, 0, NULL, 0) = 0
[pid 16552] futex(0xc000d86148, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid 16536] epoll_pwait(4,  <unfinished ...>
[pid 16552] <... futex resumed>)        = 1
[pid 16536] <... epoll_pwait resumed>[], 128, 0, NULL, 0) = 0
[pid 16554] <... futex resumed>)        = 0
<...snip...>

Here is the system call summary after 10s:
comet ~ # timeout 10 strace -c -f -p 16530
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 84.17   19.429929          41    463870      6614 futex
  8.62    1.990271          17    111794       130 nanosleep
  6.50    1.500132         615      2436         1 epoll_pwait
  0.38    0.087532           0    261162           fcntl
  0.11    0.026024           5      5107           tgkill
  0.10    0.022536           4      5107           getpid
  0.06    0.014966           0     65283           getrandom
  0.04    0.009026           1      5107       174 rt_sigreturn
  0.01    0.002656           1      2306           sched_yield
  0.00    0.000914           4       215           write
  0.00    0.000695           1       409       119 read
  0.00    0.000498           1       375           madvise
  0.00    0.000052          52         1           restart_syscall
  0.00    0.000013           2         5           openat
  0.00    0.000007           0        10           getdents64
  0.00    0.000005           1         5           close
  0.00    0.000000           0        20           pwrite64
  0.00    0.000000           0         5         5 epoll_ctl
  0.00    0.000000           0        15           newfstatat
------ ----------- ----------- --------- --------- ----------------
100.00   23.085256          25    923232      7043 total

@milosivanovic since it's just probably something looping forever to see what's happening you should provide a stack trace of the processes (SIGQUIT) and perhaps the logs of when this is happening. Syscalls aren't useful in such case.

Sure - here is the raw output after sending SIGQUIT to the main process which was running for just a few seconds and had the 120% CPU issue:
agola_stack_traces.txt

I re-ran agola for 8 seconds with debug: true set in each service config, producing the following output:
comet ~/d/agola # ./bin/agola serve --config /root/swarm/agola/config_nondocker.yml --components all-base,executor
2024-02-15T22:43:57.134413215-08:00 DBG internal/services/notification/webhooks.go:132 > webhookCleanerLoop
2024-02-15T22:43:57.134659182-08:00 DBG internal/services/executor/executor.go:1089 > executorStatusSenderLoop
2024-02-15T22:43:57.134613827-08:00 DBG internal/services/notification/commitstatus.go:138 > commitStatusesCleanerLoop
2024-02-15T22:43:57.134726757-08:00 DBG internal/services/executor/executor.go:1106 > executorTasksStatusSenderLoop
2024-02-15T22:43:57.134820864-08:00 DBG internal/services/executor/executor.go:1142 > tasksUpdater
2024-02-15T22:43:57.134728233-08:00 DBG internal/services/executor/executor.go:1033 > podsCleaner
2024-02-15T22:43:57.134824973-08:00 DBG internal/services/executor/executor.go:1270 > tasksDataCleaner
2024-02-15T22:43:57.134825894-08:00 DBG internal/services/executor/executor.go:1576 > tasksTimeoutCleaner
2024-02-15T22:43:57.135324643-08:00 DBG internal/services/runservice/scheduler.go:1345 > fetcher
2024-02-15T22:43:57.135325424-08:00 DBG internal/services/runservice/scheduler.go:1495 > finished run archiver loop
2024-02-15T22:43:57.135344569-08:00 DBG internal/services/runservice/scheduler.go:1361 > fetcher
2024-02-15T22:43:57.135351647-08:00 DBG internal/services/runservice/scheduler.go:1511 > finished run archiver
2024-02-15T22:43:57.135353153-08:00 DBG internal/services/runservice/scheduler.go:1658 > objectsCleaner
2024-02-15T22:43:57.135360984-08:00 DBG internal/services/runservice/scheduler.go:1450 > runsSchedulerLoop
2024-02-15T22:43:57.135397426-08:00 DBG internal/services/runservice/scheduler.go:1466 > runsScheduler
2024-02-15T22:43:57.135363169-08:00 DBG internal/services/runservice/scheduler.go:1599 > cacheCleaner
2024-02-15T22:43:57.135359596-08:00 DBG internal/services/runservice/scheduler.go:849 > executorTasksCleaner
2024-02-15T22:43:57.13536822-08:00 DBG internal/services/runservice/scheduler.go:970 > runTasksUpdater
2024-02-15T22:43:57.135413945-08:00 DBG internal/services/runservice/scheduler.go:986 > runTasksUpdater
2024-02-15T22:43:57.135353614-08:00 DBG internal/services/runservice/scheduler.go:1641 > logCleanerLoop
2024-02-15T22:43:57.135452566-08:00 DBG internal/services/runservice/scheduler.go:1658 > objectsCleaner
2024-02-15T22:43:57.135505688-08:00 INF internal/services/runservice/runservice.go:43 > maintenance mode watcher: maintenance mode enabled: false
2024-02-15T22:43:57.135547184-08:00 DBG internal/services/runservice/runservice.go:46 > maintenanceModeWatcherLoop
2024-02-15T22:43:57.136755848-08:00 DBG internal/services/executor/executor.go:1169 > ets: []*types.ExecutorTask{}
2024-02-15T22:43:57.136923357-08:00 INF internal/services/configstore/configstore.go:44 > maintenance mode watcher: maintenance mode enabled: false
2024-02-15T22:43:57.136951925-08:00 DBG internal/services/configstore/configstore.go:47 > maintenanceModeWatcherLoop
2024-02-15T22:43:57.137265074-08:00 DBG internal/services/executor/executor.go:734 > send executor status: &types.ExecutorStatus{
  ListenURL: "http://<IP_ADDRESS>:4001",
  Archs: []types.Arch{
    "amd64",
  },
  Labels: map[string]string{},
  AllowPrivilegedContainers: false,
  ActiveTasksLimit: 2,
  ActiveTasks: 0,
  Dynamic: false,
  ExecutorGroup: "515ba71a-a58a-4d58-b699-f77d060acc1a",
  SiblingsExecutors: []string{
    "515ba71a-a58a-4d58-b699-f77d060acc1a",
  },
}
2024-02-15T22:43:58.136955321-08:00 DBG internal/services/runservice/runservice.go:46 > maintenanceModeWatcherLoop
2024-02-15T22:43:58.136976599-08:00 DBG internal/services/runservice/scheduler.go:849 > executorTasksCleaner
2024-02-15T22:43:58.137037368-08:00 DBG internal/services/configstore/configstore.go:47 > maintenanceModeWatcherLoop
2024-02-15T22:43:58.13734305-08:00 DBG internal/services/executor/executor.go:1033 > podsCleaner
2024-02-15T22:43:59.13493095-08:00 DBG internal/services/executor/executor.go:1270 > tasksDataCleaner
2024-02-15T22:43:59.134930006-08:00 DBG internal/services/executor/executor.go:1576 > tasksTimeoutCleaner
2024-02-15T22:43:59.13492976-08:00 DBG internal/services/executor/executor.go:1106 > executorTasksStatusSenderLoop
2024-02-15T22:43:59.135540026-08:00 DBG internal/services/runservice/scheduler.go:1345 > fetcher
2024-02-15T22:43:59.135573187-08:00 DBG internal/services/runservice/scheduler.go:1361 > fetcher
2024-02-15T22:43:59.1361108-08:00 DBG internal/services/runservice/scheduler.go:1495 > finished run archiver loop
2024-02-15T22:43:59.136138183-08:00 DBG internal/services/runservice/scheduler.go:1511 > finished run archiver
2024-02-15T22:43:59.136899799-08:00 DBG internal/services/executor/executor.go:1142 > tasksUpdater
2024-02-15T22:43:59.136898747-08:00 DBG internal/services/runservice/scheduler.go:1450 > runsSchedulerLoop
2024-02-15T22:43:59.136961853-08:00 DBG internal/services/runservice/scheduler.go:1466 > runsScheduler
2024-02-15T22:43:59.137112258-08:00 DBG internal/services/runservice/runservice.go:46 > maintenanceModeWatcherLoop
2024-02-15T22:43:59.137111236-08:00 DBG internal/services/runservice/scheduler.go:849 > executorTasksCleaner
2024-02-15T22:43:59.137170212-08:00 DBG internal/services/executor/executor.go:1169 > ets: []*types.ExecutorTask{}
2024-02-15T22:43:59.137140897-08:00 DBG internal/services/configstore/configstore.go:47 > maintenanceModeWatcherLoop
2024-02-15T22:43:59.137784528-08:00 DBG internal/services/executor/executor.go:1089 > executorStatusSenderLoop
2024-02-15T22:43:59.139432447-08:00 DBG internal/services/executor/executor.go:734 > send executor status: &types.ExecutorStatus{
  ListenURL: "http://<IP_ADDRESS>:4001",
  Archs: []types.Arch{
    "amd64",
  },
  Labels: map[string]string{},
  AllowPrivilegedContainers: false,
  ActiveTasksLimit: 2,
  ActiveTasks: 0,
  Dynamic: false,
  ExecutorGroup: "515ba71a-a58a-4d58-b699-f77d060acc1a",
  SiblingsExecutors: []string{
    "515ba71a-a58a-4d58-b699-f77d060acc1a",
  },
}
2024-02-15T22:43:59.139706655-08:00 DBG internal/services/executor/executor.go:1033 > podsCleaner
2024-02-15T22:44:00.137285332-08:00 DBG internal/services/configstore/configstore.go:47 > maintenanceModeWatcherLoop
2024-02-15T22:44:00.137378263-08:00 DBG internal/services/runservice/runservice.go:46 > maintenanceModeWatcherLoop
2024-02-15T22:44:00.137470329-08:00 DBG internal/services/runservice/scheduler.go:849 > executorTasksCleaner
2024-02-15T22:44:00.141127454-08:00 DBG internal/services/executor/executor.go:1033 > podsCleaner
2024-02-15T22:44:01.134987177-08:00 DBG internal/services/executor/executor.go:1106 > executorTasksStatusSenderLoop
2024-02-15T22:44:01.1349885-08:00 DBG internal/services/executor/executor.go:1576 > tasksTimeoutCleaner
2024-02-15T22:44:01.134989389-08:00 DBG internal/services/executor/executor.go:1270 > tasksDataCleaner
2024-02-15T22:44:01.135794413-08:00 DBG internal/services/runservice/scheduler.go:1345 > fetcher
2024-02-15T22:44:01.135806459-08:00 DBG internal/services/runservice/scheduler.go:1361 > fetcher
2024-02-15T22:44:01.136311023-08:00 DBG internal/services/runservice/scheduler.go:1495 > finished run archiver loop
2024-02-15T22:44:01.136324857-08:00 DBG internal/services/runservice/scheduler.go:1511 > finished run archiver
2024-02-15T22:44:01.137071986-08:00 DBG internal/services/runservice/scheduler.go:1450 > runsSchedulerLoop
2024-02-15T22:44:01.137086227-08:00 DBG internal/services/runservice/scheduler.go:1466 > runsScheduler
2024-02-15T22:44:01.13723224-08:00 DBG internal/services/executor/executor.go:1142 > tasksUpdater
2024-02-15T22:44:01.137388638-08:00 DBG internal/services/configstore/configstore.go:47 > maintenanceModeWatcherLoop
2024-02-15T22:44:01.137477751-08:00 DBG internal/services/runservice/runservice.go:46 > maintenanceModeWatcherLoop
2024-02-15T22:44:01.13748769-08:00 DBG internal/services/executor/executor.go:1169 > ets: []*types.ExecutorTask{}
2024-02-15T22:44:01.137704348-08:00 DBG internal/services/runservice/scheduler.go:849 > executorTasksCleaner
2024-02-15T22:44:01.139839714-08:00 DBG internal/services/executor/executor.go:1089 > executorStatusSenderLoop
2024-02-15T22:44:01.141516077-08:00 DBG internal/services/executor/executor.go:734 > send executor status: &types.ExecutorStatus{
  ListenURL: "http://<IP_ADDRESS>:4001",
  Archs: []types.Arch{
    "amd64",
  },
  Labels: map[string]string{},
  AllowPrivilegedContainers: false,
  ActiveTasksLimit: 2,
  ActiveTasks: 0,
  Dynamic: false,
  ExecutorGroup: "515ba71a-a58a-4d58-b699-f77d060acc1a",
  SiblingsExecutors: []string{
    "515ba71a-a58a-4d58-b699-f77d060acc1a",
  },
}
2024-02-15T22:44:01.142895198-08:00 DBG internal/services/executor/executor.go:1033 > podsCleaner
2024-02-15T22:44:02.137454546-08:00 DBG internal/services/configstore/configstore.go:47 > maintenanceModeWatcherLoop
2024-02-15T22:44:02.137522325-08:00 DBG internal/services/runservice/runservice.go:46 > maintenanceModeWatcherLoop
2024-02-15T22:44:02.13775333-08:00 DBG internal/services/runservice/scheduler.go:849 > executorTasksCleaner
2024-02-15T22:44:02.144428202-08:00 DBG internal/services/executor/executor.go:1033 > podsCleaner
2024-02-15T22:44:03.135157315-08:00 DBG internal/services/executor/executor.go:1270 > tasksDataCleaner
2024-02-15T22:44:03.13515986-08:00 DBG internal/services/executor/executor.go:1576 > tasksTimeoutCleaner
2024-02-15T22:44:03.135160018-08:00 DBG internal/services/executor/executor.go:1106 > executorTasksStatusSenderLoop
2024-02-15T22:44:03.135953122-08:00 DBG internal/services/runservice/scheduler.go:1345 > fetcher
2024-02-15T22:44:03.135979465-08:00 DBG internal/services/runservice/scheduler.go:1361 > fetcher
2024-02-15T22:44:03.136412754-08:00 DBG internal/services/runservice/scheduler.go:1495 > finished run archiver loop
2024-02-15T22:44:03.136424991-08:00 DBG internal/services/runservice/scheduler.go:1511 > finished run archiver
2024-02-15T22:44:03.137201763-08:00 DBG internal/services/runservice/scheduler.go:1450 > runsSchedulerLoop
2024-02-15T22:44:03.137211015-08:00 DBG internal/services/runservice/scheduler.go:1466 > runsScheduler
2024-02-15T22:44:03.13750215-08:00 DBG internal/services/executor/executor.go:1142 > tasksUpdater
2024-02-15T22:44:03.137595098-08:00 DBG internal/services/configstore/configstore.go:47 > maintenanceModeWatcherLoop
2024-02-15T22:44:03.13762987-08:00 DBG internal/services/runservice/runservice.go:46 > maintenanceModeWatcherLoop
2024-02-15T22:44:03.137645347-08:00 DBG internal/services/executor/executor.go:1169 > ets: []*types.ExecutorTask{}
2024-02-15T22:44:03.13782317-08:00 DBG internal/services/runservice/scheduler.go:849 > executorTasksCleaner
2024-02-15T22:44:03.141838273-08:00 DBG internal/services/executor/executor.go:1089 > executorStatusSenderLoop
2024-02-15T22:44:03.143436024-08:00 DBG internal/services/executor/executor.go:734 > send executor status: &types.ExecutorStatus{
  ListenURL: "http://<IP_ADDRESS>:4001",
  Archs: []types.Arch{
    "amd64",
  },
  Labels: map[string]string{},
  AllowPrivilegedContainers: false,
  ActiveTasksLimit: 2,
  ActiveTasks: 0,
  Dynamic: false,
  ExecutorGroup: "515ba71a-a58a-4d58-b699-f77d060acc1a",
  SiblingsExecutors: []string{
    "515ba71a-a58a-4d58-b699-f77d060acc1a",
  },
}
2024-02-15T22:44:03.146057005-08:00 DBG internal/services/executor/executor.go:1033 > podsCleaner
2024-02-15T22:44:04.137649644-08:00 DBG internal/services/configstore/configstore.go:47 > maintenanceModeWatcherLoop
2024-02-15T22:44:04.137690427-08:00 DBG internal/services/runservice/runservice.go:46 > maintenanceModeWatcherLoop
2024-02-15T22:44:04.137936275-08:00 DBG internal/services/runservice/scheduler.go:849 > executorTasksCleaner
2024-02-15T22:44:04.147450947-08:00 DBG internal/services/executor/executor.go:1033 > podsCleaner
2024-02-15T22:44:05.135229251-08:00 DBG internal/services/executor/executor.go:1576 > tasksTimeoutCleaner
2024-02-15T22:44:05.135229394-08:00 DBG internal/services/executor/executor.go:1270 > tasksDataCleaner
2024-02-15T22:44:05.135228478-08:00 DBG internal/services/executor/executor.go:1106 > executorTasksStatusSenderLoop
2024-02-15T22:44:05.136136144-08:00 DBG internal/services/runservice/scheduler.go:1345 > fetcher
2024-02-15T22:44:05.136160683-08:00 DBG internal/services/runservice/scheduler.go:1361 > fetcher
2024-02-15T22:44:05.136520172-08:00 DBG internal/services/runservice/scheduler.go:1495 > finished run archiver loop
2024-02-15T22:44:05.136545153-08:00 DBG internal/services/runservice/scheduler.go:1511 > finished run archiver
2024-02-15T22:44:05.137328518-08:00 DBG internal/services/runservice/scheduler.go:1450 > runsSchedulerLoop
2024-02-15T22:44:05.137352317-08:00 DBG internal/services/runservice/scheduler.go:1466 > runsScheduler
2024-02-15T22:44:05.137705609-08:00 DBG internal/services/executor/executor.go:1142 > tasksUpdater
2024-02-15T22:44:05.137743451-08:00 DBG internal/services/runservice/runservice.go:46 > maintenanceModeWatcherLoop
2024-02-15T22:44:05.137770757-08:00 DBG internal/services/configstore/configstore.go:47 > maintenanceModeWatcherLoop
2024-02-15T22:44:05.137868515-08:00 DBG internal/services/executor/executor.go:1169 > ets: []*types.ExecutorTask{}
2024-02-15T22:44:05.138083771-08:00 DBG internal/services/runservice/scheduler.go:849 > executorTasksCleaner
2024-02-15T22:44:05.143809241-08:00 DBG internal/services/executor/executor.go:1089 > executorStatusSenderLoop
2024-02-15T22:44:05.144960861-08:00 DBG internal/services/executor/executor.go:734 > send executor status: &types.ExecutorStatus{
  ListenURL: "http://<IP_ADDRESS>:4001",
  Archs: []types.Arch{
    "amd64",
  },
  Labels: map[string]string{},
  AllowPrivilegedContainers: false,
  ActiveTasksLimit: 2,
  ActiveTasks: 0,
  Dynamic: false,
  ExecutorGroup: "515ba71a-a58a-4d58-b699-f77d060acc1a",
  SiblingsExecutors: []string{
    "515ba71a-a58a-4d58-b699-f77d060acc1a",
  },
}
2024-02-15T22:44:05.148948977-08:00 DBG internal/services/executor/executor.go:1033 > podsCleaner
^C
comet ~/d/agola #

@milosivanovic Thanks for the stack trace. I think what's going on and will open a PR soon.

Should be fixed by #487

@sgotti wow, thank you so much - I checked out the https://github.com/agola-io/agola/pull/487 PR locally and confirmed that it fixed the bug!

@milosivanovic Thanks for reporting and testing. Merged #487.


IOET's Contour Next LINK driver

It turns out the Contour Next LINK is already compatible with the existing Bayer Contour driver, so we just need to add the USB vendor and product IDs for it to work.
This PR also includes a speed improvement for the upload time.

LGTM. Is the styling of the next with all caps for LINK what's desired @brandonarbiter or @HowardLook?

Styling is fine for now, and maybe forever.
Thanks,
Howard
On Mon, Oct 5, 2015 at 4:03 PM, Jana Beck<EMAIL_ADDRESS>wrote:

LGTM. Is the styling of the next with all caps for LINK what's desired
@brandonarbiter https://github.com/brandonarbiter or @HowardLook
https://github.com/HowardLook?
—
Reply to this email directly or view it on GitHub
https://github.com/tidepool-org/chrome-uploader/pull/163#issuecomment-145693215
.

--
Howard Look
President, CEO and Founder
*Tidepool *An open source, not-for-profit effort to build an open data
platform and better applications that reduce the burden of Type 1 Diabetes
and accelerate the commercialization of closed-loop systems.
*Email<EMAIL_ADDRESS>*Web:    *Tidepool.org http://tidepool.org/

Merging and building for devel, since we're going to next this next and current devel Chrome store uploader is approved for prod.


How to get model predictions on all classes after applying Transfer Learning in TF2.0?

I have been following transfer learning with TFHub to implement transfer learning in my model for text classification. In the example, I do not understand how to get probabilities for all the classes (1000 classes before + 5 classes after implementing transfer learning). At the end of the tutorial, they only show predictions on the 5 classes on which the model was re-trained, but I want to have probabilities also on the 1000 classes. I can not find any documentation or explanation on how to achieve this. If anyone has any ideas or some useful links, please feel free to share. THANK YOU!
This was my main question.
About model, where I want to implement this idea of transfer learning.
I have a text dataset of 8000 classes, since the data size is too big so it can not be loaded into the RAM of my machine. So I want to train on small-small sizes of data i.e. 4000 classes and 4000 classes. I trained my model freshly on 4000 classes first, the learned model gives me good results. Now I want to retrain the saved model on the rest 4000 classes using Transfer Learning (I am also open to any other way), but after doing a lot of google searches seems like it is impossible to retrain a model on new classes, at least in text classification. If you have read this part and have some suggestions or ideas please share them, I will be very thankful.

For faster resolution please post the issue on TFHub
repository.Thanks!

@ravikyram thank you for your suggestion, I posted the issue on TFHub and here is the issue #328. Just in case someone is also looking for it.

@rishabhsahrawat Can i close this issue . We can follow-up the issue #328 on TFHub for the resolution. Thanks!


TLS Certificate is not renewed on expiration

Bug Description
After a few hours of running the cloud SQL proxy, new connections are automatically closed.   The proxy prints out error messages on each connection:
2023/05/10 16:29:18 [account-intelligence-dev:us-central1:ogma-prod-1] accepted connection from <IP_ADDRESS>:49983
2023/05/10 16:29:18 [account-intelligence-dev:us-central1:ogma-prod-1] connection aborted - error reading from instance: remote error: tls: bad certificate
2023/05/10 16:29:18 [account-intelligence-dev:us-central1:ogma-prod-1] accepted connection from <IP_ADDRESS>:49985
2023/05/10 16:29:18 [account-intelligence-dev:us-central1:ogma-prod-1] connection aborted - error reading from instance: remote error: tls: bad certificate
2023/05/10 16:29:18 [account-intelligence-dev:us-central1:ogma-prod-1] accepted connection from <IP_ADDRESS>:49987
2023/05/10 16:29:18 [account-intelligence-dev:us-central1:ogma-prod-1] connection aborted - error reading from instance: remote error: tls: bad certificate
2023/05/10 16:29:18 [account-intelligence-dev:us-central1:ogma-prod-1] accepted connection from <IP_ADDRESS>:49989
2023/05/10 16:29:19 [account-intelligence-dev:us-central1:ogma-prod-1] connection aborted - error reading from instance: remote error: tls: bad certificate
2023/05/10 16:29:19 [account-intelligence-dev:us-central1:ogma-prod-1] accepted connection from <IP_ADDRESS>:49991
2023/05/10 16:29:19 [account-intelligence-dev:us-central1:ogma-prod-1] connection aborted - error reading from instance: remote error: tls: bad certificate
2023/05/10 16:29:19 [account-intelligence-dev:us-central1:ogma-prod-1] accepted connection from <IP_ADDRESS>:49993
2023/05/10 16:29:19 [account-intelligence-dev:us-central1:ogma-prod-1] connection aborted - error reading from instance: remote error: tls: bad certificate

Example code (or command)
// paste your code or command here

Stacktrace
No response
Steps to reproduce?

?
?
?
...

Environment

OS type and version: Mac OS
Cloud SQL Proxy version (./cloud-sql-proxy --version):  cloud-sql-proxy version 2.2.0+darwin.arm64
Proxy invocation command (for example, ./cloud-sql-proxy --enable_iam_login --dir /path/to/dir INSTANCE_CONNECTION_NAME):  cloud-sql-proxy urltest-266408:us-central1:ogma-dev-1?port=15432 account-intelligence-dev:us-central1:ogma-prod-1?port=15431

Additional Details
No response

Does this include letting your machine go to sleep?

Also what does your database connection string look like (removing private information of course).

Does this include letting your machine go to sleep?

Yes

Also what does your database connection string look like (removing private information of course).

jdbc:postgresql://localhost:15431/postgres
and
jdbc:postgresql://localhost:15432/postgres

I suspect the machine sleeping is the cause of the problem.
Nonetheless, I thought we'd fixed that here: https://github.com/GoogleCloudPlatform/cloud-sql-go-connector/pull/471.
I'll investigate and report back.

Sounds good. I can provide additional log info as needed.

@enocom This appears to still be an issue. It makes the cloud-sql-proxy more-or-less unusable for our local development environments.

Good to know. We tried removing the monotonic clock value when calculating refresh times (see https://github.com/GoogleCloudPlatform/cloud-sql-go-connector/pull/471), but that seems not to have helped.
Perhaps the thing to do here is to check if the current cert is valid before initiating a connection, and blocking on a refresh if the cert is expired.

Also affected by this.

Perhaps the thing to do here is to check if the current cert is valid before initiating a connection, and blocking on a refresh if the cert is expired.

@enocom How can I implement this?

To add some info here — I recently upgraded to 2.7.1 (from 1.31.0) and started to encounter this problem. I don't believe I ever encountered on v1.31.0, maybe there's on the 2.x branch that caused this regression?

The change would have to happen around here in the Go Connector: https://github.com/GoogleCloudPlatform/cloud-sql-go-connector/blob/ed9b384fb6f0bbdbd4d16c622e5a4489dd13e8bc/dialer.go#L213
Basically:

Check if TLS Config has a non-expired cert
ForceRefresh otherwise

I'll take a look at this some time soon -- the refresh logic is on the hot path, so it's important to think carefully about any changes.

Adding some debug logging into the Go Connector around refresh and force refresh, I see this:
2023/11/27 22:39:47 Authorizing with Application Default Credentials
2023/11/27 22:39:47 [enocom-experiments-304623:us-central1:pg] Waiting to acquire rate limiter
2023/11/27 22:39:47 [enocom-experiments-304623:us-central1:pg] Refresh started
2023/11/27 22:39:47 [enocom-experiments-304623:us-central1:pg] Refresh result (expiry = 2023-11-28 06:39:47 +0000 UTC, err = <nil>)
2023/11/27 22:39:47 [enocom-experiments-304623:us-central1:pg] scheduling refresh at 2023-11-28 06:35:47 +0000 UTC
2023/11/27 22:39:47 [enocom-experiments-304623:us-central1:pg] Listening on <IP_ADDRESS>:5432
2023/11/27 22:39:47 The proxy has started successfully and is ready for new connections!
2023/11/27 22:39:49 [enocom-experiments-304623:us-central1:pg] accepted connection from <IP_ADDRESS>:49314
2023/11/27 22:39:50 [enocom-experiments-304623:us-central1:pg] client closed the connection
2023/11/28 08:37:01 [enocom-experiments-304623:us-central1:pg] accepted connection from <IP_ADDRESS>:49322
2023/11/28 08:37:01 [enocom-experiments-304623:us-central1:pg] connection aborted - error reading from instance: remote error: tls: bad certificate
2023/11/28 08:37:22 [enocom-experiments-304623:us-central1:pg] accepted connection from <IP_ADDRESS>:49324
2023/11/28 08:37:22 [enocom-experiments-304623:us-central1:pg] connection aborted - error reading from instance: remote error: tls: bad certificate
2023/11/28 08:37:23 [enocom-experiments-304623:us-central1:pg] accepted connection from <IP_ADDRESS>:49326
2023/11/28 08:37:23 [enocom-experiments-304623:us-central1:pg] connection aborted - error reading from instance: remote error: tls: bad certificate
2023/11/28 08:37:24 [enocom-experiments-304623:us-central1:pg] accepted connection from <IP_ADDRESS>:49328
2023/11/28 08:37:24 [enocom-experiments-304623:us-central1:pg] connection aborted - error reading from instance: remote error: tls: bad certificate
2023/11/28 08:37:26 [enocom-experiments-304623:us-central1:pg] accepted connection from <IP_ADDRESS>:49330
2023/11/28 08:37:26 [enocom-experiments-304623:us-central1:pg] connection aborted - error reading from instance: remote error: tls: bad certificate
2023/11/28 08:37:27 [enocom-experiments-304623:us-central1:pg] accepted connection from <IP_ADDRESS>:49332
2023/11/28 08:37:27 [enocom-experiments-304623:us-central1:pg] connection aborted - error reading from instance: remote error: tls: bad certificate

This shows that force refresh isn't running. The error is coming from here: https://github.com/GoogleCloudPlatform/cloud-sql-proxy/blob/1c00ba475374e6ae46956c4125b91a55fe953751/internal/proxy/proxy.go#L952.

These bad certificate errors are not being caught by the Proxy (or the Go Connector) given an implementation detail of how TLS 1.3 works:

In TLS 1.3 the client is the last one to speak in the handshake, so if it causes an error to occur on the server, it will be returned on the client by the first Read, not by Handshake. For example, that will be the case if the server rejects the client certificate.

https://go.dev/doc/go1.12#tls_1_3
Right now the Go Connector in particular assumes an expired client certificate (what we have here) will cause the TLS handshake to fail. Instead, the handshake succeeds and then the first read fails. Because it's the read that fails, the Proxy assumes it's a network error instead of a problem with the TLS connection and so never tries to refresh the client certificate.
This is definitely a bug on our part. I have a fix in the works.

For extra context: https://stackoverflow.com/questions/62459802/tls-1-3-client-does-not-report-failed-handshake-when-client-certificate-verifica

To close the loop on v1 not having this problem: https://github.com/GoogleCloudPlatform/cloud-sql-proxy/blob/d1e48b9851c825b0b899b6f87f2d1288e49ee0d2/proxy/proxy/client.go#L380
There's a check for the certs expiration. We'll ship this next week.

We've fixed this in the Go Connector and will release this on Tuesday.

FYI we've discovered and fixed another bug where running the Proxy with IAM Authentication would not correctly refresh the certificate.
A fix for that will go out in https://github.com/GoogleCloudPlatform/cloud-sql-proxy/pull/2128 on Thursday.


structure web server as a use of library api

currently we have the library depends on the web server, when theres no good reason to require it

@cartazio can you explain a little more what you mean?  (does the library import from somewhere we don't need, or does it, like, force HTTP requests somewhere when it could access stuff internally?)

Hi, @cartazio! I think they're independent already.

@cartazio @abhigya-sodani is this closed?

closing for now


[FLINK-16389][kafka] Bump kafka version to <IP_ADDRESS>

To address CVE-2018-1288.

Argh forgot licensing...


Can't get template to work ... easily.

nix-shell -p cargo
cargo new hello-x
nix flake init -t github:yusdacra/nix-cargo-integration
git add .
nix develop

To which it replies
warning: No packages found. Did you add the `package.metadata.nix` section to a `Cargo.toml` and added `build = true` under it?
error:
       … while calling the 'mapAttrs' builtin
       ...

Helpful, so then
echo "[package.metadata.nix]" >> Cargo.toml
echo "build = true" >> Cargo.toml
nix develop

replies
...
      error: attribute 'devShells' missing

       at /nix/store/ph69dv42xyf10i4lcbxn53xkkji98456-source/src/build/default.nix:217:11:

          216|   unwrappedPackage = _outputs.packages.${pkgs.system}.${cargoPkg.name};
          217|   shell = _outputs.devShells.${pkgs.system}.${cargoPkg.name};
             |           ^
          218| in rec {

Following this discussion, I mod the flake to
cat flake.nix
{
  inputs.nci.url = "github:yusdacra/nix-cargo-integration";

  outputs = inputs:
    inputs.nci.lib.makeOutputs {
      config = common: {
        outputs.defaults = {
          package = "hello-x";
        };
      };
      root = ./.;
    };
}

But the result of nix develop is unchanged
Running cargo run (to generate Cargo.lock)
cargo run
git add Cargo.lock

Then
nix develop

Ok - this works!
I think the error messages and docs could be clearer on this.
Is it possible to get a template such that I don't have to first nix-shell -p cargo etc.
Happy to assist if you agree there's something to be done here.
Thanks,

Thanks for the info. Can you try out #110 ? It should handle what you are talking about.

A bit smoother. Still had some issues and it took several attempts to get there.
nix-shell -p cargo
cargo new hello-x
cd hello-x/
nix flake init -t github:yusdacra/nix-cargo-integration/919017ea66b17f20df6c5721aacdbcb5e35924f1
hx flake.nix # Edit url to point at commit; rename example crate.
cargo run
git add .
nix run .#generate-lockfiles # Suggested in other error messages, but also fails
nix develop # Fails
nix develop .#hello-x

Most of these issues can easily avoided with some docs - I was just guessing.
 Ensures that crate correctly added to flake & set as default.

Maybe this is silly.

The generate-lockfiles app should be working, can you post the error message? Or make a repo with the erroring flake and etc. Thanks!

The annoying faff is having to drop into a nix-shell to use cargo to init.
Maybe the template includes the files output "cargo init" so that it can be entered immediately?
I'll make a repo...

Is it that there is a path that is absolute rather than relative?
[nix-shell:~/tmp/hello-x]$ nix run .#generate-lockfiles
trace: Cargo.lock not found for project at path .
Please ensure the lockfile exists for your project.
If you are using a VCS, ensure the lockfile is added to the VCS and not ignored (eg. run `git add /Cargo.lock` for git).

This project will be skipped and won't have any outputs generated.
Run `nix run .#generate-lockfiles` to generate lockfiles for projects that don't have one.

error: manifest path `/Cargo.toml` does not exist
fatal: /Cargo.lock: '/Cargo.lock' is outside repository at '/home/waalge/tmp/hello-x'

https://github.com/waalge/hello-x-nci/commits/main
Some notes of input/output in the commit messages.

Maybe the template includes the files output "cargo init" so that it can be entered immediately?

There is a simple-crate template included in the templates (you can use it with nix flake init -t github:yusdacra/nix-cargo-integration/flake-parts#simple-crate). That is what you mean by that I assume?

Is it that there is a path that is absolute rather than relative?

This is a bug, I fixed it just now. Please try it again.

That is exactly what I mean :) it works much more smoothly.
If I knew this existed, I would have used this multiple times in the past month to quick spin up a repo to try some library.
Its a bit of a stall for there to be no default shell, and no help message
$ nix develop # <-- BAD
warning: Git tree '/home/waalge/tmp/hello-nci' is dirty
error: flake 'git+file:///home/waalge/tmp/hello-nci' does not provide attribute 'devShells.x86_64-linux.default', 'devShell.x86_64-linux', 'packages.x86_64-linux.default' or 'defaultPackage.x86_64-linux'
       Did you mean devShells?
 $ nix develop .#my-crate # <-- GOOD

Don't want to over engineer this. But.
Every user is going to want to immediately rename "my-crate". Which has to be done in multiple places. There's an option to add a welcomeText onto a template, and/or pass args
https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-flake-init.html#options
I've not used this, but i'd be interested in trying

I don't think templates with args exist.
I've made some changes here:
https://github.com/waalge/nix-cargo-integration/tree/waalge/flake-parts

Ok, I added welcomeText's to the examples and tweaked them a bit more. Would be happy if you could check them out, hopefully it should address the issues you had.

Think it looks good.
There are other fairly immediate pit falls

rust analyzer not working, and having to add
https://discourse.nixos.org/t/rust-src-not-found-and-other-misadventures-of-developing-rust-on-nixos/11570/15
I would have thought this was pretty generic.
git submodules not being supported, but this is an artifact of flakes&git so ... i don't think there's anything to do here.
Its just painful how unhelpful nix error messages are.

rust analyzer not working, and having to add

Is this not working in the nix-cargo-integration devshell?

hmm. Maybe it was and then I broke it... not sure. Maybe await someone else reporting it as an issue.
Thanks for assisting with this, and this project


Fix the widgets example.

If the widget uses a position with x and y parameters, these are expected to be in the map interface gcs (latitude and longitude).  Rather, one should use top, left, right, and bottom for fixed screen locations.
Also, I noticed of Firefox that the examples had a needless vertical scrollbar, which I have hidden.
This fixes issue #519.

Well that's an easy fix.  LGTM.


Wrong rendering: white page

Attach (recommended) or Link to PDF file here: test2.pdf
Configuration:

Web browser and its version: Safari 15.6.1
Operating system and its version: macOS 12.6.1
PDF.js version: 3.1.81
Is a browser extension: no

Steps to reproduce the problem:

open the attached PDF using pdfJsLib;
render its first page.

What is the expected behavior? (add screenshot)

What went wrong? (add screenshot)

Web browser and its version: Safari 15.6.1

WFM, when opening it with https://mozilla.github.io/pdf.js/web/viewer.html in either Firefox Nightly 110 or Chrome Beta 109.
If this is specific to Safari that unfortunately suggests a browser-specific bug, rather than a general PDF.js one, since otherwise you'd expect it to be consistently broken everywhere.
Please report this as a canvas-related bug to the Safari developers instead, since this unfortunately doesn't look fixable here.


Missing dependency: wget, git

Summary of issue
I'm setting up a test Islandora site for evaluation on a RHEL 8 virtual machine. I was following the install guide, had installed the listed required tools, and ran the installer. A few prompts in, I received an error: environment: line 115: wget: command not found. This implies that you need wget on your system to run the installer. wget is not in the listed requirements in the README.md.
Does it make sense to list wget as an additional dependency in the README.md? I know it's a pretty standard tool but it's not bundled with every distro by default (RHEL 8 does not include it, for example). edit: git is also like this, it is required by this script but not listed anywhere.
I am more than happy to make a PR as this is a really simple change was just hoping for some input from the maintainers before doing so 😄

Thanks for the report @MykalMachon! I just opened a PR to get these changes in.

Thank you @joecorall !


Add lettuce 5.0

Pull Request Test Coverage Report for Build 190

0 of 0   changed or added relevant lines in 0 files are covered.
3749 unchanged lines in 6 files lost coverage.
Overall coverage decreased (-0.5%) to 4.197%

Files with Coverage Reduction
New Missed Lines
%

opentracing-redis-lettuce/src/main/java/io/opentracing/contrib/redis/lettuce/TracingStatefulRedisConnection.java
17
28.0%

opentracing-redis-lettuce/src/main/java/io/opentracing/contrib/redis/lettuce/TracingStatefulRedisClusterConnection.java
22
0.0%

opentracing-redis-lettuce/src/main/java/io/opentracing/contrib/redis/lettuce/TracingRedisAsyncCommands.java
632
2.61%

opentracing-redis-lettuce/src/main/java/io/opentracing/contrib/redis/lettuce/TracingRedisAdvancedClusterAsyncCommands.java
646
0.0%

opentracing-redis-lettuce/src/main/java/io/opentracing/contrib/redis/lettuce/TracingRedisAdvancedClusterCommands.java
1211
0.0%

opentracing-redis-lettuce/src/main/java/io/opentracing/contrib/redis/lettuce/TracingRedisCommands.java
1221
0.58%

Totals

Change from base Build 188:
-0.5%

Covered Lines:
1086

Relevant Lines:
25876

💛  - Coveralls


[Feature]: Chain nthCalledWith

Summary

This add a new matcher toBeNth to be used when the function you want to test have no arguments for better understanding of the reader. This was requested at this issue #13646
Test plan

test('works with arguments that match', () => {
    const fn = jest.fn();
    fn(1);

    jestExpect(createSpy(fn))[calledWith](1);
    jestExpect(fn)[calledWith](1);

    expect(() => jestExpect(fn)[calledWith](1)).not.toThrow();
  });

Thanks for the PR! However, I don't think we need to add this to core. I'd be happy to land this in https://github.com/jest-community/jest-extended 🙂


[SPARK-26771][CORE][GRAPHX] Make .unpersist(), .destroy() consistently non-blocking by default

What changes were proposed in this pull request?
Make .unpersist(), .destroy() non-blocking by default and adjust callers to request blocking only where important.
This also adds an optional blocking argument to Pyspark's RDD.unpersist(), which never had one.
How was this patch tested?
Existing tests.

@srowen thank you very much for your work here. Was there any reason that you didn't change the uncacheQuery in dropTempView call here:
https://github.com/apache/spark/blob/master/sql/core/src/main/scala/org/apache/spark/sql/internal/CatalogImpl.scala#L367
It is also ends up to always a blocking call to rdd unpersist. I was wondering if a blocking call to unpersist is a requirement for dropping temp views.

@rezasafi no strong reason. The default doesn't matter so much as whether it should be blocking at all. I didn't touch it as it's more internal to Spark and wasn't sure whether there are reasons the code really expects blocking behavior here. @maropu do you know more? If we can't find a good reason, I might suggest a follow-up to remove all of these blocking params and let them default to non-blocking.

Since the current default behaviour is non-blocking in the other places, the change looks reasonable to me. IMHO errors caused by blocking uncache are a bit useless for users.  Could you check the followup? https://github.com/apache/spark/pull/24212


Deprecate manylinux 2010

Is your feature request related to a problem? Please describe.
We currently support manylinux 2010 wheels. However, manylinux2010 reached its end-of-life last year and our dependencies are no longer supporting it going forward.
Two examples so far:

llvmlite/numba stopped supporting manylinux 2010: https://github.com/numba/llvmlite/issues/768
Pillow released version 8.3.2 today that no longer supports manylinux 2010: https://pypi.org/project/Pillow/#files . This is breaking our CI

Describe the solution you'd like
Drop support for manylinux 2010 so we can use the latest versions of our dependencies
Describe alternatives you've considered
Pin our dependencies to the last version that supports manylinux 2010. Or use separate dependencies only for manylinux2010.
Additional context
Add any other context or screenshots about the feature request here.

seems to be resolved, CI is working again on main

well - should we wait with deprecation then?

I'm ok with waiting to do this until the 0.8.0 release (btw when will that be?) as @mloning seems to have indicated by switching the milestone on https://github.com/alan-turing-institute/sktime/pull/1379

Yes, we haven't established a clear release schedule but I would like to aim for a release every month, we're currently a bit behind schedule, also due to the summer break, but hopefully can push out more regular releases soon. Any preference from your side @freddyaboulton?

I've now tentatively scheduled v0.8.0 for the beginning of November (see https://github.com/alan-turing-institute/sktime/milestone/8). After I'd like to try to make a new release at the beginning of every month.

Sounds good to me @mloning !


Simplify dependencies and package type

tokens and icons have cjs bundle as main now.
Removed type flag on icons & tokens as this flag is meant for consuming applications as i've understood. Meaning if you make a new application and set type="module" in package.json, it will then load the bundle under "module" in our library.
Set all peer-deps to have a min.version approach

Should we remove prop-types in this PR or wait?

Suggest we do it separately


[ceres] Should not set CMAKE_CXX_STANDARD

Description of problem
The portfile for Ceres contains the following logic:
https://github.com/microsoft/vcpkg/blob/7e7dad5fe20cdc085731343e0e197a7ae655555b/ports/ceres/portfile.cmake#L60-L65
This can create issues for users who import Ceres into their projects using find_package(Ceres), because this unconditionally and globally overwrites the CMAKE_CXX_STANDARD variable to the value 14. As a result, consumers who wish to use a different C++ standard are forced to manually (re)set this variable after including Ceres.
This behavior appears to have been introduced here, as part of #12785.
Proposed solution
Modify the Ceres portfile to stop injecting these lines. vcpkg should not modify the user's CMAKE_CXX_STANDARD variable. Provided there is agreement, I am happy to submit such a PR.
Note that the upstream Ceres project already enforces a minimum C++ standard using a more idiomatic and targeted CMake mechanism.
Describe alternatives you've considered
I am currently able to work around this issue by manually resetting CMAKE_CXX_STANDARD after including Ceres:
set(orig_cxx_std ${CMAKE_CXX_STANDARD})
find_package(Ceres REQUIRED)
set(CMAKE_CXX_STANDARD ${orig_cxx_std})

Additional context
This behavior appears to have been introduced by #12785. cc @cenit, @JackBoosY, @BillyONeal

Timeline:

2018-03-29 The linked change was made in ceres: https://github.com/ceres-solver/ceres-solver/commit/282b8b5f35de02d653292c480796a1a53946c16c
2020-03-25 Ceres 1.14.x added to vcpkg: https://github.com/microsoft/vcpkg/commit/afe6d4f3bba8eec5d3acc644cba61fa192bd37d2#diff-16c32e1ebb4f18f123aaeef3ab97b2b8d3293acec6d2c5c8c48166ab8ff1063e

This means that whatever problem #14719 was trying to fix seems to not be able to use that for some reason.

2020-05-30 Upstream minimum C++ changed to 14: https://github.com/ceres-solver/ceres-solver/commit/7ef83e07592ead74eeacc227b642df1959d2a246#diff-a3b92e34b93c0cca1d994e6782bfbd21f40d3264a75d1b6ff9247f1d82864791
2020-12-01 Ceres 2.0.0 added to vcpkg https://github.com/microsoft/vcpkg/pull/14719
2020-12-11 That find/replace introduced https://github.com/microsoft/vcpkg/pull/12785/

@cenit Can you comment as to why that specific change was made?

I observe that the target_compile_options upstream is trying to do does not make it into the exported targets because they set cmake_minimum_required(VERSION 3.5) but the ability to do that seems to have been added in 3.8 or 3.11: https://cmake.org/cmake/help/latest/command/target_compile_options.html#arguments

Hmmm nvm I missed that I guess. The target_compile_features is present in both.

Timeline:

2018-03-29 The linked change was made in ceres: ceres-solver/ceres-solver@282b8b5
2020-03-25 Ceres 1.14.x added to vcpkg: afe6d4f#diff-16c32e1ebb4f18f123aaeef3ab97b2b8d3293acec6d2c5c8c48166ab8ff1063e

This means that whatever problem #14719 was trying to fix seems to not be able to use that for some reason.

2020-05-30 Upstream minimum C++ changed to 14: ceres-solver/ceres-solver@7ef83e0#diff-a3b92e34b93c0cca1d994e6782bfbd21f40d3264a75d1b6ff9247f1d82864791
2020-12-01 Ceres 2.0.0 added to vcpkg [ceres] upgrade to 2.0.0 #14719
2020-12-11 That find/replace introduced [OpenCV] fix compatibility with VTK9 #12785

@cenit Can you comment as to why that specific change was made?

i think that the target_compile_options were not present at the time of my #12785 PR in that current ceres version, and upgrade to v2 in #14719 didn't remove the "quick and dirty" patch that was forcing c++14 on a downstream project

i think that the target_compile_options were not present at the time of my #12785 PR in that current ceres version, and upgrade to v2 in #14719 didn't remove the "quick and dirty" patch that was forcing c++14 on a downstream project

I think it was in there, because it was done in 2018 but the version we were using when your changes were made was in 2020. I'm worried about accidentally dropping what you were doing on the floor. If you don't remember what it was and CI is passing, I'm just going to go with it?

https://github.com/microsoft/vcpkg/commit/d66679fc140d0ba2f78df6c7af84426da78c9de0
the commit i did says that it was necessary for downstream ports using classic target and not the namespaces one. And that is coherent with the position inside the config file.
With vcpkg-ci-opencv not tested in many configs, the vtk module that required it is not tested too, and so i am not sure about the ci green reliability...

the commit i did says that it was necessary for downstream ports using classic target and not the namespaced one. And that is coherent with the position inside the config file.

That's strange to me since the classic target should be doing target_link_libraries (effectively) to the namespaced one.

With vcpkg-ci-opencv not tested in many configs, the vtk module that required it is not tested too, and so i am not sure about the ci green reliability...

What ports would you like me to manually test?
I know of:

vcpkg-ci-opencv:ALL_THE_TRIPLETS ?


Update requirements and cibuild to latest tmpl

/cc https://github.com/octodns/octodns-template/pull/6 for action
/cc https://github.com/octodns/octodns-template/pull/7 for update-requirements
/cc https://github.com/octodns/octodns-template/pull/8 for cibuild test installed

Review of this can serve as review of the 3 PRs that made it to octodns-template. Once it's 👍 I'll merge them, this, and make the changes to the other providers.


[1.12.2] A way to disable Swinging Sounds?

Mod Version:
1.12.2 - <IP_ADDRESS>
Forge Version:
<IP_ADDRESS>98
Description:
I'm wondering if there is a way to disable the swinging sounds for tools (and preferably for weapons, too). I think there was a setting in the past to disable them but it seems like that was removed.
Personally I think the swinging sounds are incredibly annoying (especially while mining or harvesting when you accidently swing your pick/axe through the air a lot) and it would be awesome if it was possible to disable them (or adjust their volume).

There is an option.  Under the Sound options there is "Equip Sounds".  Set to false.

Thanks for the quick reply. I will take a look.

Pushed v<IP_ADDRESS> with changes.


LIST/WIDTH crashes Ferret for very wide output

Reported by Ansley B Manke on 29 Mar 2004 21:51 UTC
There's a buffer of 10000 characters for writing
ascii output with the /WIDTH qualifier.  When
this results in 1000 or more values being written
out, there's a crash in list_cmnd_data at line
669 where we create the Fortran format to use:
cleft+1-(width-3)/2 is the number of values to
be written to the buffer, and if there are more than
1000 of them the I3 in format 3020 is too small.
I5 would always be safe, as we're never writing more
than 10000 values to a line.
   WRITE ( col_head_format, 3020 ) cleft+1-(width-3)/2,
 .					      num_fields,  width
   WRITE ( line_buff, col_head_format ) ( i,i = lo1,hi1,del1 )

3020	   FORMAT ( '(',I2,'X,',I3,'I',I2,')' )	! eg. "( 8X, 10I 6)"
CALL SPLIT_LIST(pttmode_explct, list_lun, line_buff, 0 )
ENDIF
Migrated-From: http://dunkel.pmel.noaa.gov/trac/ferret/ticket/837

Comment by<EMAIL_ADDRESS>on 29 Apr 2004 20:31 UTC
fixed in list_cmnd_data.F; a format spec was
too small to create the needed Fortran format
for output to the line.


Create Chromium Chronicle Episode 5

What's changed, or what was fixed?
Added text for episode #5. Photos still need to be added.
Target Live Date: 2019-08-27

[ ] This has been reviewed and approved by (NAME)
[ ] I have run npm test locally and all tests pass.
[ ] I have added the appropriate type-something label.
[ ] I've staged the site and manually verified that my content displays correctly.

CC: @petele

Whoops!
There were 1 critical errors that broke the build and prevented it from being automatically deployed.
ERRORS
src/content/en/updates/2019/08/chromium-chronicle-5 - '' are NOT allowed on DevSite.

Whoops!
There were 2 warnings that will prevent this PR from being merged. Please take a look, and either fix, or provide a justification for why they can't be fixed.
WARNINGS
src/content/en/updates/2019/08/chromium-chronicle-5.md#L77 - Consider adding a "was this page helpful?" widget to your page: https://developers.google.com/web/resources/widgets#helpful
src/content/en/updates/2019/08/chromium-chronicle-5.md#L77 - Updates post is missing RSS feed widget: '{% include "web/_shared/rss-widget-updates.html" %}'

Whoops!
There were 2 warnings that will prevent this PR from being merged. Please take a look, and either fix, or provide a justification for why they can't be fixed.
WARNINGS
src/content/en/updates/2019/08/chromium-chronicle-5.md#L77 - Consider adding a "was this page helpful?" widget to your page: https://developers.google.com/web/resources/widgets#helpful
src/content/en/updates/2019/08/chromium-chronicle-5.md#L77 - Updates post is missing RSS feed widget: '{% include "web/_shared/rss-widget-updates.html" %}'

Whoops!
There were 2 warnings that will prevent this PR from being merged. Please take a look, and either fix, or provide a justification for why they can't be fixed.
WARNINGS
src/content/en/updates/2019/08/chromium-chronicle-5.md#L77 - Consider adding a "was this page helpful?" widget to your page: https://developers.google.com/web/resources/widgets#helpful
src/content/en/updates/2019/08/chromium-chronicle-5.md#L77 - Updates post is missing RSS feed widget: '{% include "web/_shared/rss-widget-updates.html" %}'

:+1:

:+1:


Cannot GET /

When I try to open the backend on http://localhost:3001/
I get white page with small text "Cannot GET /"

Therefore when I try to use the API I am getting error:
An Error occured: 400 Client Error: Bad Request for url: http://host.docker.internal:3001/api/search
the log for the backend in docker looks good:
2024-10-31 00:05:53 yarn run v1.22.19
2024-10-31 00:05:53 $ npm run db:push && node dist/app.js
2024-10-31 00:05:53
2024-10-31 00:05:53 ><EMAIL_ADDRESS>db:push
2024-10-31 00:05:53 > drizzle-kit push sqlite
2024-10-31 00:05:53
2024-10-31 00:05:53 drizzle-kit: v0.22.7
2024-10-31 00:05:53 drizzle-orm: v0.31.2
2024-10-31 00:05:53
2024-10-31 00:05:53 No config path provided, using default path
2024-10-31 00:05:53 Reading config file '/home/perplexica/drizzle.config.ts'
2024-10-31 00:05:54 [⣷] Pulling schema from database...
[✓] Pulling schema from database...
2024-10-31 00:05:54
2024-10-31 00:05:54 [i] No changes detected
2024-10-31 00:05:54 info: WebSocket server started on port 3001
2024-10-31 00:05:54 info: Server is running on port 3001

However, Perplexica is working fine as frontend when I use it on port 3000
what am I missing?

Use http://localhost:3001/api/search. You don't need to use host.docker.internal since you're sending request from the host.

Thanks for the reply,
Changing it to  http://localhost:3001/api/search still give me this result:

Yes when I try to make call I egt this:
An Error occured: HTTPConnectionPool(host='localhost', port=3001): Max retries exceeded with url: /api/search (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7ff0fa55ee10>: Failed to establish a new connection: [Errno 111] Connection refused'))


Execution should start as soon as possible.

I was posting on an old issue that I can't find right now, but ultimately I thought this would merit a new issue.
The point of this is that I don't see the requirement (other than how the code as it is written currently) to wait for all browsers before executing tests.
https://github.com/karma-runner/karma/blob/master/lib/executor.js#L18
I believe changing this to run tests in a single browser right after that browser connects would have multiple benefits. To name a few:

Would significantly speed up overall run
Would make the overall run less prone to runner errors (we can leave one browser out, if that browser times out / fails to connect, this should have no bearing on tests in other browsers).
3 Would allow the use of selenium + ios-driver without fear of locking up the hub

Closing due to inactivity


Choice of ascii vs utf8 encoding is ambiguous

[Enter feedback here]
Hi there. It would be very helpful if you could elaborate on why you mix UTF-8 and Ascii encoding in the examples. Whether that's a mistake or on purpose is not really clear.
Kind Regards

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 0718f126-017a-f26c-4f39-f9d6899f6496
Version Independent ID: fffab5ef-d2a6-c86f-60fd-df0df5ac7dac
Content: Learn how to sign an HTTP request with HMAC - An Azure Communication Services tutorial
Content Source: articles/communication-services/tutorials/hmac-header-tutorial.md
Service: azure-communication-services
Sub-service: identity
GitHub Login: @alexandra142
Microsoft Alias: apistrak

@madfr-at-vipps Thanks for the feedback! We are currently investigating and will update you shortly.

@madfr-at-vipps Thanks for bringing this to our attention. Your feedback has been shared with the content owner for further review.

@SnehaAgrawal-MSFT Plese close the ticket. Maxim added the Python example. This issue with mixing ASCII and UTF-8 encodings in the examples has been already fixed and tutorials are now up to date. Maxim replaced ASCII with UTF-8,

@madfr-at-vipps The issue is fixed, We will close this out but if you feel you need more information please just let us know.


XMC7200 svd parsing problems

cat1c8m.zip
Trying to parse attached svd with development version of cmsis-svd but ends with
  File "d:\test.py", line 59, in svd
    for peripheral in parser.get_device().peripherals:
                      ^^^^^^^^^^^^^^^^^^^
  File "C:\Users\abcd\src\cmsis-svd\python\cmsis_svd\parser.py", line 733, in get_device
    return self._parse_device(self._root)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\abcd\src\cmsis-svd\python\cmsis_svd\parser.py", line 692, in _parse_device
    peripherals.append(self._parse_peripheral(peripheral_node))
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\abcd\src\cmsis-svd\python\cmsis_svd\parser.py", line 629, in _parse_peripheral
    return SVDPeripheral(
           ^^^^^^^^^^^^^^
  File "C:\Users\abcd\src\cmsis-svd\python\cmsis_svd\model.py", line 384, in __init__
    for r in _none_as_empty(self.registers):
                            ^^^^^^^^^^^^^^
  File "C:\Users\abcd\src\cmsis-svd\python\cmsis_svd\model.py", line 399, in registers
    regs.extend(cluster.registers)
  File "C:\Users\abcd\src\cmsis-svd\python\cmsis_svd\model.py", line 330, in registers
    yield self.updated_register(reg, cluster, i)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\abcd\src\cmsis-svd\python\cmsis_svd\model.py", line 305, in updated_register
    name="{}_{}".format(clu.name % i, reg.name),
                        ~~~~~~~~~^~~
TypeError: not all arguments converted during string formatting

After removing CANFD peripherals there still seems to be a problem in PERI peripheral with strings that have dual pattern replacements.

Thank you very much for your feedback. But, for safety reasons about the potential bug exploitation in decompression tools, I accept only plain text file. Can you provide your SVD file in plain text, and host this file on github.com, please ?

Have fun …
cat1c8m.svd.txt

Thank's @BenBE


[19.09] chromium: 80.0.3987.116 -> 80.0.3987.122 (backport)

Motivation for this change
Backport of https://github.com/NixOS/nixpkgs/pull/81016.

platform
attribute
status
tester

x86_64
chromium

@Frostman

x86_64
nixosTests.chromium

@Frostman

x86_64
google-chrome

@primeos

Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

nixos/tests/chromium passed on x86_64


Fix race condition in TestAggregatorCollectListGet unit test

Before this fix it was possible for the Run method to start processing
summaries before all ADD events had been processed by the registered
event handlers. When that happened, the summary was discarded by
doCollect. The reason is that there is no guarantee that all event
handlers have completed by the time the cache reports that it has
synced.
Another issue was that len(a.dataCh) being 0 is not a good enough signal
to detect that summaries have been processed. The Run method may still
be executing doCollect for the last summary. To avoid this issue, we
close stopCh and wait for Run to return.
Fixes #3300
Signed-off-by: Antonin Bas<EMAIL_ADDRESS>

/skip-all


IF-Else statements problem verifying

When verifying my file. I print out that it is odd, or even, but the verify is saying that I am not. I attached a screenshot.

Tested fix, working.


dev-server:generic doesn't load assets

Describe the bug
I'm using dev-server:generic so I could add stylelintto the webpack configuration for build and serve, however static assets which were previously loadable via angular-devkit/build-angular:dev-server are now not being served.
To Reproduce
I followed exactly the stackoverflow answer on how to configure angular.json https://stackoverflow.com/questions/39187556/angular-cli-where-is-webpack-config-js-file-new-angular6-does-not-support-ng-e#answer-53910947
Expected behavior
Angular assets are served.
Screenshots

Builder:

@angular-builders/dev-server: ^7.3.1

Libraries

angular-devkit/build-angular: 0.13.7

Could you please share more details? Your webpack config, your agnular.json?

Apologies, I should have said this app is more or less based on the CLI angular new.
angular.json

{
  "$schema"<EMAIL_ADDRESS>  "version": 1,
  "newProjectRoot": "projects",
  "projects": {
    "myapp": {
      "root": "",
      "sourceRoot": "src",
      "projectType": "application",
      "prefix": "myprefix",
      "schematics": {
        "@schematics/angular:component": {
          "styleext": "scss"
        }
      },
      "architect": {
        "build": {
          "builder": "@angular-builders/custom-webpack:browser",
          "options": {
            "customWebpackConfig": {"path": "./custom-webpack.config.js", "replaceDuplicatePlugins": true},
            "outputPath": "dist/myapp",
            "index": "src/index.html",
            "main": "src/main.ts",
            "polyfills": "src/polyfills.ts",
            "tsConfig": "src/tsconfig.app.json",
            "assets": [
              "src/favicon.ico",
              "src/assets"
            ],
            "styles": [
<EMAIL_ADDRESS>              "src/styles.scss"
            ],
            "scripts": []
          },
          "configurations": {
            "production": {
              "fileReplacements": [
                {
                  "replace": "src/environments/environment.ts",
                  "with": "src/environments/environment.prod.ts"
                }
              ],
              "optimization": true,
              "outputHashing": "all",
              "sourceMap": false,
              "extractCss": true,
              "namedChunks": false,
              "aot": true,
              "extractLicenses": true,
              "vendorChunk": false,
              "buildOptimizer": true
            }
          }
        },
        "serve": {
          "builder": "@angular-builders/dev-server:generic",
          "options": {
            "browserTarget": "myapp:build"
          },
          "configurations": {
            "production": {
              "browserTarget": "myapp:build:production"
            }
          }
        },
        "extract-i18n": {
          "builder": "@angular-devkit/build-angular:extract-i18n",
          "options": {
            "browserTarget": "myapp:build"
          }
        },
        "test": {
          "builder": "@angular-devkit/build-angular:karma",
          "options": {
            "main": "src/test.ts",
            "polyfills": "src/polyfills.ts",
            "tsConfig": "src/tsconfig.spec.json",
            "karmaConfig": "src/karma.conf.js",
            "styles": [
<EMAIL_ADDRESS>              "src/styles.scss"
            ],
            "scripts": [],
            "assets": [
              "src/favicon.ico",
              "src/assets"
            ],
            "codeCoverage": true
          }
        },
        "lint": {
          "builder": "@angular-devkit/build-angular:tslint",
          "options": {
            "tsConfig": [
              "src/tsconfig.app.json",
              "src/tsconfig.spec.json"
            ],
            "exclude": [
              "**/node_modules/**"
            ]
          }
        }
      }
    },
    "myapp-e2e": {
      "root": "e2e/",
      "projectType": "application",
      "architect": {
        "e2e": {
          "builder": "@angular-devkit/build-angular:protractor",
          "options": {
            "protractorConfig": "e2e/protractor.conf.js",
            "devServerTarget": "myapp:serve"
          },
          "configurations": {
            "production": {
              "devServerTarget": "myapp:serve:production"
            }
          }
        },
        "lint": {
          "builder": "@angular-devkit/build-angular:tslint",
          "options": {
            "tsConfig": "e2e/tsconfig.e2e.json",
            "exclude": [
              "**/node_modules/**"
            ]
          }
        }
      }
    }
  },
  "defaultProject": "myapp"
}

custom-webpack.config.js
const StyleLintPlugin = require('stylelint-webpack-plugin');

const options = { 'files' : 'src/**/*.s?(a|c)ss', 'emitErrors' : false};
module.exports = {
  plugins: [
    new StyleLintPlugin(options)
  ]
}

A few questions:

It doesn't work with ng serve only or with ng build either?
It won't load any assets or just the styles?
Would you mind trying to do that with function? Might be related to #235 .

Thanks for bearing with me too, first jaunt into Angular..

It's the same with both. ng build doesn't copy the assets folder
styles.js is loaded, anything under assets isn't
it works!

Thanks for the help. I'll need to read the other ticket and understand it.


fix: make use of packages.json for all images

This uses a new introduced ARG PACKAGE_LIST to define which image we are building, and take the corresponding packages out of packages.json. Includes and excludes all work like before, just a slighty more narrowed down approach to make it work with the bluefin build proces.
Fixes: #276

I see warnings about:
Warning:  one or more build args were not consumed: [IMAGE_NAME]
https://github.com/ublue-os/bluefin/actions/runs/6058404397/job/16440514675#step:8:3258
I'm not sure if that will lead to problems. Otherwise I need to add it back in. I thought it was only used in build.sh

I think we are good, did a quick skopeo compare of older images and de ones just build. All that looks good.


Close resources after use - tests

While running sbt/test continuously I saw a steady increase in the used
heap. This is because CPGs weren't being closed at all and with ondisk
overflow that is actually problematic.
While we might turn off ondisk overflow for tests and such, it is still a
good idea to always close the resources in a clean way.
The change essentially cleans up the way we create/use test fixtures to
ensure that resources are always closed. With the change, running tests
continuously kept heap constant and low.
I refrained from using external library for ARM (such as better files) to keeps things lightweight.

The reason why I'm persistent on having this change in is because CPG is in reality an IO resource. And like any IO resource, such as DB or File, it should be closed cleanly, irrespective of the fact whether it causes a memory leak or not.
Also if you want to test ondisk overflow in tests, then enabling it may cause other problems.

@hubertp I think you are right. Since the CPG now has IO semantics (caused by the swap to disk), we need to properly close it.


The Spell "Strange Geometry" has no area included in its description.

As the title, Strange Geometry has a range of 60 ft which is included, but the area is 4 10 ft cubes, which is not anywhere in the spell description in Foundry (I needed to look it up on AoN).
Obviously a very small issue, but thought I should let you guys know.

You may be running an old version of the system

Weird. Up to date but not showing up in the monster's stat block. Well, no big deal.

You just need to refresh the copy.


Service Fabric Spec is Not ARM Spec

The host for the service fabric spec points to localhost and clearly couldn't be used in it's current form for code generation or external use. It does not belong in the master branch until it is done.
@msjeffreychen, please move this to a branch or request that @amarzavery move this to a branch.
@msjeffreychen, please rename the folder from 'arm_servicefabric' to 'servicefabric'.

@devigned - I had brought up the same point with jefferey Chen in the initial review of the spec. He said that is the right value for the host. It is not a regular arm service. It is a hosted service. Since he clarified it with his PM about this, I was fine with it. They are using the generic version of nodejs codegen.
Thanks,
Amar Zavery
On Mar 26, 2016, at 6:54 AM, "David Justice" <notifications<EMAIL_ADDRESS>wrote:
Assigned #207https://github.com/Azure/azure-rest-api-specs/issues/207 to @amarzaveryhttps://github.com/amarzavery.

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/Azure/azure-rest-api-specs/issues/207#event-604052195

@amarzavery I see. That's quite interesting. This is one of those places where I wish we stored the specs as yaml, so that we could add comments to the spec and describe why some things are the way they are.
Though, I don't think the spec should be in the 'arm_' folders. The spec is not an ARM API spec, it is a data plane spec for service fabric.
I'm going to change the title and redirect the issues.

@devigned - I argued the same thing. He published a node package named "azure-servicefabric" and then published another package named "azure-arm-servicefabric" insisting that his service is an ARM service.

Take a look at his explanation on the points raised in the initial PR https://github.com/Azure/azure-rest-api-specs/pull/129
Take  look at the conversation on this PR in node sdk https://github.com/Azure/azure-sdk-for-node/pull/1675

Highlighting the important point from the review in the PR #129 "Our commands will read a local config file to determine the hostname, we are not really using the hostname in the swagger file."

@amarzavery ok, then there should be a arm hostname in the spec and the commands can override that in the presence of the local config.

I looped in our PMs to explain in more detail. Thanks for bringing this up. I have checked again with our management. The story is that our team owns both SFRP (Service Fabric Resource Provider), and the software Service Fabric. SFRP is indeed an ARM service. Users could interact with SFRP to create Service Fabric clusters. The CLI commands and spec we added so far are used to interact with Service Fabric clusters, not SFRP. In this case, how should we name our spec? If we also added the spec to interact with SFRP in the future, would that confuse the customer, as some commands are under ARM, some commands are not? Do you have other customers having the similar situation? How should we spec this? Thanks.

@msjeffreychen, we expect there will be both an RP api and a service api (we call that management plane vs. data plane). We expect the management plane to be /arm-{service name}/ and the data plane to be /{service name}/. For the library naming, we suggest azure-arm-{service name} for management and azure-{service name} for data plane. A good example of this is azure-arm-storage and azure-storage.
If we all follow the same guidance, then there will be consistency and less likelihood of customers getting confused.

I will rename them. But, the CLI only supports 2 modes, ARM and ASM. In this case, how should I place my commands?

There are some commands that are mode agnostic. For example: azure login command. Anything that is common to both the modes or does not care about the mode should go [here] (https://github.com/Azure/azure-xplat-cli/tree/dev/lib/commands). Please take a look at the storage and batch commands.

I believe this can be closed since the spec was moved to an appropriate folder.


bump pipeline-model-def to account for cloudbees plugin name change

pipeline-model-definition dependency download was failing because of cloudbees plugin name change ... ref:  https://wiki.jenkins-ci.org/display/JENKINS/CloudBees+Docker+Workflow+Plugin
@bparees @oatmealraisin @tdawson FYI

[test]

[merge]

@stevekuznetsov @bparees - per the recent change for this repo to start leveraging rosie, how long should I expect to wait before either a test job gets queued or a merge request to get placed on the queue?
It is coming up on half an hour.

@gabemontero i'd have expected the usual 3 minute interval for PR processing.  something definitely seems wrong...  @stevekuznetsov ?

Looking

@gabemontero @bparees fixed

vagrant origin-local-checkout doesn't seem to have ever supported this repo... I'll need to add it. Sorry about that oversight.

definite progress @stevekuznetsov - the test job passed ; the merge job https://ci.openshift.redhat.com/jenkins/job/merge_pull_request_jenkins/5/ just failed; apologies, but the errors in the log at first blush don't make much sense to me - hopefully you have the necessary context

@gabemontero but at least Rosie can short-circuit the merge for you :)

On Wed, May 10, 2017 at 11:09 AM, Steve Kuznetsov<EMAIL_ADDRESS>wrote:

@gabemontero https://github.com/gabemontero but at least Rosie can
short-circuit the merge for you :)

works for me :-)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openshift/jenkins/pull/291#issuecomment-300512879,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADbadMCPduo87hEbP2N7djYtJaJ5VvSkks5r4dMUgaJpZM4NUX2L
.


repeated errors reported after set_position failure

Hi,
If I try to drive the uarm too far so that it returns an error, subsequent calls to set_position() also return errors/failure even if they are to valid positions. Is this expected? Do I have to do something to clear the error?
Thanks,
Randall.
e..g
Python 2.7.9 (default, Sep 17 2016, 20:26:04)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.

import pyuarm
myuarm=pyuarm.uarm.UArm()
pyuarm - INFO - pyuarm version: <IP_ADDRESS>
pyuarm - INFO - Connecting from port - /dev/ttyUSB0...
pyuarm - INFO - Connected...
pyuarm - INFO - Firmware Version: 2.2.1
myuarm.set_position(50,50,100)
True
myuarm.set_position(-150,150,100)
True
myuarm.set_position(-150,150,100,speed=50)
False
myuarm.set_position(-150,250,100,speed=50)
True
myuarm.set_position(-150,250,250,speed=50)
pyuarm - ERROR - Communication| ERROR: send #15 G0 X-150.0 Y250.0 Z250.0 F50.0
, received error from robot:
False
myuarm.set_position(-150,250,100,speed=50)
pyuarm - ERROR - Communication| ERROR: send #17 G0 X-150.0 Y250.0 Z100.0 F50.0
, received error from robot: $16 OK V2.2.1

False

myuarm.set_position(-150,150,100,speed=50)
pyuarm - ERROR - Communication| ERROR: send #19 G0 X-150.0 Y150.0 Z100.0 F50.0
, received error from robot: $18 OK V2.2.1

False

Hi @rbw42 , you could checkout this new commit 0b6f95

Hi altjz,
Well, that seems to have fixed the original problem, but now I have a new error:
Python 2.7.9 (default, Sep 17 2016, 20:26:04)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyuarm
>>> myuarm=pyuarm.uarm.UArm()
pyuarm - INFO - pyuarm version: <IP_ADDRESS>
>>> myuarm.connect()
pyuarm - INFO - Connecting from port - /dev/ttyUSB0...
>>> myuarm.set_position(-147.2,85.0,100.0,speed=50,wait=True)
pyuarm - ERROR - function - TypeError - 'NoneType' object is not iterable

The help for the UArm class methods like set_position() are now opaque, since they don't describe what the possible args are. Has the interface changed?
Cheers,
Randall.

Hi @rbw42 , Could you open the debug? And retry?
import pyuarm
arm = pyuarm.UArm(debug=True)

Here you go
>>> import pyuarm
>>> arm = pyuarm.UArm(debug=True)
pyuarm - INFO - pyuarm version: <IP_ADDRESS>
>>> arm.connect()
pyuarm - INFO - Connecting from port - /dev/ttyUSB0...
pyuarm - DEBUG - Received MSG: @1
>>> arm.set_position(-147.2,85.0,100.0,speed=50,wait=True)
pyuarm - DEBUG - Send #2 G0 X-147.2 Y85.0 Z100.0 F50.0
pyuarm - DEBUG - MSG Received: $2 OK
pyuarm - DEBUG - Send #3 M200
pyuarm - DEBUG - MSG Received: $3 OK V1
pyuarm - DEBUG - Send #4 M200
pyuarm - DEBUG - MSG Received: $4 OK V1
pyuarm - DEBUG - Send #5 M200
pyuarm - DEBUG - MSG Received: $5 OK V1
pyuarm - DEBUG - Send #6 M200
pyuarm - ERROR - function - TypeError - 'NoneType' object is not iterable
True
>>> pyuarm - DEBUG - MSG Received: $6 OK V1

BTW, I'm not a git guru. To get the commit version you mentioned, I did a git clone of the repo and then a git checkout 0b6f95. Let me know if I have to do something else. The original version I had installed was from installing via pip. That is uninstalled now.

Seems it caused by pyuarm didn't get a reply from check moving query.
Would you provide me the uArm firmware version and hardware version?
you could get them via
print(arm.firmware_version)
print(arm.hardware_version)

Python 2.7.9 (default, Sep 17 2016, 20:26:04)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyuarm
>>> arm=pyuarm.uarm.UArm()
pyuarm - INFO - pyuarm version: <IP_ADDRESS>
>>> arm.connect()
pyuarm - INFO - Connecting from port - /dev/ttyUSB0...
>>> arm.firmware_version
'2.2.1'
>>> arm.hardware_version
'2.1'

It was a 2016 Christmas present, so is presumably the most recent model.


Removed a wrong assert.

This fixes #15801
We ran into a strange crash on iOS (debug only). After removing the clutter I was able to reproduce it in a tiny app. You can check it out here.
The UI in JS and native are not always in sync (which is okay). Due to this, a native view might call back into JS, which is no longer present in the shadow view hierarchy there. I think this should be also okay.
TextInput in some cases calls into setIntrinsicContentView, where it triggers an overly enthusiastic NSAssert and crashes the app.
Test Plan
Check out textinput_stress
Rotate the simulator a few times to see the crash or the lack of crash.

Hey @shergin ,
I've updated the PR.
I checked that I see the log message (and not a crash) in my sample app.
FYI, there are several places in RCTUIManager.m with the same RCTAssert : RCTAssert(shadowView != nil, @"Could not locate view with tag #%@", reactTag);
I haven't touched them now, because I am not sure whether those are also bugs. My gut feeling is that most of those should be also only warnings.

I agree, it should be special internal method (something like executeBlockWithShadowView:forView:) which have to check shadowView for null and produce warning.


Switching to using Mariner's version of Python's junit_xml module for test verification.

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[X] The toolchain has been rebuilt successfully (or no changes were made to it)
[X] The toolchain/worker package manifests are up-to-date
[X] Any updated packages successfully build (or no packages were changed)
[X] Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
[X] Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
[X] All package sources are available
[X] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
[X] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
[X] All source files have up-to-date hashes in the *.signatures.json files
[X] sudo make go-tidy-all and sudo make go-test-coverage pass
[X] Documentation has been updated to match any changes to the build system
[X] Ready to merge

Summary

This allows us to drop relying on the flaky access to the internal Python modules feed.
Change Log

Switched to Mariner's junit_xml module.

Does this affect the toolchain?

No.
Test Methodology

PR check.

Auto cherry-pick results:

main :x: -> https://github.com/microsoft/CBL-Mariner/pull/6926

Auto cherry-pick pipeline run -> https://dev.azure.com/mariner-org/mariner/_build/results?buildId=464598&view=results


fix(containers): available buttons for created container

Now for created container available buttons are the same as for stopped.
Fixes #1063

Thanks @G07cha :+1:


Does it support BSC?

and if Yes, is there any example to do?

It supports custom networks so I assume it supports BSC too.
Define your provider options like this;
    const providerOptions = {
        walletconnect: {
            package: WalletConnectProvider,
            options: {
            rpc: {
                NETWORKID: "https://YOURPROVIDER"
            },
            network: "bsc"
            }
        }
    };

Then use;
try {
        provider = await web3Modal.connect();
    } catch(e) {
        onConnectError();
    }

Also if you want to make sure user is on same network, while interacting, use;
const chainId = await web3.eth.getChainId();
    if(chainId != YOURCHAINID) {
        alert("Wrong network! Switch to BSC");
        return;
    }```

Also add
```            CHAINID: {
                chainId: CHAINID,
                chain: "BSC",
                network: "BSC",
                networkId: NETWORKID
            }

to the library. It should be around on line 11K, simply CTRL+F and search for callisto-testnet, add yours below that

It supports custom networks so I assume it supports BSC too.
Define your provider options like this;
    const providerOptions = {
        walletconnect: {
            package: WalletConnectProvider,
            options: {
            rpc: {
                NETWORKID: "https://YOURPROVIDER"
            },
            network: "bsc"
            }
        }
    };

Then use;
try {
        provider = await web3Modal.connect();
    } catch(e) {
        onConnectError();
    }

Also if you want to make sure user is on same network, while interacting, use;
const chainId = await web3.eth.getChainId();
    if(chainId != YOURCHAINID) {
        alert("Wrong network! Switch to BSC");
        return;
    }

Also add
 CHAINID: {
                chainId: CHAINID,
                chain: "BSC",
                network: "BSC",
                networkId: NETWORKID
            }

to the library. It should be around on line 11K, simply CTRL+F and search for callisto-testnet, add yours below that

   const providerOptions = {
      /* See Provider Options Section */
      walletconnect: {
        package: WalletConnectProvider, // required
        options: {
          rpc: { 56: 'https://bsc-dataseed1.defibit.io/', },
          network: "binance",
        }
      },
      // Other Providers Go Here
    };

You can switch out "https://bsc-dataseed1.defibit.io/" to any other BSC RPC Node that you want.
In the Code it accepts binance as the network.
You dont have to do the extra steps as long as you put network as binance

BSC testnet was not supported yet

oh no 🤣

With stable version 2.0.0 of Web3Modal now released, we are officially dropping support for version 1.x
Due to this this issue/pr was marked for closing. It is highly recommended to upgrade as 2.x will be receiving further updates that will enable functionality for some of our newer sdks like auth and push as well as support for WalletConnect v2 (See this post about WalletConnect v1 being deprecated https://medium.com/walletconnect/walletconnect-v1-0-sunset-notice-and-migration-schedule-8af9d3720d2e)
If you need to continue using Web3Modal 1.x and require this feature/fix implemented, we suggest adding it via forking V1 branch.


Retrieve version of the app

I want to suggest also retrieve the current version of the app

Unfortunately that isn't possible using this module. The API/technique that this uses is mainly for retrieving all reviews for a given app.
I recommend using app-store-scraper to get the current version of a given app. Specifically the app method it provides.


fix: remove extra call to setup_logger()

Description
Removes seemingly extra call to setup_logger() in api, see #2797 for details.
Still not super familiar with API changes, so @johanneskoester please advise.
QC

[x] The PR contains a test case for the changes or the changes are already covered by an existing test case.
[x] The documentation (docs/) is updated to reflect the changes or this is not necessary (e.g. if the change does neither modify the language nor the behavior or functionalities of Snakemake).

@johanneskoester could you take a look at this when you get a chance? Would be good to get this fixed before moving forward with monitoring plugin.


Updated to Swift 5

@timle8n1 Just mentioning so this can be approved and merged quickly

@Fibonacci336 I don't have access to this repo any longer. I got Dynamit to open source it while I worked there but no longer do. Perhaps @jdamer or @nicholaslyon-dt could merge it - or figure out how to transfer ownership to me - as its been abandoned - I don't have much use for it - but I could probably deal with the odd PR.

Okay, I totally understand. I may just keep a fork and make that its own cocaopod but I would appreciate it if this can be merged in some way in the meantime. Thank you for getting back so quickly.

Okay, I totally understand. I may just keep a fork and make that its own cocaopod but I would appreciate it if this can be merged in some way in the meantime. Thank you for getting back so quickly.

Ideally you wouldn't make a public cocoapod with your repo before we seek to get this resolved. You can reference a GitHub repo in your pod file in the mean time.


New Contribution

Contributor: Nonameko
SSH Public key: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPaPaEoQ4o3CE//+K9d1aXK2j7/Lx9nXfHY4zWDcxVjJ
Attestation: Nonameko

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPaPaEoQ4o3CE//+K9d1aXK2j7/Lx9nXfHY4zWDcxVjJ

Your contribution process begins.

0000000011.csrs

[2024-06-10T05:29:21Z INFO  ceremony::secrets] Extracting secrets
[2024-06-10T05:29:21Z INFO  ceremony::contribute] Rescaling powers of tau..
[2024-06-10T06:34:16Z INFO  ceremony::contribute] Computing contribution proof..
[2024-06-10T06:36:02Z INFO  ceremony::contribution] Contribution written to "./contributions/0000000012.csrs"

Hi @zvorcuit The upload is finished 100%.

Hi @zvorcuit I met error when upload:
Welcome to Zircuit Mainnet Ceremony
<EMAIL_ADDRESS>Permission denied (publickey).
Connection closed.
Connection closed
bash: put: command not found
bash: quit: command not found

yh cus it wasnt your turn yet,, another is assigned to that 0014.csrs already,,, you would have to wait until its your turn to contribute

yh cus it wasnt your turn yet,, another is assigned to that 0014.csrs already,,, you would have to wait until its your turn to contribute

thank you, I'm waiting

Hi I'm on the way back to my home, about 3 more hours from now on. After that I will run it. Please wait for me, thank you so much.

I'm ready


Post error details when action fails

Post a comment like below when action fails:
  efficiency: 98.8091 %
  wastedBytes: 11697960 bytes (12 MB)
  userWastedPercent: 1.6116 %
Inefficient Files:
Count  Wasted Space  File Path
    6        4.9 MB  /var/cache/debconf/templates.dat
    4        3.2 MB  /var/cache/debconf/templates.dat-old
    6        1.2 MB  /var/lib/dpkg/status
    6        1.2 MB  /var/lib/dpkg/status-old
    5        400 kB  /var/log/dpkg.log
...(skipped)...
Results:
  PASS: highestUserWastedPercent
  PASS: highestWastedBytes
  FAIL: lowestEfficiency: image efficiency is too low (efficiency=0.988091457351898 < threshold=0.99)
Result:FAIL [Total:3] [Passed:2] [Failed:1] [Warn:0] [Skipped:0]

Done #4


Allow using Cloud Run instead of Cloud Functions

For customers that are not able to use Cloud Build to build functions provide the possibility to use Cloud Run with pre-built containers.
Containers are specified providing cloud_function_image_prefix, for example for value us-central1-docker.pkg.dev/${local.project_id}/${local.repository_name}/weka-functions-container, following containers are expected in local.repository_name in local.project_id project:

weka-functions-container-cloudinternal
weka-functions-container-scale-down
weka-functions-container-status

Containers can be build using pack:
for ENTRY_POINT in CloudInternal ScaleDown Status ; do
    pack build --builder=gcr.io/buildpacks/builder \
        --env GOOGLE_FUNCTION_TARGET=${ENTRY_POINT} \
        us-central1-docker.pkg.dev/${GCP_PROJECT_ID}/${REPOSITORY}/weka-functions-container-$(echo ${ENTRY_POINT} |\
        tr '[:upper:]' '[:lower:]')
done

Ideally, containers could be provided in WEKA managed repository, but customer should be able to point to their own repository and use customer's process to stage containers from external repository into internal ones.

can you please rebase on dev and point your PR there?

had one last comment, please squash the commits when you are done, we will test and if everything works we can include it on our next release

@kristina-solovyova is there something still required from my end? I'm not sure if terraform docs check failure requires my attention.


bwrite command does not support binary data types

Using binary types with 'bwrite' command results in the following error.
dy bwrite --table test  --input tests/resources/test_batch_write.json
[2023-09-13T09:07:17Z ERROR dy::batch] [skip] invalid/unsupported DynamoDB JSON format: Object {"B": String("dGhpcyB0ZXh0IGlzIGJhc2U2NC1lbmNvZGVk")}
[2023-09-13T09:07:17Z ERROR dy::batch] [skip] invalid/unsupported DynamoDB JSON format: Object {"BS": Array [String("dGhpcyB0ZXh0IGlzIGJhc2U2NC1lbmNvZGVk"), String("sdfsdhSRHwFEDw4f")]}

This issue seems to be due to the lack of implementation for B and BS types in the following.
https://github.com/awslabs/dynein/blob/f95b9fcce244e7a78b3112b68b13dd32fa959e16/src/batch.rs#L413-L475
I will work on this issue.

#170  resolved this issue.


Console empty string bug

Fixes #31 .
As suggested, I tried to add a check for command's return:
if let Err(err) = S::command(DRIVER_NUM, command::WRITE, s.len() as u32, 0)
                .to_result::<(), ErrorCode>()
            {
                return Err(err);
            }

But that didn't solve the problem, and from the console capsule's code it seems like that command will never return an error:
1 => {
                        // putstr
                        let len = arg1;
                        self.send_new(appid, app, kernel_data, len)
                    }

fn send_new(
        &self,
        app_id: ProcessId,
        app: &mut App,
        kernel_data: &GrantKernelData,
        len: usize,
    ) -> Result<(), ErrorCode> {
        app.write_len = kernel_data
            .get_readonly_processbuffer(ro_allow::WRITE)
            .map_or(0, |write| write.len())
            .min(len);
        app.write_remaining = app.write_len;
        self.send(app_id, app, kernel_data);
        Ok(())
    }

I've also added a guard clause in the write function of the Console API:
        if s.len() == 0 {
            return Ok(());
        }

This solves the problem, and it seems right for the write function to do nothing at all if there isn't anything to be written.

I found this note in the documentation of WRITE command:

Additional notes: A process may call this command with a write size of 0 to cancel a write transaction, if one is ongoing. Unless an error occurs, this will generate a write transaction completed event, regardless of whether or not a write transaction was already in progress.

However, it does not return an error and it does not generate an event (the process wouldn't remain yielded otherwise). Am I missing something?

Posted issue tock/tock#3433.


Banner native full width

You can make use of a native banner, which length has the device screen size?

@Angelk90 it's unclear to me what you're asking. Can you elaborate?

I think they were asking for a banner size that has the same width as the device's screen. But that's what smartBanner does, isn't it?

I would say the same, but that's still an assumption. But since there hasn't been a reply for over a month I'm going to close this.

@koenpunt, @dandesz198: Correct, you say good.

The ‘smartBanner’ is created exactly for this purpose.


Add Search Functionality

New command for steambot module allows users to search db from discord

I actually dont really much in the way of feedback for this. Looks good. My only feedback (which was something I was planning on doing in the command update) is to abstract the isolating the mentions as an argument. Since we only use the mentions for 2 commands its not a big deal either way and this might just obfuscate the code at such a small scale, but below is what I had implemented in my branch (since the command infrastructure really didnt have a way to handle passing the mentions to the command.action. It is just a helper function that strips the @mentions off of msg and passes it to the action function as the second parameter. Again only bringing this up for discussion, completely non-blocking Greenlight from me
const MongoDB = require('../../MongoDB/MongoDB')
const Commander = require('../CommanderInChief/commander-in-chief');

module.exports = function(bot) {

  var commands = [{
    keyword: '/games',
    helptext: 'Sends a list of all shared games between mentioned users',
    action: pullMentions(ShowAllSharedGames)
  },{
    keyword: '/pickgame',
    helptext: 'Sends a game chosen randomly from a list of games shared between mentioned users',
    action: pullMentions(PickRandomSharedGame)
  }];

  Commander.registerCommands("Steambot", commands);

  bot.on('ready', () => {
    console.info(`Steambot logged in as ${bot.user.tag}!`);
  });

  function pullMentions(action){
    return function(msg) {
      let arrMentions = msg.mentions.users.map(user => user.id)
      if(arrMentions.length > 1){
        action(msg, arrMentions);
      }
    }
  }

  function PickRandomSharedGame(msg, mentions){
    MongoDB.GetCommonGames(mentions).then(games =>{
      let rdmIdx = Math.floor(Math.random() * games.length)
      msg.channel.send(`Lets play ${games[rdmIdx].name}!`)
      MongoDB.Close()
    })
    .catch(err => console.log(err))
  };

  function ShowAllSharedGames(msg, mentions){
    MongoDB.GetCommonGames(mentions).then(games =>{
      msg.channel.send(`${msg.mentions.users.map(user => user.username).join(", ")} share: \n${games.map(game => game.name).join("\n")}`)
      MongoDB.Close()
    })
    .catch(err => console.log(err))
  };
}