[BUG] upgrade from 1.4.4 to 1.5.4 failed because of volumes keeping attached

Describe the bug
This the second time I tried updating Longhorn to 1.5.4 from 1.4.4. But again I can't get all the volumes to attach.
First the nodes didn't become ready. After setting the correct tag (as explained here https://github.com/longhorn/longhorn/issues/7212) the nodes became ready.
Directly some volumes became attached, without the pod was up. The pods that got to be attached I couldn't detach them.
Also some pods keeped  attaching. I didn't get them to attach. I tried restarting de nodes, starting de pod linked to the volume, disable selinux.
To Reproduce
Upgrade to 1.5.4 from 1.4.4 with the kubectl commando:
kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.5.4/deploy/longhorn.yaml

Expected behavior
Only the volumes attached that have k8s pods linked.
Support bundle for troubleshooting

Environment

Longhorn version: 1.5.4
Impacted volume (PV):

pvc-a35a936b-30c3-4892-84d1-adb2ce4c515a
pvc-c488336c-29ff-4dbe-8f9c-7c16ab5b2008
pvc-4d501d7e-43dd-4cbc-9341-dbb0a4403c5c
pvc-c488336c-29ff-4dbe-8f9c-7c16ab5b2008
pvc-0e68938d-3762-4d12-b8f5-0de9fd19bfa1
pvc-637564a8-270c-4862-bf85-deeefd12a8cb
pvc-f3b6b2de-dcaf-41a3-b019-a058aed1b58c

Installation method (e.g. Rancher Catalog App/Helm/Kubectl): Kubectl
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version: v1.28.8+k3s1

Number of control plane nodes in the cluster: 3
Number of worker nodes in the cluster: 2

Node config

OS type and version: AlmaLinux 9.3 (Shamrock Pampas Cat)
Kernel version: 5.14.0-362.24.2.el9_3.x86_64
CPU per node: 6.00
Memory per node: 15.34Gi
Disk type (e.g. SSD/NVMe/HDD): HDD
Network bandwidth between the nodes (Gbps): 100 Mbps

Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal): Baremetal
Number of Longhorn volumes in the cluster: 41

Hi @tijder,
Could you provide the support bundle for investigating?
Did you try to scale down and scale up the workload?
Any information from kubectl describe pod [attaching volumes pods name] ?

Hi @mantissahz, thanks for your reply. I emailed the support bundle to<EMAIL_ADDRESS>I tried scaling up and down. That didn't work. It keeped attaching the volume.
I have now reverted back to 1.4.4. When I reverted back there were still three volumes keeping attaching, but when I restart the node it was tryng to attach to it stopped attaching (I also tried that when on 1.5.4). So now everything is working fine again on 1.4.4.
I don't have time to again upgrade right know. But the command on 1.4.4 gives this info:
Name:             forgejo-db-598dd8867b-2xtsq
Namespace:        forgejo
Priority:         0
Service Account:  default
Node:             maloof/<IP_ADDRESS>
Start Time:       Sun, 07 Apr 2024 19:40:20 +0200
Labels:           io.kompose.service=forgejo-db
                  pod-template-hash=598dd8867b
Annotations:      <none>
Status:           Running
IP:               <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  ReplicaSet/forgejo-db-598dd8867b
Containers:
  forgejo-db:
    Container ID:   containerd://59845270dbb759748789a9bbace27dd8e5550ff4cff3aa4784a873e5aa593425
    Image:          postgres:15.3
    Image ID:       docker.io/library/postgres@sha256:8775adb39f0db45cf4cdb3601380312ee5e9c4f53af0f89b7dc5cd4c9a78e4e8
    Port:           5432/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Sun, 07 Apr 2024 19:40:42 +0200
    Ready:          True
    Restart Count:  0
    Environment:
      POSTGRES_DB:        gitea
      POSTGRES_USER:      gitea
      POSTGRES_PASSWORD:  gitea
      PGDATA:             /var/lib/postgresql/data/pgdata
    Mounts:
      /var/lib/postgresql/data from forgejo-claim-db (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-j9qdh (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  forgejo-claim-db:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  forgejo-claim-db
    ReadOnly:   false
  kube-api-access-j9qdh:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:                      <none>

Hi @mantissahz, thanks for your reply. I emailed the support bundle to<EMAIL_ADDRESS>I tried scaling up and down. That didn't work. It keeped attaching the volume.
I have now reverted back to 1.4.4. When I reverted back there were still three volumes keeping attaching, but when I restart the node it was tryng to attach to it stopped attaching (I also tried that when on 1.5.4). So now everything is working fine again on 1.4.4.
I don't have time to again upgrade right know. But the command on 1.4.4 gives this info:
Name:             forgejo-db-598dd8867b-2xtsq
Namespace:        forgejo
Priority:         0
Service Account:  default
Node:             maloof/<IP_ADDRESS>
Start Time:       Sun, 07 Apr 2024 19:40:20 +0200
Labels:           io.kompose.service=forgejo-db
                  pod-template-hash=598dd8867b
Annotations:      <none>
Status:           Running
IP:               <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  ReplicaSet/forgejo-db-598dd8867b
Containers:
  forgejo-db:
    Container ID:   containerd://59845270dbb759748789a9bbace27dd8e5550ff4cff3aa4784a873e5aa593425
    Image:          postgres:15.3
    Image ID:       docker.io/library/postgres@sha256:8775adb39f0db45cf4cdb3601380312ee5e9c4f53af0f89b7dc5cd4c9a78e4e8
    Port:           5432/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Sun, 07 Apr 2024 19:40:42 +0200
    Ready:          True
    Restart Count:  0
    Environment:
      POSTGRES_DB:        ***
      POSTGRES_USER:      ***
      POSTGRES_PASSWORD:  ***
      PGDATA:             /var/lib/postgresql/data/pgdata
    Mounts:
      /var/lib/postgresql/data from forgejo-claim-db (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-j9qdh (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  forgejo-claim-db:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  forgejo-claim-db
    ReadOnly:   false
  kube-api-access-j9qdh:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:                      <none>

Hi @mantissahz, did you receive the support bundle at<EMAIL_ADDRESS>

Hi @tijder,
Yes, I am looking into the SB to find some clues.

Hi @tijder
I did not see the upgrade path from v1.4.4 to v1.5.4 in the longhorn-manager-xxxx logs.
Did you restart the longhorn-manager pods during the upgrade?
I saw some logs in the longhron-manager pod
"Failed to sync Longhorn volume" func=controller.handleReconcileErrorLogging file="utils.go:68" Volume=longhorn-system/pvc-a35a936b-30c3-4892-84d1-adb2ce4c515a controller=longhorn-volume error="failed to sync longhorn-system/pvc-a35a936b-30c3-4892-84d1-adb2ce4c515a: failed to reconcile volume state for pvc-a35a936b-30c3-4892-84d1-adb2ce4c515a: failed to find instance manager for replica pvc-a35a936b-30c3-4892-84d1-adb2ce4c515a-r-2bef9dc5: cannot find the only available instance manager for instance pvc-a35a936b-30c3-4892-84d1-adb2ce4c515a-r-2bef9dc5, node pxxxxi01, instance manager image longhornio/longhorn-instance-manager:v1.5.4, type aio" node=cancellatum

but I did not see the logs of pvc-a35a936b-30c3-4892-84d1-adb2ce4c515a-r-2bef9dc5 and pvc-a35a936b-30c3-4892-84d1-adb2ce4c515a-e-2bef9dc5, they seemed to be deleted.
And I can not reproduce this issue by steps:

Fresh install Longhorn v1.4.4.
Create two deployment workloads(ex: volumes v1 and v2) and wait for the workload running.
Scale down one of two workloads (ex volume v2 becomes detached.)
Upgrade Longhorn to v1.5.4 and wait for all pods running.
Scale up the workload (volume v2) and wait for the workload running
Scale down all workloads and scale up all workloads.
Volumes are all attached.

Could you create the support bundle when you upgrade the Longhorn to 1.5.x and find this happens again?

Thanks for looking in to this! I will try it again Sunday. Then send the support bundle again.


Resident Evil 2 remake is too dark with DXVK 1.0

RESIDENT EVIL 2 / BIOHAZARD RE:2 (883710) worked fine with DXVK 0.96 but with DXVK 1.0 the image is very, very dark in-game. It reverts back to normal if I downgrade DXVK.

Software information
RESIDENT EVIL 2 / BIOHAZARD RE:2
https://store.steampowered.com/app/883710/
System information

GPU: Nvidia GTX 1060 6GB
Driver: 415.27
Wine version: Proton 3.16-8 beta
DXVK version: 1.0

Log files
steam-883710.zip

Still works fine on my RX 480. Please bisect the issue if you think this is a DXVK regression.
Please keep in mind that there is a game bug causing the image to be too dark on some systems when running above 60 FPS.

I don't have 60 FPS. What is "bisect the issue"?

https://git-scm.com/docs/git-bisect

So, what should I do with 'git bisect'?

You need to bisect it and test different versions of DXVK.

So, I have to compile them? I tried to compile DXVK once and failed. Are there compiled builds between 0.96 and 1.0 available? I would test them.

Are you using the dxvk version that is shipped with proton or have you tried dxvk by placing it next to the game? Just to eliminate proton in this equation.

Both. It started glitching when I tried DXVK 1.0 almost two weeks ago. I had Proton 3.16-6 or 3.16-7 back then. I've been using 0.96 since that. But now Proton got updated, got DXVK 1.0, and that happened again. If I replace Proton's DXVK with v0.96, the game works fine.

You could try setting d3d11.relaxedBarriers = False in the config file.
Although that doesn't really explain why it works for most people.

I have bisected the issue and found https://github.com/doitsujin/dxvk/commit/915091b76b2de06d04a4de0b050001b8e7c88169 to be the breaking point. Reverting it fixes the issue on both RE2 and DMC5.

Should be fixed as of<PHONE_NUMBER>90ae843cbdcd526f3c72087ab31888.
I don't know why using shift instructions (even arithmetic shifts, which should be equal to signed division) breaks on Nvidia, but it does.

I can confirm I have the same issue as reported on a NVIDIA GTX 980 with latest Proton.

Yes, everyone has this issue, just read the comment above for a fix.

I've identified the compiler bug, and it is already fixed in the most recent Vulkan developer driver at https://developer.nvidia.com/vulkan-driver. It should be fixed in our next mainline driver release as well.

arithmetic shifts, which should be equal to signed division

Arithmetic shift of negatives is not equal to division. Division rounds to zero, shift rounds to negative infinity.

The numbers in question are guaranteed to be a multiple of 4 (and technically also guaranteed to be non-negative).

@jeffbolznv I do not think you fixed it (in windows). See https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/333239/devil-may-cry-vresident-evil-2-biohazard-re2-brig/2341397/
Really, you should not play with llvm codebase if you do not know what you are doing ;)

Wasn't this found to be a game bug when running at low frame rates anyway?

Low? Is 100 Hz low? I do not think so.

Well I'm sorry that I wasn't able to guess your hardware and framerate based on absolutely no information whatsoever...

@doitsujin You are only working with Linux Directx, right)) I was asking that to Nvidia guy because bug is in Windows...

The bugfix I made was only in the Vulkan SPIR-V compiler and had something to do with shared memory ordering. It's possible the DX compiler could have a similar issue, but it would be in a different part of the code base. But it's also likely it could be something completely different.

Was that a genuine driver bug though? The game is known to rely on undefined behaviour wrt workgroup shared memory, which has also caued issues with RADV in the past.

I don't actually know. The change I made was for a different app, where it was fixing a legitimate compiler bug, and the same fix also fixed this bug. So we never debugged this particular shader in detail.


RoleDefinitionClient: preparing request failed

Bug Report

import path of package in question, e.g. .../services/compute/mgmt/2018-06-01/compute
SDK version e.g. master, latest, 18.1.0

Specify the exact commit if possible; one way to get this is the REVISION
column output by dep status "github.com/Azure/azure-sdk-for-go.

output of go version
import path: github.com/Azure/azure-sdk-for-go/services/authorization/mgmt/2020-10-01/authorization
SDK version: latest
go version: go1.18.1 windows/amd64

What happened?
I am creating a terraform provider and have recently started getting this error when trying to lookup a role definition (see error below), this was working a couple months ago but has now started exhibiting this issue.

╷
│ Error: loading Role Definition List: autorest/Client#Do: Preparing request failed: StatusCode=0 -- Original Error: clientCredentialsToken: cannot request token: Post "https://login.microsoftonline.com/d1fe8e44-4d35-4dad-8ea9-d9d9cb9a988c/oauth2/v2.0/token": context canceled
│
│   with avevarm_role_eligibility_schedule_request.avevarnd_cdotemptesting_devtest_key_vault_secrets_officer_neil_stevens_aveva_com,
│   on main.tf line 29, in resource "avevarm_role_eligibility_schedule_request" "avevarnd_cdotemptesting_devtest_key_vault_secrets_officer_neil_stevens_aveva_com":
│   29: resource "avevarm_role_eligibility_schedule_request" "avevarnd_cdotemptesting_devtest_key_vault_secrets_officer_neil_stevens_aveva_com" {
│

The error occurs on this line roleDefinitions, err := roleDefinitionsClient.List(ctx, scope, fmt.Sprintf("roleName eq '%s'", roleName)) and times out after around 7 minutes with the above error

What did you expect or want to happen?
This used to work and would lookup the ID of the role definition, I have tried specifying the ID and skipping the role definition ID lookup but the error then occurs on the next request.

How can we reproduce it?
See line above and use Azure service principal authentication

Anything we should know about your environment.
I am using environment variables to provide the ARM_CLIENT_ID, ARM_CLIENT_SECRET, ARM_TENANT_ID and ARM_SUBSCRIPTION_ID, the request is using Azure Service Principal authentication

The library you are using is our old SDK that we are deprecating. The old SDK is relying on some deprecated packages like ADAL and our new SDKs are more secure and comply with the latest SDK guidelines. You can use this migration guidance: https://github.com/Azure/azure-sdk-for-go/blob/main/documentation/MIGRATION_GUIDE.md to start your migration now.


In pgsql plugin deprecate min_idle_time, supersede by min_idle_count

The option min_idle_time was being used in r2d2's builder min_idle(u32) method which is described in r2d2 documentation as:
    /// Sets the minimum idle connection count maintained by the pool.
    ///
    /// If set, the pool will try to maintain at least this many idle
    /// connections at all times, while respecting the value of `max_size`.
    ///
    /// Defaults to `None` (equivalent to the value of `max_size`).
    pub fn min_idle(mut self, min_idle: Option<u32>) -> Builder<M> {
        self.min_idle = min_idle;
        self
    }

so to prevent confusion, I renamed min_idle_time plugin configuration option to more accurate min_idle_count. The min_idle_time still works but prints warning in logger.
Signed-off-by: Patrik Stas<EMAIL_ADDRESS>

Hi @ianco , can you take a look at this as well?


Switch app from CRA to Vite

Hi @furkanmutlu I can do this task also. I have read few articles on the internet on how to migrate from CRA to Vite.js and by following their suggested steps i can migrate this project from CRA to Vite.js.


Update live nonlinear fitting

Broke apart the notebook for better flow and added more figures to allow as-you-scan updates.
Also added the notebook to the documentation.

Perfect, thank you @JunAishima.


Backend dont sent video files.

Backend stopped to sent video files.
"message: "ERR_SENDING_WAPP_MSG"
statusCode: 400"

Sometimes the connection goes stale. Restart the backend.
Make sure you are using google chrome headless, because Chromium (Puppeteer default) does not have the required Ffmpeg library

How to change the Puppeteer to use Chrome (Full) on whaticket @ricco-douro? Sorry for my ignorance.

backend
.env
CHROME_BIN=C:\Program Files\Google\Chrome\Application\chrome.exe
or
CHROME_BIN=/usr/bin/google-chrome
If you dont know where Chrome is installed:
whereis google-chrome

NODE_ENV=
BACKEND_URL=http://<IP_ADDRESS>
FRONTEND_URL=http://<IP_ADDRESS>:3000
PROXY_PORT=8080
PORT=8080
DB_DIALECT=
DB_HOST=localhost
DB_USER=root
DB_PASS=
DB_NAME=WA-HASBUNA
JWT_SECRET=3123123213123
JWT_REFRESH_SECRET=75756756756
IO_REDIS_SERVER=
IO_REDIS_PORT=
CHROME_BIN = "C:\Program Files\Google\Chrome\Application\chrome.exe"

Many thanks guys, i will test this soon!


NiceHash Equihash miner fails to benchmark on GPUs

From @nYrXvcpk2l47ciid on October 29, 2016 23:13
The NiceHash Equihash miner fails to benchmark on GPUs when the "t" flag is set to 0.
Without the "t" flag set, the benchmark is performed on both the CPU and GPU.
C:\Users\Sydney\Desktop\Files\NiceHashMiner_v<IP_ADDRESS>\bin\nheqminer_v0.3a>nheqminer.exe -b -cd 0

        ==================== www.nicehash.com ====================
                Equihash CPU&GPU Miner for NiceHash v0.3a
        Thanks to Zcash developers for providing base of the code.
            Special thanks to tromp and xenoncat for providing
                 optimized CPU and CUDA equihash solvers.
        ==================== www.nicehash.com ====================

Setting log level to 2
[2016-10-29 16:44:46.674864][0x0006c7d4]: Using SSE2: YES
[2016-10-29 16:44:46.676863][0x0006c7d4]: Using AVX: YES
[2016-10-29 16:44:46.678864][0x0006c7d4]: Using AVX2: YES
[2016-10-29 16:44:46.825014][0x0006c7d4]: Benchmarking CUDA worker (CUDA-TROMP) GeForce GTX 750 (#0)
 BLOCKS=28, THREADS=64
[2016-10-29 16:44:46.944156][0x0006c7d4]: Benchmarking CPU worker (CPU-XENONCAT-AVX2)
[2016-10-29 16:44:46.946158][0x0006c7d4]: Benchmarking CPU worker (CPU-XENONCAT-AVX2)
[2016-10-29 16:44:46.948161][0x0006c7d4]: Benchmarking CPU worker (CPU-XENONCAT-AVX2)
[2016-10-29 16:44:46.950162][0x0006c7d4]: Benchmark starting... this may take several minutes, pleas
e wait...
[2016-10-29 16:44:47.431624][0x0006c7d4]: Benchmark done!
[2016-10-29 16:44:47.432624][0x0006c7d4]: Total time : 421 ms
[2016-10-29 16:44:47.433626][0x0006c7d4]: Total iterations: 200
[2016-10-29 16:44:47.435627][0x0006c7d4]: Total solutions found: 4
[2016-10-29 16:44:47.436628][0x0006c7d4]: Speed: 475.059 I/s
[2016-10-29 16:44:47.438630][0x0006c7d4]: Speed: 9.50119 Sols/s

The results reported are likely sums of the units' hash rates.
With the number of CPU threads set to 0, however, the benchmark does not run properly.
C:\Users\Sydney\Desktop\Files\NiceHashMiner_v<IP_ADDRESS>\bin\nheqminer_v0.3a>nheqminer.exe -b -cd 0 -t 0

        ==================== www.nicehash.com ====================
                Equihash CPU&GPU Miner for NiceHash v0.3a
        Thanks to Zcash developers for providing base of the code.
            Special thanks to tromp and xenoncat for providing
                 optimized CPU and CUDA equihash solvers.
        ==================== www.nicehash.com ====================

Setting log level to 2
[2016-10-29 16:45:07.748957][0x0006c7d8]: Using SSE2: YES
[2016-10-29 16:45:07.750960][0x0006c7d8]: Using AVX: YES
[2016-10-29 16:45:07.752962][0x0006c7d8]: Using AVX2: YES
[2016-10-29 16:45:07.897099][0x0006c7d8]: Benchmarking CUDA worker (CUDA-TROMP) GeForce GTX 750 (#0)
 BLOCKS=28, THREADS=64
[2016-10-29 16:45:08.019217][0x0006c7d8]: Benchmark starting... this may take several minutes, pleas
e wait...
[2016-10-29 16:45:08.077273][0x0006c7d8]: Benchmark done!
[2016-10-29 16:45:08.079274][0x0006c7d8]: Total time : 37 ms
[2016-10-29 16:45:08.081276][0x0006c7d8]: Total iterations: 200
[2016-10-29 16:45:08.082277][0x0006c7d8]: Total solutions found: 0
[2016-10-29 16:45:08.084279][0x0006c7d8]: Speed: 5405.41 I/s
[2016-10-29 16:45:08.085280][0x0006c7d8]: Speed: 0 Sols/s

Now we don't get correct results for the GPU's hash rate.
So of course it is necessary to set the "t" flag to 0, but the miner does not react to this correctly.
This could be an issue with nheqminer.cs (https://github.com/nicehash/NiceHashMiner/blob/master/NiceHashMiner/Miners/nheqminer.cs#L66$L71) or the miner itself.
Copied from original issue: nicehash/NiceHashMiner#295

From @S74nk0 on October 30, 2016 20:41
NiceHash Miner handles this correctly. You can check your logs that generate benchmark input. If you are referring this as an issue with nheqminer open an issue there. But nheqminer is intended to run on CPU by default.

From @ansemz on October 30, 2016 2:48
I have the same issue.

From @ansemz on October 31, 2016 3:47
[2016-10-30 09:55:34] [INFO] [BENCHMARK] Benchmark starts
[2016-10-30 09:55:34] [INFO] [nheqminer-MINER_ID(6)-DEVICE_IDs(0)] Starting benchmark: -b   -t 0  -cd 0
[2016-10-30 09:55:34] [INFO] [nheqminer-MINER_ID(6)-DEVICE_IDs(0)] Using miner: bin\nheqminer_v0.3a\nheqminer.exe
[2016-10-30 09:55:35] [INFO] [BENCHMARK] Final Speed: 0.000 H/s
[2016-10-30 09:55:35] [INFO] [BENCHMARK] Benchmark ends
[2016-10-30 09:55:35] [INFO] [FormBenchmark] EndBenchmark() benchmark routine finished
[2016-10-30 09:55:35] [INFO] [CopyBenchmarks] Checking for benchmarks to copy
[2016-10-30 09:55:42] [INFO] [NICEHASH] Balance get
[2016-10-30 09:55:52] [INFO] [nheqminer-MINER_ID(7)-DEVICE_IDs(NOT_SET)] NEW MINER CREATED
[2016-10-30 09:55:53] [INFO] [BENCHMARK] Benchmark starts
[2016-10-30 09:55:53] [INFO] [nheqminer-MINER_ID(7)-DEVICE_IDs(0)] Starting benchmark: -b   -t 0  -cd 0
[2016-10-30 09:55:53] [INFO] [nheqminer-MINER_ID(7)-DEVICE_IDs(0)] Using miner: bin\nheqminer_v0.3a\nheqminer.exe
[2016-10-30 09:55:54] [INFO] [BENCHMARK] Final Speed: 0.000 H/s
[2016-10-30 09:55:54] [INFO] [BENCHMARK] Benchmark ends

0.3a version was compiled only for cuda compute 5.2 , your card is older, you need compile cuda_tromp.dll for your card or use older (slower) from version 0.2a

@chronosek Thank you. it works.

@chronosek Thank you!


increase default timeout to 30s, and make configurable

What

Set default HTTP timeout to 30s
Add TIMEOUT environment variable
Restrict configured value to between 10s and 120s

How to review

Run make debug
Test florence on a really slow connection and get a timeout after 30s
Run TIMEOUT=10 make debug
Check startup logs for timeout being set to 10s
Run TIMEOUT=5 make debug
Check startup logs for invalid timeout error and timeout being set to 10s
Run TIMEOUT=150 make debug
Check startup logs for invalid timeout error and timeout being set to 120s

Who can review
Anyone except @ian-kent

LGTM, probably worth @Crispioso or @jondewijones taking a look.


feat (RingTheory/Binomial) : Multichoose at negative arguments

This PR adds some lemmas for evaluating Pochhammer polynomials and the multichoose function at negative arguments.  This is preparation for identities involving generalized binomial coefficients.

If you can make Ruben and my final suggested changes, this looks good. Apologies this took so long!
bors d+

bors r+


Update go dependencies for 2.41

Signed-off-by: Julien Pivotto<EMAIL_ADDRESS>

:+1: Though it'd be nicer to have the unrelated docs changes in a separate commit at least.

Ah. They are related of course. Ignore my comment.
:+1:


Black mesa - separate episode titles in menu from those in game

The episode titles in the menu use the same texts as those that appear in the game, however are displayed in reverse.
Probably best to try and edit the menu files to separate those, or otherwise give up on translating the titles.

Unfortunately there's no apparent configuration for that.


hello

BaseGame-master.zip
Live Game URL:
Code Repository URL:

@efren36066 , You have to provide the two urls according to the instructions.  Come visit us at the booth and we can help you out if needed.

Thank you for your submission! Unfortunately you were not selected as a winner. Here's some notes we had:
You did not follow instructions for submitting your game.
Thank you for participating and we hope you enjoyed the competition!


Remove commas for dist and sudo keys

Hi!
I work at travis and saw this repo pop up in our error logs, looks like the comma at the end of these two lines is preventing the build from starting correctly.
I hope this PR helps fix that!

Looks like there's still some things left to figure out, but this should give you actual log output to go from. :)

Tks :) 👍


[SPARK-42301][SQL] Assign name to _LEGACY_ERROR_TEMP_1129

What changes were proposed in this pull request?
This PR proposes to assign name to _LEGACY_ERROR_TEMP_1129, "UNABLE_TO_INFER_SCHEMA".
Why are the changes needed?

We should assign proper name to LEGACY_ERROR_TEMP*
Does this PR introduce any user-facing change?

No
How was this patch tested?

./build/sbt "sql/testOnly org.apache.spark.sql.SQLQueryTestSuite*"

cc @srielau @MaxGekk @cloud-fan Please review this when you find some time

Test fails since we don't have 42KD9 in SQLSTATE lists.
Please refer to https://github.com/apache/spark/pull/39886.

Let me rebase to master once https://github.com/apache/spark/pull/39886 get merged.

+1, LGTM. Merging to master/3.4.
Thank you, @itholic and @srielau for review.


Clear text password stored on disk

Currently the lib isn't usable in production since it stores the password in NSUserDefaults. There is an existing issue proposing to use an encrypted Realm: https://github.com/realm-demos/realm-loginkit/issues/24 but it sounds like it's more of a "nice to have" instead of a must.
The lib needs to either store the password in the Keychain or use another more secure approach

I'm curious as to why you opened a new issue instead of adding a comment to that existing issue. XD
Yeah, the original design intent of this login controller was for demo apps, where the password was more often than not going to simply be password. I'm working on slowly making it a production ready library for actual shipping apps, for both Realm and third party users, but the current priority is adapting the logic to allow additional authentication methods with it.

The referred issue was saying it'd be "somewhat nicer" to fix this and it wasn't assigned to anyone, so it wasn't clear if that's going to be addressed or not. If you feel this is already being tracked over there - just close this issue 👍

Yeah, I should have worded that nicer, sorry! I'll update the original issue to increase its urgency.
It's on my list. :) I'm planning to overhaul that system so a history of past ROS credentials can be brought up (which will definitely be encrypted)!

Thanks Tim 👍


Add pre-commit-hooks

This is meant to be a starting point. We'll add the hooks one after another to prevent to many changes to be made at a time.
Here we start with black as  the first pre-commit-hook.
make sure you have installed pre-commit ( pip install pre-commit) then simply run pre-commit install and you set.

One more thing: This file is ending in .yaml, other YAML files in our repository end in .yml. Should we try to stay consistent here?


Route model binding behaviour changed in 9.14

Laravel Version: 9.14.0
PHP Version: 8.1.6
Database Driver & Version:

Description:
I've just discovered a breaking change that appeared between 9.13.0 and 9.14.0. I've got a complex use-case but I've tried to break it down. Here's the route set up that was working in 9.13.0.
Route::get('{university}/{campus:slug}/categories/{category}', [...]);

The intention here is that the campus record is scoped to the institution and that the category is not scoped to other route models. However, after upgrading to 9.14.0 it appears Laravel is also trying to scope the category to the campus and blowing up because the association does not exist:
Call to undefined method App\Models\Campus::categories()

Totally appreciate if perhaps my mixed use of nested routing and non-nested routing is unintended behaviour and that this is actually a fix, but thought it was worth bringing up. I'll roll back to 9.13.0 in the meantime.
Steps To Reproduce:
I have created a repo here: https://github.com/dwightwatson/routing-bug
If you pull it down and run php artisan test it should pass using the SQLite database. If you open composer.json and bump to Laravel 9.14.0 and re-run the tests it should fail.

@ksassnowski could this be because of your PR? https://github.com/laravel/framework/pull/42425
@dwightwatson what happens if you revert those changes?
Right now, there indeed is no documentation about this behavior for three params: https://laravel.com/docs/9.x/routing#implicit-model-binding-scoping

Yeah, it works on Laravel 9.14.0 if I revert the changes from that PR.

I get that my use-case is probably uncommon (will be interesting to see if it affects other people as well) so I'm not fussed if this becomes the new default behaviour. But perhaps a good opportunity to make a call on what should happen when dealing with more than 2 params.

I have the same issue after upgrade to 9.14

This probably due to this line here https://github.com/laravel/framework/blob/9.x/src/Illuminate/Routing/ImplicitRouteBinding.php#L49
It checks if the parameter name exists in the route's binding field. Since my change made it so that if any of the parameters provides a custom binding field, every parameter gets added to the route's binding field (but possibly with null). This would mess up the array_key_exists call though. The fix would probably be to also check that the value for the binding field isn't null before treating it as a scoped binding.

I'll send a PR for this shortly.

@driesvints Can you maybe point me to the tests that cover the ImplicitRouteBinding class? It doesn't seem to have its own tests.

Nevermind, I don't know why PhpStorm didn't find ImplicitRouteBindingTest...

I've submitted a PR (#42517) that fixes this. I've also tested the changes against the repository provided by @dwightwatson  and the tests pass again.

Thanks for the quick turnaround @ksassnowski, champion!


[BUG] [1.18.2] Visual Bug with Champions Mod

Description
Champions adds mobs with health bars on scree and having Dynamic Crosshair kind of doubles it.
Steps to Reproduce

Spawn/Find a Champions mob
Have Dynamic Crosshair

Expected Behavior
The second "moving" bar shouldn't be there
Screenshots

Game Logs
I don't think this is needed but here
Other Mods
champions-forge-1.18.2-<IP_ADDRESS>
Additional Information
Versions
Minecarft : 1.18.2
Forge : 40.1.92
Soulder Surfing : 2.2.17
If this isn't able to be fixed (or caused) by your end then I can report this to Champions.

Thanks for the report! Champions is not using the forge events correctly here. I will open an issue with a more detailed description on how to fix this issue in their repo tomorrow.

Should be fixed on champions' side. Feel free to reopen this thread if the issue persists.


Add itsta.txt

Request to add the Instituto Tecnologico Superior de Tantoyuca to the list of universities available to request access to JetBrains tools.

@HugoLuna5 First stage of verification passed, official domain is itsta.edu.mx as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

@HugoLuna5 Thank you for your patience while waiting for a review and processing your request. Pull request merged.


Multiple data annotations containing the same representation doesn't work

Having multiple @api-data annotations that contain the same representation type seem to break API Blueprint generation, only setting up a single reference to that representation.
@api-data somekey (\RepresentationName) - Description
@api-data somekey1 (\RepresentationName) - Description
@api-data somekey2 (\RepresentationName) - Description

All three somekey datas will be generated, but only one of them will have (Representation) as the type it seems.
// @muglug

Spent some time investigating this, and I couldn't replicate it.


near-operation-file-preset doesn't support documentTransforms yet

near-operation-file-preset lacks support for the new documentTransforms config
see: https://the-guild.dev/graphql/codegen/docs/advanced/document-transform
Not too familiar with the internals of this stuff but I think it's just a matter of passing it through here?
diff --git a/packages/presets/near-operation-file/src/index.ts b/packages/presets/near-operation-file/src/index.ts
index c9dd7729a..4afd35f95 100644
--- a/packages/presets/near-operation-file/src/index.ts
+++ b/packages/presets/near-operation-file/src/index.ts
@@ -345,6 +345,7 @@ export const preset: Types.OutputPreset<NearOperationFileConfig> = {
       artifacts.push({
         filename,
         documents: [combinedSource],
+        documentTransforms: options.documentTransforms,
         plugins,
         pluginMap,
         config,

if that's the right solution, I'm happy to throw this in a pr

@superfreddialpad Please send a PR!

working on a pr, currently having an issue updating a couple of the relevant dependencies:
even after bumping @graphql-codegen/plugin-helpers to 4.1.0, it seems like version that's installed still has graphql

working on a pr, currently having an issue updating a couple of the relevant dependencies. Apologies for my ignorance of the build system here.
even after bumping @graphql-codegen/plugin-helpers to 4.1.0, it seems like version that's installed still has a type for GenerateOptions which doesn't have documentTransforms. Does something need to happen in the main repo for the types to be regenerated? I don't see a 4.1.0 branch for plugin helpers there.


Missing allow quoted data in DslCsvDataSet

Issue
When using CSV data which then contains JSON data and with a different type of delimiter (specifying \n or other types as a delimter) the JMeter DSL runner fails to run and reads the data as
Sample JSON CSV data
HeaderValue
[{ "keyValue1" : "dataValue1"}]
[{ "keyValue2" : "dataValue2"}]
[{ "keyValue3" : "dataValue3"}]
Url to pass values into:
https://fakeurl.com/testing/
Body: ${HeaderValue}
------ Current behaviour -----
Url: https://fakeurl.com/testing/
Body: '< EOF >'
----Expected behaviour----
Url: https://fakeurl.com/testing/
Body: [{ "keyValue1" : "dataValue1"}]
Url: https://fakeurl.com/testing/
Body: [{ "keyValue2" : "dataValue2"}]
etc....
Additional information
Option is avaliable in Jmeter. Please see screenshot below.

https://jmeter.apache.org/images/screenshots/csvdatasetconfig.png

Please add the "Allow quoted data?" flag to the .Net configuration.
Notes
Love the library and the simplification for .Net yet with this feature missing it makes it very difficult to post preconfigured JSON test data to an endpoint. Other alternatives is having a "fixed" JSON payload in the body section, which does work, yet you loose the dynamic data insertion for a steadyload and rampup of changing datra for a given endpoint that may be configured to take multiple JSON inputs.

Hello, thank you for trying and asking about this and providing so well formatted report.
Currently the CsvDataSet element already sets allow quoted data to true. This was done to standarize the formatting of CSV files regardless if random order is required or not (random order uses Blazemeter plugin which contains Random CSV Data Set Config element, and such element does not provide a setting to disable such behavior).
In your case you can adapt the csv by enclosing with quotes and replacing each quote with double quotes (a standard CSV format for quoted values). Eg:
HeaderValue
"[{ ""keyValue1"" : ""dataValue1""}]
"[{ ""keyValue2"" : ""dataValue2""}]
"[{ ""keyValue3"" : ""dataValue3""}]

Do you think that with such workaround is still required to add support for the "unquoted" option? That would require extending the BM plugin to support the unquoted case)?

I will try your suggestion tomorrow and feedback to you. Adding this in the CSV docs section may help others as well should it work.

@rabelenda - While thinking about your suggestion, I think the Allow Quoted data should be allowed as your suggestion means that the payload is not conforming to the JSON standard. This requires re-working of any JSON data to have an invalid JSON payload which is means you are diverging from standards.
While I appreciate that you are trying to standardise things, sticking to the standards for a given language should be a priority.
Additional examples.... If you are posting XML, HTML, JS, etc directly you should have the ability to send the data verbatim for that given row in a CSV. Exactly like producer and consumer would act and form/produce/send the markup for each request.


No longer tracking pats between logins

Ever since 6/29/2022 the plugin is now starting from 0 every time I log in.

Ok it suddenly started working again no idea why. I don't know what changed, I haven't been touching my plugins.

It seems to either load my total pets or not at random Im not sure whats going on :)

It's counted separately per character, using currently logged char name as a key. Any chance you simply have 2 different chars and see different counter values?
Only other (and super unlikely) way to break it that i can see is:

unable to access plugin config (PatMe.json located in %appdata%\XIVLauncher\pluginConfigs)
unable to read current player name, internal Dalamud data, just works


feat: Finish scope sync for both iOS and Android

Add scope sync methods for setTag, setExtra, setUser, addBreadcrumb, clearBreadcrumb for iOS.
Fixes setUser not taking non-default data and clearBreadcrumbs on Android.
Adds test for the JS side of the bridge, and methods to test scope sync on the sample apps.
Tested on the v3 sample app.

@philipphofmann Do you mind having a quick run through of this as it contains a lot of swift? (and the fact that I haven't really done much swift before) Thanks!


fix: make fix compatible with node < v6

Problem
My last PR broke for node versions < 6
Solution
Test better. This solution is has been tested on the following versions:

iojs-v1.0.0
iojs-v2.0.0
iojs-v3.0.0
v4.0.0
v4.9.1 (lts/argon)
v5.0.0
v6.17.1 (lts/boron)
v7.0.0
v8.17.0 (lts/carbon)
v9.0.0
v10.0.0
v11.0.0
v12.16.3
v12.18.3 (lts/erbium)

Testing
nvm install <version>
npm test

cbuild on travis is failing too - https://travis-ci.org/github/sarosia/buffer-indexof-polyfill/builds/723207199.

Linted. The build is passing now.


reconciler/managed: add crossplane_resource_drift_seconds metric

Description of your changes
Adds a metric crossplane_resource_drift_seconds that records the time since the previous reconcile when a resource was found to be out of sync.
As we don't record the last reconcile on the object (for reasons, we cannot update an object on every observe), we count from the last reconcile in the same process. This means obviously that we don't emit any metric when the provider restarts.
I have:

[x] Read and followed Crossplane's contribution process.
[x] Run make reviewable test to ensure this PR is ready for review.

How has this code been tested

This was merged via https://github.com/crossplane/crossplane-runtime/pull/683.


Change name from cherrytree to tinytree

Closing in favour of https://github.com/raunakab/tinytree/pull/16. This branch had an invalid name.


Schema change

The activity log schema had more changes than what's outlined above. For example, Category is now CategoryValue.

Where can I get the latest schema? Is it documented?
In the future, we would like to get advanced notification on schema changes. Is such service available?

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

ID: 2c54c118-8930-9afa-a3f8-c11367ba62bc
Version Independent ID: ec8d211f-9814-acaa-98b0-cef46204a301
Content: Collect Azure Activity log with diagnostic settings (preview) - Azure Monitor - Azure Monitor
Content Source: articles/azure-monitor/platform/diagnostic-settings-legacy.md
Service: azure-monitor
Sub-service: logs
GitHub Login: @bwren
Microsoft Alias: bwren

@aka0 The document you have been following outlines the legacy activity log collection. I would suggest you to refer this document for the activity log schema.
Hope this helps!

thanks @SwathiDhanwada-MSFT.
@aka0  -
We will now close this issue. If there are further questions regarding this matter, please reply and we will gladly continue the discussion.


Wiki links problem

The links in Quick Navigation in the wiki are all absolute and point to Sandertv/BlockSniper.
They should be made relative.

Whoops. I'll fix that quickly.

Fixed, thanks!


Refactor component code

General Support Request
There is a LOT of code in this element.
Support request
Refactor the code so that there is reasonable sanity for what code should be in what file. There is base-input.js and then there is auro-input.js. With a lot of recent feature adds we have lost sense of what code should be in what file.
auro-input is a large and complex element. Should we consider breaking this into smaller elements with dedicated concerns? E.g. breaking out the credit card icon feature could be an option? What about breaking up concepts into individual js files like having a dedicated js file for supporting the password toggle feature?

Closing in favor of

https://github.com/AlaskaAirlines/auro-input/issues/165


I can't control the device on my pc even tho i have usb debugging enabled

There also isn't any error and i have tried many things but none of them worked, my phone is a redmi 9, can someone help me?

https://github.com/Genymobile/scrcpy#prerequisites
https://github.com/Genymobile/scrcpy/blob/master/FAQ.md#mouse-and-keyboard-do-not-work

Thanks, i have android 11 as i checked and i dont really have a popup and my screen is unlocked, so idk what to do?


multiple windows of nemo closing together, turns out to be crashed

Describe the bug
Several windows of nemo closing together when sending killactive (note that this is not real kill) and a coredump can be found in systemd journal.
Steps To Reproduce
Steps to reproduce the behavior:

Open several instances of nemo from a wlroots based compositor e.g. sway or hyprland.
Press hotkeys attached to killactive on one window.
Get systemd-coredump message from journal (I use gnome-logs for convenience).

Expected behavior
The nemo window should exits one per time, not closing together, and not coredump as well.
Additional context

Nemo windows do share one process id, but this seems to be not the case as killactive just closes a window, not killing it. (however, this may be misleading as someone mentioned that steam also exits its background process when using killactive)
This issue didn't exist on Arch Linux. Just to mention that there may be something we should patch.
This is the content of coredump:

Process 46111 (.nemo-wrapped) of user 1000 dumped core.

Module librsvg-2.so.2 without build-id.
Module libpixbufloader-svg.so without build-id.
Module libFcitx5GClient.so.2 without build-id.
Module im-fcitx5.so without build-id.
Module libdconfsettings.so without build-id.
Module libcap.so.2 without build-id.
Module libicudata.so.72 without build-id.
Module libsystemd.so.0 without build-id.
Module libbrotlicommon.so.1 without build-id.
Module libxklavier.so.16 without build-id.
Module libgnomekbd.so.8 without build-id.
Module libpcre.so.1 without build-id.
Module libGLX.so.0 without build-id.
Module libXdmcp.so.6 without build-id.
Module libXau.so.6 without build-id.
Module libGLdispatch.so.0 without build-id.
Module libdatrie.so.1 without build-id.
Module libxml2.so.2 without build-id.
Module libjson-glib-1.0.so.0 without build-id.
Module libicui18n.so.72 without build-id.
Module libicuuc.so.72 without build-id.
Module libdbus-1.so.3 without build-id.
Module libatspi.so.0 without build-id.
Module libbrotlidec.so.1 without build-id.
Module libbz2.so.1 without build-id.
Module libgraphite2.so.3 without build-id.
Module libgcc_s.so.1 without build-id.
Module libstdc++.so.6 without build-id.
Module libexpat.so.1 without build-id.
Module libgnomekbdui.so.8 without build-id.
Module libpcre2-8.so.0 without build-id.
Module libffi.so.8 without build-id.
Module libselinux.so.1 without build-id.
Module libjpeg.so.62 without build-id.
Module libGL.so.1 without build-id.
Module libz.so.1 without build-id.
Module libXrender.so.1 without build-id.
Module libxcb-render.so.0 without build-id.
Module libxcb.so.1 without build-id.
Module libxcb-shm.so.0 without build-id.
Module libpng16.so.16 without build-id.
Module libEGL.so.1 without build-id.
Module libfreetype.so.6 without build-id.
Module libthai.so.0 without build-id.
Module libXinerama.so.1 without build-id.
Module libXcomposite.so.1 without build-id.
Module libXdamage.so.1 without build-id.
Module libXcursor.so.1 without build-id.
Module libxkbcommon.so.0 without build-id.
Module libXfixes.so.3 without build-id.
Module libtracker-sparql-3.0.so.0 without build-id.
Module libatk-bridge-2.0.so.0 without build-id.
Module libXi.so.6 without build-id.
Module libepoxy.so.0 without build-id.
Module libfribidi.so.0 without build-id.
Module libfontconfig.so.1 without build-id.
Module libpangoft2-1.0.so.0 without build-id.
Module libharfbuzz.so.0 without build-id.
Module libXrandr.so.2 without build-id.
Module libxkbfile.so.1 without build-id.
Module libXext.so.6 without build-id.
Module libexempi.so.8 without build-id.
Module libexif.so.12 without build-id.
Module libxapp.so.1 without build-id.
Module libX11.so.6 without build-id.
Module libatk-1.0.so.0 without build-id.
Module libpango-1.0.so.0 without build-id.
Module libpangocairo-1.0.so.0 without build-id.
Module libcinnamon-desktop.so.4 without build-id.
Module libnemo-extension.so.1 without build-id.
Module .nemo-wrapped without build-id.
Stack trace of thread 46111:
#0  0x00007f2888b468ca gtk_widget_destroy (libgtk-3.so.0 + 0x3468ca)
#1  0x000000000050639d destroy (.nemo-wrapped + 0x10639d)
#2  0x00007f28884924e8 g_closure_invoke (libgobject-2.0.so.0 + 0x174e8)
#3  0x00007f28884a5880 signal_emit_unlocked_R (libgobject-2.0.so.0 + 0x2a880)
#4  0x00007f28884ac6ba g_signal_emit_valist (libgobject-2.0.so.0 + 0x316ba)
#5  0x00007f28884ac94f g_signal_emit (libgobject-2.0.so.0 + 0x3194f)
#6  0x00007f2888b4f2b0 gtk_widget_dispose (libgtk-3.so.0 + 0x34f2b0)
#7  0x00007f28884990c9 g_object_run_dispose (libgobject-2.0.so.0 + 0x1e0c9)
#8  0x00007f2888a7d7f1 gtk_scrolled_window_destroy (libgtk-3.so.0 + 0x27d7f1)
#9  0x00007f28884924e8 g_closure_invoke (libgobject-2.0.so.0 + 0x174e8)
#10 0x00007f28884a5880 signal_emit_unlocked_R (libgobject-2.0.so.0 + 0x2a880)
#11 0x00007f28884ac6ba g_signal_emit_valist (libgobject-2.0.so.0 + 0x316ba)
#12 0x00007f28884ac94f g_signal_emit (libgobject-2.0.so.0 + 0x3194f)
#13 0x00007f2888b4f2b0 gtk_widget_dispose (libgtk-3.so.0 + 0x34f2b0)
#14 0x00007f28884990c9 g_object_run_dispose (libgobject-2.0.so.0 + 0x1e0c9)
#15 0x00000000004b75c3 nemo_window_slot_dispose (.nemo-wrapped + 0xb75c3)
#16 0x00007f2888497741 g_object_unref (libgobject-2.0.so.0 + 0x1c741)
#17 0x00007f2888922fb8 gtk_container_remove (libgtk-3.so.0 + 0x122fb8)
#18 0x00000000004b4d51 nemo_window_pane_remove_slot_unsafe (.nemo-wrapped + 0xb4d51)
#19 0x00000000004b8fbb nemo_window_close_pane (.nemo-wrapped + 0xb8fbb)
#20 0x00007f2888391158 g_list_foreach (libglib-2.0.so.0 + 0x54158)
#21 0x00000000004b87b4 nemo_window_destroy (.nemo-wrapped + 0xb87b4)
#22 0x00007f28884925af g_closure_invoke (libgobject-2.0.so.0 + 0x175af)
#23 0x00007f28884a5880 signal_emit_unlocked_R (libgobject-2.0.so.0 + 0x2a880)
#24 0x00007f28884ac6ba g_signal_emit_valist (libgobject-2.0.so.0 + 0x316ba)
#25 0x00007f28884ac94f g_signal_emit (libgobject-2.0.so.0 + 0x3194f)
#26 0x00007f2888b4f2b0 gtk_widget_dispose (libgtk-3.so.0 + 0x34f2b0)
#27 0x00007f2888b62938 gtk_window_dispose (libgtk-3.so.0 + 0x362938)
#28 0x00007f28888ca76f gtk_application_window_dispose (libgtk-3.so.0 + 0xca76f)
#29 0x00007f28884990c9 g_object_run_dispose (libgobject-2.0.so.0 + 0x1e0c9)
#30 0x00000000004b8f4c nemo_window_delete_event (.nemo-wrapped + 0xb8f4c)
#31 0x00007f288889da04 _gtk_marshal_BOOLEAN__BOXEDv (libgtk-3.so.0 + 0x9da04)
#32 0x00007f28884927d9 _g_closure_invoke_va (libgobject-2.0.so.0 + 0x177d9)
#33 0x00007f28884abc56 g_signal_emit_valist (libgobject-2.0.so.0 + 0x30c56)
#34 0x00007f28884ac94f g_signal_emit (libgobject-2.0.so.0 + 0x3194f)
#35 0x00007f2888b45674 gtk_widget_event_internal.part.0 (libgtk-3.so.0 + 0x345674)
#36 0x00007f28889fb2c3 gtk_main_do_event (libgtk-3.so.0 + 0x1fb2c3)
#37 0x00007f2889102b85 _gdk_event_emit (libgdk-3.so.0 + 0x3eb85)
#38 0x00007f2889136722 gdk_event_source_dispatch (libgdk-3.so.0 + 0x72722)
#39 0x00007f28883959db g_main_context_dispatch (libglib-2.0.so.0 + 0x589db)
#40 0x00007f2888395c88 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x58c88)
#41 0x00007f2888395d3f g_main_context_iteration (libglib-2.0.so.0 + 0x58d3f)
#42 0x00007f28885c119d g_application_run (libgio-2.0.so.0 + 0xe519d)
#43 0x0000000000433329 main (.nemo-wrapped + 0x33329)
#44 0x00007f2887c2924e __libc_start_call_main (libc.so.6 + 0x2924e)
#45 0x00007f2887c29309 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x29309)
#46 0x0000000000433375 _start (.nemo-wrapped + 0x33375)

Stack trace of thread 46114:
#0  0x00007f2887d02759 __poll (libc.so.6 + 0x102759)
#1  0x00007f2888395c26 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x58c26)
#2  0x00007f2888395f73 g_main_loop_run (libglib-2.0.so.0 + 0x58f73)
#3  0x00007f28885fc436 gdbus_shared_thread_func (libgio-2.0.so.0 + 0x120436)
#4  0x00007f28883c08cd g_thread_proxy (libglib-2.0.so.0 + 0x838cd)
#5  0x00007f2887c88e86 start_thread (libc.so.6 + 0x88e86)
#6  0x00007f2887d0fd30 __clone3 (libc.so.6 + 0x10fd30)

Stack trace of thread 46113:
#0  0x00007f2887d07d3d syscall (libc.so.6 + 0x107d3d)
#1  0x00007f28883eb0c2 g_cond_wait_until (libglib-2.0.so.0 + 0xae0c2)
#2  0x00007f2888363a91 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x26a91)
#3  0x00007f28883c130a g_thread_pool_thread_proxy (libglib-2.0.so.0 + 0x8430a)
#4  0x00007f28883c08cd g_thread_proxy (libglib-2.0.so.0 + 0x838cd)
#5  0x00007f2887c88e86 start_thread (libc.so.6 + 0x88e86)
#6  0x00007f2887d0fd30 __clone3 (libc.so.6 + 0x10fd30)

Stack trace of thread 46112:
#0  0x00007f2887d02759 __poll (libc.so.6 + 0x102759)
#1  0x00007f2888395c26 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x58c26)
#2  0x00007f2888395d3f g_main_context_iteration (libglib-2.0.so.0 + 0x58d3f)
#3  0x00007f2888395d91 glib_worker_main (libglib-2.0.so.0 + 0x58d91)
#4  0x00007f28883c08cd g_thread_proxy (libglib-2.0.so.0 + 0x838cd)
#5  0x00007f2887c88e86 start_thread (libc.so.6 + 0x88e86)
#6  0x00007f2887d0fd30 __clone3 (libc.so.6 + 0x10fd30)

Stack trace of thread 46119:
#0  0x00007f2887d07d3d syscall (libc.so.6 + 0x107d3d)
#1  0x00007f28883eb0c2 g_cond_wait_until (libglib-2.0.so.0 + 0xae0c2)
#2  0x00007f2888363a91 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x26a91)
#3  0x00007f28883c130a g_thread_pool_thread_proxy (libglib-2.0.so.0 + 0x8430a)
#4  0x00007f28883c08cd g_thread_proxy (libglib-2.0.so.0 + 0x838cd)
#5  0x00007f2887c88e86 start_thread (libc.so.6 + 0x88e86)
#6  0x00007f2887d0fd30 __clone3 (libc.so.6 + 0x10fd30)

Stack trace of thread 46121:
#0  0x00007f2887d07d3d syscall (libc.so.6 + 0x107d3d)
#1  0x00007f28883eb0c2 g_cond_wait_until (libglib-2.0.so.0 + 0xae0c2)
#2  0x00007f2888363a91 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x26a91)
#3  0x00007f28883c130a g_thread_pool_thread_proxy (libglib-2.0.so.0 + 0x8430a)
#4  0x00007f28883c08cd g_thread_proxy (libglib-2.0.so.0 + 0x838cd)
#5  0x00007f2887c88e86 start_thread (libc.so.6 + 0x88e86)
#6  0x00007f2887d0fd30 __clone3 (libc.so.6 + 0x10fd30)

Stack trace of thread 46115:
#0  0x00007f2887d02759 __poll (libc.so.6 + 0x102759)
#1  0x00007f2888395c26 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x58c26)
#2  0x00007f2888395d3f g_main_context_iteration (libglib-2.0.so.0 + 0x58d3f)
#3  0x00007f28863a346d dconf_gdbus_worker_thread (libdconfsettings.so + 0xb46d)
#4  0x00007f28883c08cd g_thread_proxy (libglib-2.0.so.0 + 0x838cd)
#5  0x00007f2887c88e86 start_thread (libc.so.6 + 0x88e86)
#6  0x00007f2887d0fd30 __clone3 (libc.so.6 + 0x10fd30)

Stack trace of thread 46120:
#0  0x00007f2887d07d3d syscall (libc.so.6 + 0x107d3d)
#1  0x00007f28883eb0c2 g_cond_wait_until (libglib-2.0.so.0 + 0xae0c2)
#2  0x00007f2888363a91 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x26a91)
#3  0x00007f28883c130a g_thread_pool_thread_proxy (libglib-2.0.so.0 + 0x8430a)
#4  0x00007f28883c08cd g_thread_proxy (libglib-2.0.so.0 + 0x838cd)
#5  0x00007f2887c88e86 start_thread (libc.so.6 + 0x88e86)
#6  0x00007f2887d0fd30 __clone3 (libc.so.6 + 0x10fd30)

Stack trace of thread 46123:
#0  0x00007f2887d07d3d syscall (libc.so.6 + 0x107d3d)
#1  0x00007f28883eb0c2 g_cond_wait_until (libglib-2.0.so.0 + 0xae0c2)
#2  0x00007f2888363a91 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x26a91)
#3  0x00007f28883c130a g_thread_pool_thread_proxy (libglib-2.0.so.0 + 0x8430a)
#4  0x00007f28883c08cd g_thread_proxy (libglib-2.0.so.0 + 0x838cd)
#5  0x00007f2887c88e86 start_thread (libc.so.6 + 0x88e86)
#6  0x00007f2887d0fd30 __clone3 (libc.so.6 + 0x10fd30)

Stack trace of thread 46122:
#0  0x00007f2887d07d3d syscall (libc.so.6 + 0x107d3d)
#1  0x00007f28883eb0c2 g_cond_wait_until (libglib-2.0.so.0 + 0xae0c2)
#2  0x00007f2888363a91 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x26a91)
#3  0x00007f28883c130a g_thread_pool_thread_proxy (libglib-2.0.so.0 + 0x8430a)
#4  0x00007f28883c08cd g_thread_proxy (libglib-2.0.so.0 + 0x838cd)
#5  0x00007f2887c88e86 start_thread (libc.so.6 + 0x88e86)
#6  0x00007f2887d0fd30 __clone3 (libc.so.6 + 0x10fd30)

Stack trace of thread 46124:
#0  0x00007f2887d07d3d syscall (libc.so.6 + 0x107d3d)
#1  0x00007f28883eb0c2 g_cond_wait_until (libglib-2.0.so.0 + 0xae0c2)
#2  0x00007f2888363a91 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x26a91)
#3  0x00007f28883c130a g_thread_pool_thread_proxy (libglib-2.0.so.0 + 0x8430a)
#4  0x00007f28883c08cd g_thread_proxy (libglib-2.0.so.0 + 0x838cd)
#5  0x00007f2887c88e86 start_thread (libc.so.6 + 0x88e86)
#6  0x00007f2887d0fd30 __clone3 (libc.so.6 + 0x10fd30)
ELF object binary architecture: AMD x86-64

Notify maintainers
@bobby285271 @mkg20001

Metadata
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.6-zen1, NixOS, 23.05 (Stoat), 23.05.20230123.1b1f506`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.12.0`
 - nixpkgs: `/nix/store/ismzj4bksv54y4x2b9spfvk9mqhbcwf8-source`

Reported from Fedora with nemo 5.6.2, also hyprland, works fine.
Maybe we need an update.

More related behavior (I'll call nemo windows in time order as nemo1 nemo2 etc):

If I launch nemo1 and nemo2 in a short interval, they won't close together when I close one.
If I launch nemo1 and wait for about 10 seconds, then launch nemo2, then close nemo1, they are possible to crash. However, closing nemo2 immediately won't, if wait for another 10 seconds, both crashes when closing nemo1 or nemo2.
If I launch nemo1, nemo2 and nemo3 in a short interval, then close nemo1, they all will crash.

Again, nemo windows share one pid. So the crash will close all windows.
This was reported by linuxmint users several years ago, but I'm afraid they can't reproduce the bug anymore. Also since other distros can't reproduce this bug, I'd rather believe it's specific to nixos, and maybe because of the wrapper.

I was not able to properly test this right now (sorry :bowing_woman:), but here are some random things you can try:

See if you can reproduce this with nautilus, thunar, also some old version of nemo, some old nixpkgs checkouts, ... If you find it previously working, a bisect point will be appreciated.

Install debug symbols and reproduce the crash, not tested but should be something like:
{ pkgs }:
{
  environment.systemPackages = with pkgs; [
    gdb
    glib
    cinnamon.nemo
  ];

  environment.enableDebugInfo = true;

  nixpkgs.overlays = [
    (final: prev: {
      cinnamon = prev.cinnamon.overrideScope' (cfinal: cprev: {
        nemo = cprev.nemo.overrideAttrs (attrs: {
          separateDebugInfo = true;
        });
      });
    })
  ];
}

Then get list of crashes with coredumpctl, run coredumpctl gdb <pid> and enter bt full.

Based on the above step, try to patch away (remove) some of the lines in nemo_window_slot_dispose according to your stack trace and try reproduce the issue, you can also e.g. try swapping the order they distroy widgets to see if it matters.

Sorry I have no idea how killactive "closes" a window, is that the only way to trigger the crash? Did you spot the crash when closing nemo normally, i.e. clicking 文件 (File) -> 关闭全部窗口 (Close All Windows) and/or 文件 (File) -> 关闭 (Close)?

I was not able to properly test this right now (sorry :bowing_woman:), but here are some random things you can try:

See if you can reproduce this with nautilus, thunar, also some old version of nemo, some old nixpkgs checkouts, ... If you find it previously working, a bisect point will be appreciated.

Install debug symbols and reproduce the crash, not tested but should be something like:
{ pkgs }:
{
  environment.systemPackages = with pkgs; [
    gdb
    glib
    cinnamon.nemo
  ];

  environment.enableDebugInfo = true;

  nixpkgs.overlays = [
    (final: prev: {
      cinnamon = prev.cinnamon.overrideScope' (cfinal: cprev: {
        nemo = cprev.nemo.overrideAttrs (attrs: {
          separateDebugInfo = true;
        });
      });
    })
  ];
}

Then get list of crashes with coredumpctl, run coredumpctl gdb <pid> and enter bt full.

Based on the above step, try to patch away (remove) some of the lines in nemo_window_slot_dispose according to your stack trace and try reproduce the issue, you can also e.g. try swapping the order they distroy widgets to see if it matters.

Sorry I have no idea how killactive "closes" a window, is that the only way to trigger the crash? Did you spot the crash when closing nemo normally, i.e. clicking 文件 (File) -> 关闭全部窗口 (Close All Windows) and/or 文件 (File) -> 关闭 (Close)?

Sorry I haven't got time to debug it, but I've tested with "close all windows" or "close" several times, they didn't crash and "close" works correctly.
Thunar don't (since it doesn't share the same pid across windows?), and nautilus refuses to open a second window when one exists.

Okay here is the coredump:
https://gist.github.com/Aleksanaa/15cb54cd422e6e6167341a76055454e4

It's because of the hyprland portal, not nix.

#1  0x000000000050639d in destroy ()
No symbol table info available.

Weird, did you trigger the crash after rebuilding nemo? :thinking:

#1  0x000000000050639d in destroy ()
No symbol table info available.

Weird, did you trigger the crash after rebuilding nemo? 🤔

Yes, by the same killactive sended by hyprland

I've included
{ pkgs, ... }:
{
  environment.systemPackages = with pkgs; [
    gdb
    glib
  ];

  environment.enableDebugInfo = true;

  nixpkgs.overlays = [
    (final: prev: {
      cinnamon = prev.cinnamon.overrideScope' (cfinal: cprev: {
        nemo = cprev.nemo.overrideAttrs (attrs: {
          separateDebugInfo = true;
        });
      });
    })
  ];
}

in my nixos configuration, and installed cinnamon.nemo-with-extensions with home manager (home manager as a module of nixos).

Can you try adding cinnamon.nemo to environment.systemPackages instead?

Can you try adding cinnamon.nemo to environment.systemPackages (reason) instead?

Okay it seem to work, and now I get this:
#0  0x00007f90f374613a in gtk_widget_destroy () from /nix/store/kv7ih63pn9hn8p00wwi1mvg400ahsrc2-gtk+3-3.24.36/lib/libgtk-3.so.0
[Current thread is 1 (Thread 0x7f90f1809a80 (LWP 303638))]
(gdb) bt full
#0  0x00007f90f374613a in gtk_widget_destroy () from /nix/store/kv7ih63pn9hn8p00wwi1mvg400ahsrc2-gtk+3-3.24.36/lib/libgtk-3.so.0
No symbol table info available.
#1  0x000000000050639d in destroy (object=0x1a12150) at ../libnemo-private/nemo-icon-container.c:2741
        container = 0x1a12150
#2  0x00007f90f2f594e8 in g_closure_invoke (closure=closure@entry=0x12c1710, return_value=return_value@entry=0x0, n_param_values=1, param_values=param_values@entry=0x7ffd397d3510,
    invocation_hint=invocation_hint@entry=0x7ffd397d3490) at ../gobject/gclosure.c:832
        marshal = 0x7f90f2f57d70 <g_type_class_meta_marshal>
        marshal_data = 0x98
        in_marshal = 1
        real_closure = 0x12c16f0
        __func__ = "g_closure_invoke"

Can you try adding cinnamon.nemo to environment.systemPackages (reason) instead?

https://github.com/linuxmint/nemo/blob/4ee50c85760f6b7c2566310510597e02484f9731/libnemo-private/nemo-icon-container.c#L2741 Pretty fun though, it happens even without triggering the 'search window'. I just open and close the nemo, and do nothing else.

Can you try adding cinnamon.nemo to environment.systemPackages (reason) instead?

Make sense to me! If I hit the search button to trigger the search widget, then close it, it won't crash (tested 10 times). So the problem is trying to destroy a widget that isn't exist.

diff --git a/libnemo-private/nemo-icon-container.c b/libnemo-private/nemo-icon-container.c
index 5ea40e6..bf5dd6e 100644
--- a/libnemo-private/nemo-icon-container.c
+++ b/libnemo-private/nemo-icon-container.c
@@ -2738,7 +2738,7 @@ destroy (GtkWidget *object)

 	/* destroy interactive search dialog */
 	if (container->details->search_window) {
-		gtk_widget_destroy (container->details->search_window);
+		//gtk_widget_destroy (container->details->search_window);
 		container->details->search_window = NULL;
 		container->details->search_entry = NULL;
 	}

Unsure of memory leaks, but anyway it works. This seems like a upstream bug and caused by gtk or glib version compatibility. Will close it for now.

Hmmm, please consider reporting this to linuxmint. I checked nautilus and they removed these code after their search rewrite/redesign so we are on our own.
I actually wonder whether a GTK_IS_WIDGET check is needed
-		gtk_widget_destroy (container->details->search_window);
+		if (GTK_IS_WIDGET (container->details->search_window))
+			gtk_widget_destroy (container->details->search_window);

But it is unclear to me why the null check is not enough :upside_down_face: Something messed up before the destroy?

Hmmm, please consider reporting this to linuxmint. I checked nautilus and they removed these code after their search rewrite/redesign so we are on our own.
I actually wonder whether a GTK_IS_WIDGET check is needed
-		gtk_widget_destroy (container->details->search_window);
+		if (GTK_IS_WIDGET (container->details->search_window))
+			gtk_widget_destroy (container->details->search_window);

But it is unclear to me why the null check is not enough upside_down_face

Tested, this is not enough however.

Did this ever get fixed? I seem to be having this same issue still with cinnamon.nemo-with-extensions  version 6.0.2
Core was generated by `/home/shaun/.nix-profile/bin/nemo'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fb43cd53649 in gtk_widget_destroy ()
   from /nix/store/wky1jsp6g0vdn7i81g1s5yvha6fnadpr-gtk+3-3.24.42/lib/libgtk-3.so.0
[Current thread is 1 (Thread 0x7fb43a8c8ac0 (LWP 14288))]
(gdb) bt full
#0  0x00007fb43cd53649 in gtk_widget_destroy ()
   from /nix/store/wky1jsp6g0vdn7i81g1s5yvha6fnadpr-gtk+3-3.24.42/lib/libgtk-3.so.0
No symbol table info available.
#1  0x00000000004f3882 in destroy ()
No symbol table info available.
#2  0x00007fb43c5435d1 in g_closure_invoke ()
   from /nix/store/yl0m9g65iv1wa6lrbbk959ag2ahw355b-glib-2.80.2/lib/libgobject-2.0.so.0

nix-shell -p nix-info --run "nix-info -m"

 - system: `"x86_64-linux"`
 - host os: `Linux 6.6.36, NixOS, 24.05 (Uakari), 24.05.20240629.d95551a`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.22.2`
 - channels(root): `""`
 - nixpkgs: `/nix/store/7n3grjjwy0xk28c27gqi409wckbsy2d6-source`

I totally forgot that. I'm using my patches for more than one year.
diff --git a/libnemo-private/nemo-icon-container.c b/libnemo-private/nemo-icon-container.c
index 5ea40e6..bf5dd6e 100644
--- a/libnemo-private/nemo-icon-container.c
+++ b/libnemo-private/nemo-icon-container.c
@@ -2738,7 +2738,7 @@ destroy (GtkWidget *object)

 	/* destroy interactive search dialog */
 	if (container->details->search_window) {
-		gtk_widget_destroy (container->details->search_window);
+		//gtk_widget_destroy (container->details->search_window);
 		container->details->search_window = NULL;
 		container->details->search_entry = NULL;
 	}

This is also useful for nemo --existing-window
diff --git a/src/nemo-main-application.c b/src/nemo-main-application.c
index 3a61cdd..94e34d2 100644
--- a/src/nemo-main-application.c
+++ b/src/nemo-main-application.c
@@ -445,8 +445,7 @@ open_tabs_in_existing_window (NemoMainApplication *application,

             /* Don't use `gtk_window_present()`, as the window manager will ignore this window's focus request and try
              * to just mark it urgent instead (flashing in the window list for example). */
-            gtk_window_present_with_time (GTK_WINDOW (window),
-                                          gdk_x11_get_server_time (gtk_widget_get_window (GTK_WIDGET (window))));
+            gtk_window_present (GTK_WINDOW (window));

           break;
         }

Would be better to report it upstream, though.

I totally forgot that. I'm using my patches for more than one year.
diff --git a/libnemo-private/nemo-icon-container.c b/libnemo-private/nemo-icon-container.c
index 5ea40e6..bf5dd6e 100644
--- a/libnemo-private/nemo-icon-container.c
+++ b/libnemo-private/nemo-icon-container.c
@@ -2738,7 +2738,7 @@ destroy (GtkWidget *object)

 	/* destroy interactive search dialog */
 	if (container->details->search_window) {
-		gtk_widget_destroy (container->details->search_window);
+		//gtk_widget_destroy (container->details->search_window);
 		container->details->search_window = NULL;
 		container->details->search_entry = NULL;
 	}

Thanks for the info. This does in fact fix it. It's worth noting for anyone who might travel this path in the future - the patch has to be applied to cinnamon.nemo, even if using cinnamon.nemo-with-extensions.
Totally didn't spend 45 minutes trying to figure out why it wasn't working just to figure that out

Please try the above fix.

seems to work?


mautrix-telegram: 0.12.0 -> 0.12.1

Description of changes
contains https://github.com/NixOS/nixpkgs/pull/191743

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

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

5 packages built:

mautrix-facebook
mautrix-signal
mautrix-telegram
python310Packages.mautrix
python39Packages.mautrix


Ternary dereference issue

Code: if(!(container ? container : src).Adjacent(user))
Error: Error at code\modules\hydroponics\seeds.dm:343:16: Invalid property "Adjacent"

Probably related to https://github.com/wixoaGit/OpenDream/issues/524


Do we have example docker file for MFT install and agent creation

Hi @P9110963,
While MFT is supported to run in a container we do not have any samples or examples to show how to do this. I will leave this issue open as an indication that this is something you would like.


fix failing integration tests

fixing embankment and turbine tests
Only marking non-draft in order to trigger TeamCity to run the tests.

I'll merge these changes and fix the turbinecontrollerit in a subsequent PR


slash menu show more options with only 4 queries visible

https://www.notion.so/slash-menu-show-more-options-with-only-4-queries-visible-47aa2269ce114c6093d54a3fa8a1315e

Duplicate for https://github.com/appsmithorg/appsmith/issues/32896


Standardize formatting of manifests/p/pyfa/pyfa/2.61.1

Microsoft Reviewers: Open in CodeFlow

@wingetbot run


Unable to select achievement to claim

NOTE: Before you begin working on this, please assign this issue to yourself. If you do not do this, then there's the possibility that 2 people will end up doing the same task, which is not a good use of time.
While testing Complex Numbers, I discovered it wasn't possible for me to select an achievement to claim. Not sure if this is a backend bug or a frontend bug. Also not sure if this is just a bug in my Complex Numbers implementation or if this affects other cards too. This requires more investigation.

This used to work.  Some other cards let you do this.

Yes, I remember this working for other cards too!

Just confirmed that the achievement card is being selected in the database.

Fixed it!


checksId prop in EntityTechInsightsScorecardCard not working

Expected Behavior
When checksId is passed to EntityTechInsightsScorecardCard, should only list the check in the list
<EntityTechInsightsScorecardCard
title="Scorecard 1"
description="This is a sample scorecard no. 1"
checksId={['titleCheck']}
Actual Behavior
The component page still lists all checks.
Steps to Reproduce

Step 1
Step 2
...

Context

Your Environment

Browser Information:

Output of yarn backstage-cli info:

@Xantier @Irma12  maybe you could have a look at this?

I note that the component doesn't react to changes in the check ids list. Maybe the useAsync should depend on [api, entity, JSON.stringify(checksId)] or something, so that it'll properly react to updates there? Not sure if that's what is affecting things here though.

Made this one to at least get the reloading behavior in place.

Hey @freben I took a look and I think problem is in TechInsightsClient.ts component. I think the error source is not defining the specific header type when POST request is made. I will create a PR in order to make it work, I think it should resolve the issue.

I think this should do the trick :)

Fine to close this? Seems like it's fixed by #14135

Closing as fixed.


Option to tap instead of swipe

I got i bigger phone and it seems my thumb is to short to swipe the cards properly when holding it.
It would be nice to just tap the edges of the card to answer yes/no.

This was also mentioned loong ago here https://github.com/oguzgelal/juken/issues/18


Error when provisioning machine from zip file (pkg_resources.VersionConflict: (setuptools 2.2 (/home/vagrant/py27/lib/python2.7/site-packages), Requirement.parse('setuptools>=8.0')))

Just by provisioning the machine from the zip in the official docs this error occurs:
==> default: Notice: /Stage[main]/Plone/Exec[/home/vagrant/py27/bin/python bootstrap.py]/returns: Traceback (most recent call last):
==> default: Notice: /Stage[main]/Plone/Exec[/home/vagrant/py27/bin/python bootstrap.py]/returns:   File "bootstrap.py", line 159, in <module>
==> default: Notice: /Stage[main]/Plone/Exec[/home/vagrant/py27/bin/python bootstrap.py]/returns:     ws.require(requirement)
==> default: Notice: /Stage[main]/Plone/Exec[/home/vagrant/py27/bin/python bootstrap.py]/returns:   File "/home/vagrant/py27/local/lib/python2.7/site-packages/pkg_resources.py", line 685, in require
==> default: Notice: /Stage[main]/Plone/Exec[/home/vagrant/py27/bin/python bootstrap.py]/returns:     needed = self.resolve(parse_requirements(requirements))
==> default: Notice: /Stage[main]/Plone/Exec[/home/vagrant/py27/bin/python bootstrap.py]/returns:   File "/home/vagrant/py27/local/lib/python2.7/site-packages/pkg_resources.py", line 592, in resolve
==> default: Notice: /Stage[main]/Plone/Exec[/home/vagrant/py27/bin/python bootstrap.py]/returns:     raise VersionConflict(dist,req) # XXX put more info here
==> default: Notice: /Stage[main]/Plone/Exec[/home/vagrant/py27/bin/python bootstrap.py]/returns: pkg_resources.VersionConflict: (setuptools 2.2 (/home/vagrant/py27/lib/python2.7/site-packages), Requirement.parse('setuptools>=8.0'))
==> default: Notice: /Stage[main]/Plone/Exec[/vagrant/buildout/bin/buildout]: Dependency Exec[/home/vagrant/py27/bin/python bootstrap.py] has failures: true
==> default: Error: /home/vagrant/py27/bin/python bootstrap.py returned 1 instead of one of [0]
==> default: Error: /Stage[main]/Plone/Exec[/home/vagrant/py27/bin/python bootstrap.py]/returns: change from notrun to 0 failed: /home/vagrant/py27/bin/python bootstrap.py returned 1 instead of one of [0]
==> default: Warning: /Stage[main]/Plone/Exec[/vagrant/buildout/bin/buildout]: Skipping because of failed dependencies
==> default: Notice: Finished catalog run in 9.66 seconds
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

puppet apply --manifestdir /tmp/vagrant-puppet-9/manifests --detailed-exitcodes /tmp/vagrant-puppet-9/manifests/plone.pp

Stdout from the command:

Notice: Compiled catalog for training.plone.org in environment production in 0.06 seconds
Notice: /Stage[main]/Plone/Exec[/home/vagrant/py27/bin/python bootstrap.py]/returns: Traceback (most recent call last):
Notice: /Stage[main]/Plone/Exec[/home/vagrant/py27/bin/python bootstrap.py]/returns:   File "bootstrap.py", line 159, in <module>
Notice: /Stage[main]/Plone/Exec[/home/vagrant/py27/bin/python bootstrap.py]/returns:     ws.require(requirement)
Notice: /Stage[main]/Plone/Exec[/home/vagrant/py27/bin/python bootstrap.py]/returns:   File "/home/vagrant/py27/local/lib/python2.7/site-packages/pkg_resources.py", line 685, in require
Notice: /Stage[main]/Plone/Exec[/home/vagrant/py27/bin/python bootstrap.py]/returns:     needed = self.resolve(parse_requirements(requirements))
Notice: /Stage[main]/Plone/Exec[/home/vagrant/py27/bin/python bootstrap.py]/returns:   File "/home/vagrant/py27/local/lib/python2.7/site-packages/pkg_resources.py", line 592, in resolve
Notice: /Stage[main]/Plone/Exec[/home/vagrant/py27/bin/python bootstrap.py]/returns:     raise VersionConflict(dist,req) # XXX put more info here
Notice: /Stage[main]/Plone/Exec[/home/vagrant/py27/bin/python bootstrap.py]/returns: pkg_resources.VersionConflict: (setuptools 2.2 (/home/vagrant/py27/lib/python2.7/site-packages), Requirement.parse('setuptools>=8.0'))
Notice: /Stage[main]/Plone/Exec[/vagrant/buildout/bin/buildout]: Dependency Exec[/home/vagrant/py27/bin/python bootstrap.py] has failures: true
Notice: Finished catalog run in 9.66 seconds

Stderr from the command:

stdin: is not a tty
Error: /home/vagrant/py27/bin/python bootstrap.py returned 1 instead of one of [0]
Error: /Stage[main]/Plone/Exec[/home/vagrant/py27/bin/python bootstrap.py]/returns: change from notrun to 0 failed: /home/vagrant/py27/bin/python bootstrap.py returned 1 instead of one of [0]
Warning: /Stage[main]/Plone/Exec[/vagrant/buildout/bin/buildout]: Skipping because of failed dependencies

I can avoid this problem by:

Removing the created virtualenv;
Editing the plone.pp manifest adding --no-setuptools when creating the virtualenv.

Since the --no-setuptools argument is from virtualenv 1.9 and in Ubuntu 14 (used in Vagrant) version is 1.11, I think it's a nice solution.
I didn't test upgrading the bootstrap.py used in https://github.com/collective/training_buildout.git but I think it should be upgraded as well: we should pin the setuptools version when calling bootstrap.py to avoid this problem in the future.

Hi,
did you try the plone5 branch? There we avoid vagrant alltogether, iirc

It works, but I need the 4.3.x branch. Since the plone5 branch asks for setuptools 12 it doesn't conflict with zc.buildout 8.0 requirement.
Are you planning to completely avoid Vagrant in plone5 branch, or just going to be an "advanced" topic?

I remembered it incorrectly. We had no windows laptops in our training.

I've updated the repo to add your proposed fix. Can you try it again?

I made a mistake, I should have been clearer in my bug report.
Using the --no-setuptools option doesn't install pip.
I was using the zip file in instructions and since it's manifests/plone.pp doesn't use pip, the --no-setuptools fix makes sense.
...but in the repo master you do use pip to upgrade setuptools, so just adding --no-setuptools in your commit breaks the provisioning again. pip usage was added in commit https://github.com/plone/training/blob/fa3c8db46954018512d3008220db9b582cc68bf5/plone_training_config/manifests/plone.pp.
Running vagrant up gives a new error:
ContextualVersionConflict: (setuptools 6.1 (/home/vagrant/buildout-cache/eggs/setuptools-6.1-py2.7.egg), Requirement.parse('setuptools>=8.0'), set(['zc.buildout']))

The correct thing here is:

Change 6.1 to a higher setuptools version (I suggest to use the same in plone5 branch, 12.2);
Update the zip file used in https://plone-training.readthedocs.org/en/latest/plone_training_config/instructions.html.

Sorry about the hassle. I think you may git commit --amend to remove the --no-setuptools and just change the version 6.1 to 12.2.
PS: There is a new Unified Installer for 4.3.4 as well.

@do3cc we can't change the code ourselves by pull requests since we can't sign the contributor's agreement. Can you check the last comment? Thanks in advance!

@idgserpro Sorry, this got lost, I take care of it.

btw, since there is no email, who are you? Are there really plone devs in BH? I pass by there regulary

This is a corporate account for Serpro - Serviço Federal de Processamento de Dados, an IT Brazilian Government company. All Zope/Python/Plone related activities in github are handled using this account. We're already contributing to some packages following an internal norm that guides how the contributions should be done (but not Plone core yet).
Yes, there are some Plone devs in BH. We'll try to get in touch by other accounts, but we can't guarantee to pass by München regularly. :)
BTW, this issue can be closed, the fix worked!

Cool. Lets see. In january we will pass by on our trip to Montes Claros.
Regarding the Contributor Agreement, I think we can ignore this:
https://github.com/plone/training/issues/62

Don't forget to change https://plone-training.readthedocs.org/en/latest/about.html#license to reflect this formal change to avoid confusion.
So, will the License be only a line long?
The Mastering Plone Training is licensed under a Creative Commons Attribution 4.0 International License.


Fix Error type

There was a typo in Error, unless I'm really missing something :)

I'll close this since it's fix in the refactor


Release 0.12

First I would like us to finish all of the AST changes that we know about, even if the parsing/printing isn't perfect for all of them.
cc @Arnavion - you're doing great so far! Thanks for all your help.

This is up in the air as Alex is helping rewrite syn to operate on token trees instead of strings: https://github.com/rust-lang/rust/pull/40939.

Next blocker for this is updating serde

Let's publish what we have under a different name for now. That way:

the early adopters can use the new TokenStream without dealing with git dependencies,
we can figure out the right idioms in Serde and futures-await and refer people to those when we eventually do 0.12,
the large contingent happily using Macros 1.1 is not disrupted while we iterate on this.

Something like syn-unstable or syn-next.

You could also use *-pre versions instead of different crate names

Oh to be clear I'm in no particular rush to release these crates, just figured it'd be good to know what's blocking it. I wouldn't mind using git for awhile.

I'm not sure whether or not we would want to start publishing it. I am currently inclined to publish it as 1.12.0-pre-1, assuming that cargo will never automatically select that version (I'm not sure what the state of cargo's support for pre-release versions is - I was reading https://github.com/rust-lang/cargo/issues/2222 but couldn't determine what the current behavior is from it).
I would say that currently the API isn't stable, and is less ergonomic to use than syn 0.11, which makes me not want to replace syn 0.11 until we can make sure that the API is actually stable and usable, so I definitely don't think we want to publish it as 0.12.
If the only advantage then of 0.12 was that on nightly it could interact with the native proc_macro API, I would not bother publishing it, especially because due to https://github.com/rust-lang/rust/issues/43081 it doesn't even give you better span information.
However, 0.12 also contains my fixes from #168 which means that it can correctly parse expressions now. This can be useful in some macros even today (e.g. https://github.com/mystor/unsauron - which is a silly macro I made, but represents a class of macros which are now possible with syn 0.12, but weren't possible with syn 0.11), It would be nice to be able to publish unsauron and future macros like it on crates.io, which requires that we publish 0.12 in some form.
That's why I feel we should publish it as a preview version, so that people don't start using it without knowing the trade-offs, but we don't make it impossible to publish crates which use it to crates.io.

I am not a fan of pre-release versions.
I think it can work well for "release candidate" or similar almost-complete versions. The deciding factor is whether time invested in upgrading a crate to use the release candidate is 100% applicable toward upgrading a crate to use the upcoming real release. Upgrading from 0.(x-1) to 0.x-rc1 to 0.x-rc2 to 0.x.0 should be the same amount of work as upgrading directly from 0.(x-1) to 0.x.0.
In my experience pre-release versions are no good for effectively "development snapshot" versions, which is the state syn would be in. We saw this with bincode releasing 1.0.0-alpha1 through 1.0.0-alpha7 over the course of several months. A sizeable fraction of people will pick those up and be frustrated with a treadmill of breaking changes over and over to the same code, even though they brought it upon themselves. And Cargo makes it even worse by upgrading across different pre-release versions even though there is no expectation that they are compatible (https://github.com/rust-lang/cargo/issues/2222).
I would like to either publish a release under a different name like syn-next or make git dependencies work better (https://github.com/rust-lang/cargo/issues/4247).

I personally hope to avoid extra crates/prerelease if possible, and I think the only real blocker for git deps is the huge submodule, so I opened https://github.com/dtolnay/syn/pull/183 to paper over that issue

+1 for just using Git and improving that experience if necessary.
Would it make sense to create a milestone for 0.12? I think it'd be helpful to get a better picture of what needs to be done for it. I'm in my usual state of not wanting to build a bunch of stuff on 0.11, knowing that an 0.12 with breaking changes is coming. I'd prefer to base my work on the latest stuff so I can give feedback on my experience, too! Right now the worst part about proc macros is the span information pointing to the invocation of the macro which is entirely useless to me. Sounds like that is more an issue with the proc macro feature than syn, though.

That problem isn't going to be fixed by 0.12 on stable, but might be fixable with 0.12 on nightly (due to the proc-macro2 shim).
I don't think there's a well-defined set of blockers right now, rather there's a general feeling that the new API is inferior to the current one, especially because of the need to specify every token when performing AST transformations. A milestone and a set of things which need to change might be good for driving us toward the release though.

I cleared some time over the next few weeks to do API design work and figure out a roadmap for 0.12.

Awesome!
I think the biggest hurdle in my experience for working with syn 0.12 is the tokens stuff that we were talking about at Rust Belt Rust, so hopefully we can come up with a good solution for that.

@mystor I assigned most of the open syntax issues to you. Feel free to decide which ones need to be in 0.12. Some of them may not require changes in the AST so those can wait. Later this month I will try to get through the ones that haven't been done by then. 😜

Tentatively scheduling this for next week Thursday or Friday, with mostly documentation work remaining. @mystor what is the chance you could get https://github.com/alexcrichton/proc-macro2/pull/36 across the finish line by then so we can put together some compelling demos involving Span?

I haven't really been working on it much. I don't think it'll be very hard if what we decide to do is simply have a build-time environment variable which controls access to the span APIs. I worry about the ergonomics of that, although it might be OK.
I've been considering more dramatic changes to the way syn and the token provider interact which would allow us to make the parser decoupled from the token provider and span format without hurting build times, which could be nice to have for things like build scripts, but I think that's outside the scope of syn 0.12 for sure.


Input image size of test_jpeg_yolov3

./test_jpeg_yolov3
the input picture size is ??

The input image of test_jpeg_yolov3 can be of any size, but the network input is fixed, and the inconsistency of the input size and the network input may affect the detection effect.

Take yolov3_voc as an example. Its network input is 416x416. If you enter a picture of any size, it will be resized to 416x416. After the detection frame is obtained, it will be zoomed back to the position corresponding to the original picture.

The input image of test_jpeg_yolov3 can be of any size, but the network input is fixed, and the inconsistency of the input size and the network input may affect the detection effect. Take yolov3_voc as an example. Its network input is 416x416. If you enter a picture of any size, it will be resized to 416x416. After the detection frame is obtained, it will be zoomed back to the position corresponding to the original picture.

if I set the input size  to 608608 in cfg file, then generate the elf file.
Is the input of the network is 608608?

yes, you can change input size to 608x608 in cfg file

Hi @LinErDeng
Since we haven't received your reply for a long time, we assume you have solved this issue and I'm going to close it. If you still have any questions, please feel free to reopen it. Thank you very much.


polk state college lakeland florida

thank you

@Satismadeit I have to close this request without merging, because you requested to add a non-existent domain to this repository: Host my.polk not found: 3(NXDOMAIN) Please ensure that you are familiar with this repository rules located at the bottom of this page and submit a new request with the correct information. Thank you for your understanding!


Diversity Access Tickets - add resources

Add resources at the bottom of the page in Known Implementations
Resources section

https://internetfreedomfestival.org/internet-freedom-festival-diversity-inclusion-fund/

@ivamarr thank you for your suggestion. This has been added to our Diversity Access Tickets metric.


Feature request: Introduce TypeScript Assertion function

Feature Request
Any plan to introduce function using TypeScript assertion feature?
For example:
export declare function assert2<T>(input: unknown): asserts input is T;

Previously, the value of the asserted type had to be assigned to a new variable.
const typedValue = assert<Type>(value);

But with this function, a new variable is no longer needed.
assert2<Type>(value);
// now value is typed

I hope this introduced! Thank you.

It may hard to introduce in formal ts guidebook

@samchon Sorry, can you explain why would this be hard to introduce? It would greatly add to the already amazing library.

Well, it is hard to explain why.
Of course, it would be honor if TypeScript team adapts typia in documents, but this is a 3rd party library.
Also, the handbook is not introducing any type of 3rd party library.

@samchon I am sorry if my poor English caused your misunderstanding. I'm not talking about any handbook. I would like to see Assertion Function introduced in typia, like:
typia.assert2<Type>(value);

Ah, you mean combinig both is<T>() and assert<T>() function.

@samchon How about guard() or assertGuard()?
export declare function guard<T>(input: unknown): asserts input is T;

function example(input: unknown) {
   guard<string>(input);
   input.toLowerCase(); // input is string here.
}

IMO assert<T>(input: unknown): T is almost never more handy than assert<T>(input: unknown): asserts input is T, so it's ideal to change the assert method to use the asserts syntax in the next major update. However, if backward compatibility is a priority, choosing another name(guard) would also be a good idea.

What about chaning typia.assert<T>() function like that?
export function assert<T>(input: unknown): asserts input is T & T;

https://github.com/microsoft/TypeScript/issues/56256
export function assertString(input: unknown): asserts input is string & string {
    if (typeof input !== 'string')
        throw new Error('Input is not a string');
    return input;
}

I've tried above way, but it is not working.
If TypeScript team does not have any plan to support above statement, I'll change the return type of assert and assertEquals function to be asserts input is T, and will do a major update following your advise. I think this is the right way. Thanks for long term waiting and good suggestion.

asserts input is string is void type.
input is string is boolean type.
so asserts input is string & string can't work!

Those functions would be newly added at tomorrow

assertGurad
assertGuardEquals
createAssertGuard
createAssertGuardEquals

Tested the type assertion to the createAssert() function, it has critical problem like below.
I'll ask this is bug or spec to the Microsoft repo.
If it is spec, then no way to support this issue's suggestion \o/

Thank you for investigation!!
Hmm, I understand the problem. Indeed, if this is a TypeScript spec, it would not be possible to implement createAssert.
But if it is, is it possible to introduce the feature as a function has other name(like assertGuard)? In that case, although createAssertGuard can't be implemented now, user would be able to choose favorite strategy, and we could implement it after TypeScript have supported such higher-order function with asserts clause.
asserts function seems minor feature, but I think that it is an important feature that would really make typia more handy. Since we cannot wrap the existing assert function to include this feature, we hope that it will be implemented in some form in the core of typia.
(This is just a thought, is it difficult commonalize the implementation of all assert<T>() for same T automatically? Instead of inlining the whole implementation at the place, put the implementation into typia module(by transforming typia code itself), and call it from the usage place)

Install the next version, then you can use the assertGuard() function earlier.
npm install typia@next

Biggest Thanks!!!
I love typia so much


Deparse DROP SCHEMA

And I'm pretty sure we're missing all kind of types here, the code should be refactored

This one suffers from the same problem with double arrays as #114

Merged - thanks for the contribution!
I've left the double array handling as is for now, I think thats okay unless we learn its not :)


With the Python client, receiver_queue_size=0 results in an InvalidConfiguration error, but is documented to work

Describe the bug
Passing receiver_queue_size=0 to the Python client's subscribe method results in a InvalidConfiguration exception.
However, these docs indicate that a receiver queue size of 0 is supported.
To Reproduce

With a connected Python client, call subscribe on any topic with the receiver_queue_size kwarg set to 0.
Observe that an InvalidConfiguration error is raised.

Expected behavior
A value of 0 should either be supported and documented (is 0 equivalent to 1?), or these docs should be updated to reflect that the python client (if not others) do not support values less than 1.
Environment
Same as https://github.com/apache/pulsar/issues/15701

@zbentley It should be a feature catch-up, the Java client supported zero queue consumer but looks like the Python client does not support it. We will add zero queue consumer support for the Python client in 2.11.0.

I think zero queue size consumer has already been supported from a very early version. I've also fixed a related bug last year, see https://github.com/apache/pulsar/pull/10506.

It's better to show your Python client version and paste your code.

is 0 equivalent to 1?

No.

@BewareMyPower Do we have a test for the zero queue consumer of the Python client? If we have a test, please share the test in this issue.

@BewareMyPower

It's better to show your Python client version and paste your code.

See https://github.com/apache/pulsar/issues/15701; that contains Python/client/etc. version.
The code I'm using is:
from pulsar import Client
import os

TOPIC = 'persistent://chariot1/chariot_ns_sre--heartbeat/chariot_topic_heartbeat'
SUBSCRIPTION = 'chariot_subscription-heartbeat-heartbeat'

def main():
    client = Client(service_url='pulsar://localhost:6650')
    client.subscribe(
        topic=TOPIC,
        subscription_name=SUBSCRIPTION,
        receiver_queue_size=0,
        consumer_name=f'testconsumer-{os.getpid()}'
    )

if __name__ == '__main__':
    main()

Could you clarify the difference between a setting of 0 and a setting of 1?

@codelipenghui See https://github.com/apache/pulsar/blob/defeec0e84a63ea865f3a2790bc61b66a02254c5/pulsar-client-cpp/python/pulsar_test.py#L289-L306
This test was introduced in https://github.com/apache/pulsar/pull/5706 that was included since Pulsar 2.5.0. It fixes https://github.com/apache/pulsar/issues/5634.

@zbentley The common behavior between 0 and 1 receiver queue size is that the permits of FLOW request is 1.
However, if the receiver queue size is 0, only when receive is called will the consumer send the FLOW request to broker, which means the consumer won't prefetch the messages.
If the receiver queue size is 1, the consumer will send a FLOW request to broker immediately after the consumer is created successfully, which means the consumer will prefetch 1 message. It could affect the logic of the dispatcher in broker.

@BewareMyPower thanks, can that be added to the client documentation for receiver-queue related flags?

Update (and updated issue title): this only happens with partitioned topics. While I'm not quite sure what receiver queue size does on partitioned topics, I'm pretty sure it shouldn't start throwing errors for configurations that are valid for non-partitioned topics.

It looks like zero queue consumer cannot be used on a partitioned topic. I tested the Java code as well.
        var topic = "my-topic";
        var admin = PulsarAdmin.builder().serviceHttpUrl("http://localhost:8080").build();
        try {
            admin.topics().createPartitionedTopic(topic, 1);
        } catch (PulsarAdminException ignored) {
        }
        var client = PulsarClient.builder().serviceUrl("pulsar://localhost:6650").build();
        var consumer = client.newConsumer()
                .topic(topic)
                .subscriptionName("sub-xxx")
                .receiverQueueSize(0)
                .subscribe();

The error message is more friendly and clear:

IllegalArgumentException: Receiver queue size needs to be greater than 0 for Topics Consumer

I think it's a common problem for clients of all languages. This check was introduced in https://github.com/apache/pulsar/pull/1103.
    MultiTopicsConsumerImpl(/* ... */) {
        super(client, singleTopic, conf, Math.max(2, conf.getReceiverQueueSize()), executorProvider, subscribeFuture,
                schema, interceptors);

        checkArgument(conf.getReceiverQueueSize() > 0,
            "Receiver queue size needs to be greater than 0 for Topics Consumer");

IMO, it's a bug. It looks like the multi topics consumer requires the receiver queue size is at least 2. (from the Math.max(2, conf.getReceiverQueueSize()) call). I guess in the early time of Pulsar, the number of partitions must be at least 2, so we have this check.
But the zero queue consumer should be an exceptional case. We should fix both Java and C++ clients for this config. @codelipenghui

@zbentley @BewareMyPower

It’s not enabled because we cannot know which partition the next message will be coming from. Any suggestion on how to achieve that?

from https://github.com/apache/pulsar/issues/7280#issuecomment-644238363
This is the main challenge to supporting zero queue consumers for a partitioned topic.
One option here is to create a function to merge messages  from multiple topics/partitions to a non-partitioned topic,
the zero consumer only consumes the messages from the merged topic.

Got it. For zero queue consumer, there is no way to determine which internal consumer (on a specific partition) should be chosen to call receive.

While I don't know much about this area of the code, that sounds fine to me.
Other solutions that may make sense:

Document that a zero queue size with a partitioned topic would potentially buffer up to N messages (where N is the number of partitions on the topic).
Sequentially loop over the internal receive calls for each partition, returning when a message is found on any. The interactions with the timeout and missed deliveries might be undesirable here though.