[BUG] Undocumented changes in migration behavior since v1.4.x

Describe the bug
Many of the manual test cases from https://longhorn.github.io/longhorn-tests/manual/pre-release/ha/ha-volume-migration/ no longer pass or have changed behavior on master-head (in the leadup to v1.7.0). The primary reason for the behavioral change seems to be the introduction of the volume attachment controller in v1.5.0.
To Reproduce
Try to run the test cases on master-head. Currently observed behaviors:

#
Scenario
Migration Confirmation
Migration Rollback

3
Old engine crash
When the volume becomes faulted, it is detached. It can never be reattached, so the migration gets stuck. Nothing rejects the confirmation request. When it is done, the volume has migrationNodeID == new and currentMigrationNodeID == new, but nodeID == "". migrationNodeID must be manually removed for the volume to be usable again.
Works as originally described.

7
New engine node down
Nothing rejects the request. Usually, the migration finishes without issue.
Works as originally described.

8
Old engine node down
When the volume becomes faulted, it is detached. It can never be reattached, so the migration gets stuck. Nothing rejects the confirmation request. When it is done, the volume has migrationNodeID == new and currentMigrationNodeID == new, but nodeID == "". migrationNodeID must be manually removed for the volume to be usable again.
Works as originally described. Being improved in https://github.com/longhorn/longhorn-manager/pull/2843.

There are almost certainly other changes (no request can be rejected, as was originally documented), but I am focusing on these for now.
Additional context
Handled in conjunction with and as a followup to https://github.com/longhorn/longhorn/issues/3401.

A key challenge is that the volume attachment/detachment API used to directly accept or reject attachment and detachment requests. Now, it only creates or deletes attachment tickets, which the volume attachment controller handles asynchronously.

The attachment/detachment API may return success, even if there is no way for the volume attachment controller to proceed intelligently with the remaining attachment tickets.
Once there are two attachment tickets for a volume, the volume attachment controller doesn't have a particularly good way to distinguish between them. For example, if the volume is detached for salvage, it must be reattached. Currently, the volume attachment controller will not reattach it at all. However, if we want it to, it must decide which attachment ticket refers to the "from" node and which refers to the "to" node.

Brainstormed with @PhanLe1010 this afternoon. So far, we came up with three ideas:

If old engine dies, set remount requested to trigger workload pod deletion and completely cancel migration / detach volume. Don't process a new attachment until the workload deletion has successfully resulted in the clearing of all CSI attachment tickets. This allows us to start fresh. It's somewhat controversial (since it's a pretty big behavioral change), but when the old engine dies before confirmation, the volume definitely crashes, so the old workload pods are not useful anyway.
Limit each volume to a maximum of two attachments with the webhook (so there are not a bunch to choose from when the workload pod dies). Try to guess which is the old node and which is the new node from existing state (e.g. spec.MigrationNodeID) so we can properly reattach to the old node and recreate the migration engine if the old node dies. This is more similar to the previous behavior, but the implementation is probably going to be pretty fragile.
Check if we can leverage information returned by the ListVolumes RPC to communicate to Kubernetes that a volume needs to be reattached (instead of killing workload pods). This one might be a stretch.

I started implementing the first idea this morning @PhanLe1010, but ran into a major issue. Deleting the workload pod does NOT generally result in a ControllerUnpublishVolume. For example, deleting a stateful set pod from examples/statefulset.yaml resulted in the pod being restarted on the same node without a detachment or attachment every time I tried. So, in the case of a failed migration, would need to ensure the workload (VMI) fully scaled down before we could try again.

I see. Thank you for the update.

So, in the case of a failed migration, would need to ensure the workload (VMI) fully scaled down before we could try again.

Should we loop the harvester team in the design discussion? cc @Vicente-Cheng @WebberHuang1118 @bk201 Is it acceptable to scale down and up VMI when a longhorn volume crash?

Sorry for the delay on this. It has taken me a few days (and some discussions with other team members) to formulate a plan.
After executing some additional tests in v1.5.x and v1.6.x, it looks like we can mostly recover from failure scenarios without manually manipulating the volume AFTER we delete at least one VolumeAttachment. Until we do so, we are stuck with the volume in a weird state and relatively unhelpful error messages / logs.
I am proposing the following modifications. At a high level, they ensure that a migration is completely stopped (and cleaned up) when the engine on the original node fails and causes the volume to detach, leaving the volume in known state. Then, Longhorn makes no effort to reattach the volume until there is again only one attachment requested. I have discussed these changes with @PhanLe1010, @shuo-wu , and @james-munson, and I think we agree that this is the smoothest way forward.

The first AttachmentTicket for a volume is always accepted. As long as there is only one, the volume attachment controller attaches (and continually reattaches) the volume to the referenced node (by setting spec.nodeID).
A second AttachmentTicket is only accepted if the volume is already attached. This is enforced by the webhook. The volume attachment controller attempts to migrate the volume to the second referenced node (by setting spec.migrationNodeID).
If the volume ever becomes unexpectedly detached while there are two AttachmentTickets, the volume attachment controller cancels the migration (by unsetting spec.MigrationNodeID).
No further is taken by the volume attachment controller until one of the AttachmentTickets is deleted. (Optionally, the volume attachment controller can intentionally delay requeuing the LHVA after the first AttachmentTicket is deleted in case the second is also going to be deleted soon.)
While the volume is attached and migrating, the volume attachment controller does not confirm the migration (set spec.NodeID = spec.MigrationNodeID and spec.MigrationNodeId = "") in an unacceptable situation (e.g. the migration engine is not running or synced).
The DetachVolume API becomes smarter. It does not recognize a detachment success until the migration is fully finished or cancelled.

Benefits:

Kubernetes can no longer think a migratable volume is detached from a node while some Longhorn components think migration is ongoing.
The volume attachment controller doesn't have to "guess" how it should act. Most confusing situations are eliminated, and it is no longer contractually obligated to try to act in the remaining one (the volume is detached and there are multiple AttachmentTickets).
Longhorn can cancel / clean up migration components as soon as the volume fails.
Longhorn volumes are never "stuck" mid-migration.

Drawbacks:

There may be situations Longhorn can no longer recover from without upper layer intervention. (However, the current version of Longhorn also can't recover from these situations. E.g. older versions of Longhorn before v1.5.0 could continue a migration if the volume detached unexpectedly).

TODO:

[ ] Finish implementation of changes at

I reached out to @Vicente-Cheng and @WebberHuang1118 internally to discuss any Harvester implications. Now that I have a POC of how this will work, I will pause the implementation a bit to discuss any Harvester concerns before continuing.

Hi @ejweber and folks,
Thanks for the improvement!
So the new flow would be like:

volumeAttachmentTicket:

One volumeAttachmentTicket: normal case
Two volumeAttachmentTickets: volume migration case

For the error cases, I am still confused with the following situation.

If the volume becomes detached, who will delete the extra volumeAttachmentTicket? The volume attachment controller?
Does the detached cover all error cases? Means no matter if the volume is faulted or the node/engine is down? I know the node/engine down will cause the volume to detach. The faulted volume will also trigger the engine to detach the volume?

I am also curious why deleting the extra volumeAttachmentTicket will help a lot (for recovering the status before migration).
Also, which volume of volumeAttachmentTicket will be a delete target?
Based on your implementation, do we still need to delete the workload pod (like VMI) when the volume crashes during the migration?
The only case we need to delete the workload pod to reattach it might be related to volume temporarily failing.
For the VM volume usage, we could check as hotplug and internal volume.
For hotplug volume, kubevirt has its own mechanism, we can remove/add volume to the VMI again. Then, the hp-volume pod will regenerate, and the device should be back. (And it will not affect other healthy volumes). But it seems not easy to do on the Longhorn side (I mean operate the VMI object), maybe on the Harvester side, we need to handle the failed volume for the VM.
Deleting the hp-volume pod might bring some potential risk for other healthy hotplug volumes.
For the internal volume, we cannot recover(reattach) it without restarting the pod. But I still did not think respawning the virt-launcher pod was a good idea. The reason is below.
When the volume fails, the VM encounters an IOError and goes into a pause state. In this case, some data might be in memory. If we try to delete the virt-launcher pod, we might cause the root filesystem to be unclean. Then we need to do fsck/xfs_repair to rescan the metadata.

If the volume becomes detached, who will delete the extra volumeAttachmentTicket? The volume attachment controller?

The csi-plugin removes the AttachmentTicket at the request of the upper layer. If the csi-plugin receives a ControllerUnpublish call, it removes the AttachmentTicket. At this point, the volume attachment controller can attach the volume to the remaining node. So:

The user (or KubeVirt) terminates any pods running on a node that consume the volume.
The Kubernetes attach/detach controller deletes the Kubernetes VolumeAttachment.
The csi-plugin receives a ControllerUnpublish volume.
The csi-plugin removes the AttachmentTicket.
If there is now only one AttachmentTicket, the volume attachment controller attaches the volume.

Does the detached cover all error cases? Means no matter if the volume is faulted or the node/engine is down? I know the node/engine down will cause the volume to detach. The faulted volume will also trigger the engine to detach the volume?

Yes, I am not making any change here. When the volume is faulted, the volume attachment controller automatically detaches it. It can be faulted because:

All its replicas are in an error state.
Its engine crashed.
The node its engine is running on goes down. (In practice, this takes quite a bit of time, since we actually wait for the instance-manager pod to report as terminating. This doesn't happen until either the upper layer tries to delete it, or Kubernetes starts evicting pods from the down node.)

For migrating volumes, it is the original engine (or the "from" engine) and replicas that are considered for this kind of volume state. The migration engine and replicas are just clones of the original ignored by most Longhorn components.

I am also curious why deleting the extra volumeAttachmentTicket will help a lot (for recovering the status before migration).
Also, which volume of volumeAttachmentTicket will be a delete target?

I'm not sure this is quite the answer to your question, but:
As you know, in reality, Longhorn migratable volumes are RWO volumes. But KubeVirt only works with RWX volumes. So, from the KubeVirt/Kubernetes perspective, it is fine to attach a Longhorn migratable volume to any number of nodes at any time. After a volume becomes faulted and detached automatically by Longhorn, there might be multiple Kubernetes VolumeAttachments (and corresponding Longhorn AttachmentTickets). From the Kubernetes/Kubevirt perspective, the Longhorn volume should just be reattached to every node. But the Longhorn migration process requires a clear "from" node and "to" node. It is difficult (and potentially fragile) to reconcile the desired state of the world (attach to these multiple nodes) with the actual state of the world (not attached to any nodes). Also, at this point, migration has lost its meaning. The point of migration is to move the volume from one node to another while the volume remains operational. If the volume is detached from all nodes (or all but one node), it allows us to completely reset and reattach exclusively. Then, we can migrate the volume again. Ideally, this is all just a corner case. Migrations between operational nodes should be quick and not involve faulted volumes.
The upper layer or user can choose which AttachmentTicket to delete by deleting the corresponding Kubernetes VolumeAttachment. In practice, this just means deleting the pod on whichever node we no longer want to be running on and waiting for Kubernetes to clean things up.

Based on your implementation, do we still need to delete the workload pod (like VMI) when the volume crashes during the migration?

Yes. Any time a volume crashes, the workload pods must be deleted to become operational again. The current design of Longhorn cannot accommodate reattaching the volume without triggering the CSI remount flow. This is the case for all RWO and migratable Longhorn volumes.

For the internal volume, we cannot recover(reattach) it without restarting the pod. But I still did not think respawning the virt-launcher pod was a good idea. The reason is below.
When the volume fails, the VM encounters an IOError and goes into a pause state. In this case, some data might be in memory. If we try to delete the virt-launcher pod, we might cause the root filesystem to be unclean. Then we need to do fsck/xfs_repair to rescan the metadata.

This is a completely valid concern, and I'm definitely fine with Harvester disabling the setting to automatically delete the workload pod in the case of a volume failure. However, there's currently no way for a faulted RWO or migratable Longhorn volume to be used again without the CSI remount flow. I'm not sure if an improvement can be made here. We are working to make Longhorn volumes more resilient (so they are less prone to crash), but we abandoned attempts to reattach and remount outside of the CSI flow (without restarting the pod) many releases ago, so a reinvestigation is required to make progress.

Hi @ejweber,
Thanks for your reply. That's good feedback and gives me more information from the Longhorn perspective.
Just some questions follow up.

Also, at this point, migration has lost its meaning. The point of migration is to move the volume from one node to another while the volume remains operational. If the volume is detached from all nodes (or all but one node), it allows us to completely reset and reattach exclusively. Then, we can migrate the volume again.

I am curious about this case. You mentioned the case in which the volume was faulted during the migration. In this situation, we should detach from all nodes. Why did we need to reattach -> migrate again? If so, could we attach to the migrated target node instead of re-running the migration?

However, there's currently no way for a faulted RWO or migratable Longhorn volume to be used again without the CSI remount flow. I'm not sure if an improvement can be made here.

I thought we should let the user do the necessary manual operations in this case. Abandon the re-attach was fine to me. As you know, the re-attach does not make the volume can be used w/o respawning the pod.
So I think we have the setting to disable that the automatically delete operation is enough for now.

Also, at this point, migration has lost its meaning. The point of migration is to move the volume from one node to another while the volume remains operational. If the volume is detached from all nodes (or all but one node), it allows us to completely reset and reattach exclusively. Then, we can migrate the volume again.

I am curious about this case. You mentioned the case in which the volume was faulted during the migration. In this situation, we should detach from all nodes. Why did we need to reattach -> migrate again? If so, could we attach to the migrated target node instead of re-running the migration?

@Vicente-Cheng, I completely agree. Much better to detach from all nodes and then just cleanly attach to whatever node we want to run on. I wasn't really meaning we would WANT to migrate again from the old node to the new node. I just meant we will be cleanly attached to whatever single node we have an attachment for. Then, we are free to migrate in the future if requested (instead of being stuck in some kind of broken migration).

Hi @Vicente-Cheng and @ejweber
Thanks for the explanation and information,
I have two questions that may need your confirmation,
The first one:

After executing some additional tests in v1.5.x and v1.6.x, it looks like we can mostly recover from failure scenarios without manually manipulating the volume AFTER we delete at least one VolumeAttachment. Until we do so, we are stuck with the volume in a weird state and relatively unhelpful error messages / logs.

In the current implementation of LH (v.1.5.x+), if the volume crashes during the migration, the workaround to recover is to delete one of the CSI VolumeAttachment.

No further is taken by the volume attachment controller until one of the AttachmentTickets is deleted. (Optionally, the volume attachment controller can intentionally delay requeuing the LHVA after the first AttachmentTicket is deleted in case the second is also going to be deleted soon.) Clear log messages are periodically written.

The csi-plugin removes the AttachmentTicket at the request of the upper layer. If the csi-plugin receives a ControllerUnpublish call, it removes the AttachmentTicket. At this point, the volume attachment controller can attach the volume to the remaining node. So:
The user (or KubeVirt) terminates any pods running on a node that consume the volume.
The Kubernetes attach/detach controller deletes the Kubernetes VolumeAttachment.
The csi-plugin receives a ControllerUnpublish volume.
The csi-plugin removes the AttachmentTicket.
If there is now only one AttachmentTicket, the volume attachment controller attaches the volume.

In the proposed implementation, if the volume crashes during the migration, the user still needs to delete the CSI VolumeAttachment manually to recover volume, but LH could avoid being stuck in the weird state, and provide relative messages/logs?
The second one:

For hotplug volume, kubevirt has its own mechanism, we can remove/add volume to the VMI again. Then, the hp-volume pod will regenerate, and the device should be back. (And it will not affect other healthy volumes). But it seems not easy to do on the Longhorn side (I mean operate the VMI object), maybe on the Harvester side, we need to handle the failed volume for the VM.
Deleting the hp-volume pod might bring some potential risk for other healthy hotplug volumes.

For the hotplug volume, the best approach is removing the hotplug volume from the VM first then adding the volume back? Since this is going to trigger the CSI  ControllerUnpublish, and we can restart it overall again?

For the internal volume, we cannot recover(reattach) it without restarting the pod. But I still did not think respawning the virt-launcher pod was a good idea. The reason is below.
When the volume fails, the VM encounters an IOError and goes into a pause state. In this case, some data might be in memory. If we try to delete the virt-launcher pod, we might cause the root filesystem to be unclean. Then we need to do fsck/xfs_repair to rescan the metadata.

I thought we should let the user do the necessary manual operations in this case. Abandon the re-attach was fine to me. As you know, the re-attach does not make the volume can be used w/o respawning the pod.
So I think we have the setting to disable the automatically delete operation is enough for now.

For the VM root disk volume, if the volume crashes during migration, the VM is not operational without a restart (i.e. respawn virt-launcher pod). I know this likely brings data inconsistency (because in-memory data is not flushed), however, it seems there is no better way to deal with this.
I mean during this phase the in-memory data is going to be lost, does it make a difference if the automatically delete operation is enabled or not on the LH side?
Thanks

@Vicente-Cheng, I completely agree. Much better to detach from all nodes and then just cleanly attach to whatever node we want to run on. I wasn't really meaning we would WANT to migrate again from the old node to the new node. I just meant we will be cleanly attached to whatever single node we have an attachment for. Then, we are free to migrate in the future if requested (instead of being stuck in some kind of broken migration).

Hi @ejweber,
I have no questions here. Thanks for your explanation of various situations!
Looking forward to the new implementation!

For the VM root disk volume, if the volume crashes during migration, the VM is not operational without a restart (i.e. respawn virt-launcher pod). I know this likely brings data inconsistency (because in-memory data is not flushed), however, it seems there is no better way to deal with this.
I mean during this phase the in-memory data is going to be lost, does it make a difference if the automatically delete operation is enabled or not on the LH side?

Thanks for taking a look at the whole story @WebberHuang1118,
Just reply to my suggestion. For others, I thought @ejweber would have clear comments/suggestions.
I thought we finally needed to restart the virt-launcher pod to resume the non-hotplug volume.
I would like to do this manually because we might know the specific timestamp for the operation.
If the root filesystem is dirty, we could easily know that it is caused by this.
If we use the auto-delete mechanism, sometimes we would not notice this VM ever encounter this situation.
On the user's side, both auto-delete and manual operation would break down their application. So, I would like to keep the configuration (for auto-deleting) and set the default to false. If the user knows that behavior and wants to enable it, they should take responsibility for their choice.

@Vicente-Cheng @ejweber
Thanks for the detailed explanation
@ejweber I just have one question,

You are correct. Without the modifications, I managed to get the volume in a weird state a couple of times in which I thought the only way forward was to directly modify the volume CR. Once I began my testing it earnest, however, I was not able to reliably reproduce these situations. More often, the volume is stuck UNTIL one or both VolumeAttachments are deleted. Without the modifications, even when the volume is completely detached, their may be one migration field (status.currentMigrationNodeID) set, though it is not clear that this causes issues.

For the current implementation (not the proposed one), if the volume crashes during the migration, the correct workarounds are:

Manually removed migrationNodeID for the volume to be usable again. (as mentioned in https://github.com/longhorn/longhorn/issues/8735#issue-2347139063)
Remove one of the VolumeAttachment

From my understanding and trial, it seems only step 2 is needed to make volume could be used again? Step 1 is to make volume get out of a weird state (migrationNodeID == new and currentMigrationNodeID == new, but nodeID == "")?
many thanks.

Step 1 is only to make volume get out of a weird state (migrationNodeID == new and currentMigrationNodeID == new, but nodeID == "")?

Sorry for cutting the line but since I am reviewing the PR. In the current Longhorn version, once you remove one of the VolumeAttachment, does Longhorn set migrationNodeID and currentMigrationNodeID to empty automatically?

Hi @PhanLe1010
I don't have the environment currently but I can re-check it later, thanks.

once you remove one of the VolumeAttachment, does Longhorn set migrationNodeID and currentMigrationNodeID to empty automatically?

@Vicente-Cheng @ejweber @PhanLe1010
I just tested with the steps @PhanLe1010 provided before

Create a storageclass with migratable: true
Create a PVC from that SC with accessmode RWX
Deploy a CSI VolumeAttachment object points to node-1
Wait for volume to be attached, deploy another CSI VolumeAttachment object points to node-2
Wait for volume to be in the middle of migration process (you can follow the logs of longhorn-manager)
Kill the longhorn engine on node-1
Volume is stuck in weird state

Assume the source CSI VolumeAttachment is va-1 to attach the volume to node1, and the new CSI VolumeAttachment (migration target) is va-2 to attach the volume to node2
After step 7,
If I manually delete the target CSI va va-2:

migrationNodeID and currentMigrationNodeID will be empty automatically
Volume automatically re-attach to node1

If I manually delete the source CSI va va-1:

migrationNodeID == new and currentMigrationNodeID == new, but nodeID == ""
Volume stuck in the detached state
Manually remove migrationNodeID to make volume attach to node2

Thanks @ejweber, it became much more clear to me.
@Vicente-Cheng, I think we maybe need to have a document about how to deal with volume crash during VM migration, including current and proposed implementation (both root disk volume and hotplug volume). WDYT? Thanks.

I agree, we should write about the different situations of the above discussion and how to fix them.
I created an issue (https://github.com/harvester/harvester/issues/6117) for document enhancement.
Thanks for the reminder!

@ejweber Need your help to clarify the test cases: https://github.com/longhorn/longhorn-tests/pull/1948. Thank you!

Verified on master-head (longhorn-manager efeb3c8) following the test plan. All migration scenarios worked as expected.


Users missing on /etc/passwd

Kairos version 2.4.5
Apr 18 18:28:25 localhost systemd[1]: Stopped OpenBSD Secure Shell server.
Apr 18 18:28:25 localhost systemd[1]: Starting OpenBSD Secure Shell server...
Apr 18 18:28:25 localhost sshd[1618]: Privilege separation user sshd does not exist
Apr 18 18:28:25 localhost systemd[1]: ssh.service: Control process exited, code=exited, status=255/EXCEPTION
Apr 18 18:28:25 localhost systemd[1]: ssh.service: Failed with result 'exit-code'.
Apr 18 18:28:25 localhost systemd[1]: Failed to start OpenBSD Secure Shell server.

Seems to be a very corner case for us. I have only seen this once.
Config file that triggered this:
#cloud-config

cosign: false
install:
    auto: true
    device: auto
    grub-entry-name: Palette eXtended Kubernetes Edge
    grub_options:
        saved_entry: registration
    passive:
        size: 8192
    poweroff: true
    reboot: false
    recovery-system:
        size: 10000
    system:
        size: 8192
reset:
    grub-entry-name: Palette eXtended Kubernetes Edge
    system:
        size: 8192
stages:
    after-upgrade:
        - commands:
            - mkdir -p /usr/local/bin
            - '[ -L /usr/local/bin/agent-provider-stylus ] || ln -s /opt/spectrocloud/bin/agent-provider-stylus /usr/local/bin/agent-provider-stylus'
            - '[ -L /usr/local/bin/palette-tui ] || ln -s /opt/spectrocloud/bin/palette-tui /usr/local/bin/palette-tui'
            - bash /opt/spectrocloud/scripts/content.sh
          name: Execute after upgrade commands
        - commands:
            - grub2-editenv /oem/grubenv unset saved_entry
          if: '[ -f /oem/grubenv ]'
          name: Unset registration grubenv
    before-install:
        - commands:
            - echo -n > /etc/machine-id
          if: '[ -f "/run/cos/live_mode" ]'
          name: Remove machine-id
        - commands:
            - echo -n > /etc/machine-id
          if: '[ -f "/run/cos/live_mode" ]'
          name: Remove machine-id
    initramfs:
        - name: Create kairos user
          users:
            kairos:
                groups:
                    - sudo
                passwd: kairos
        - users:
            kairos:
                groups:
                    - sudo
                passwd: kairos
        - name: Create kairos user
          users:
            kairos:
                groups:
                    - sudo
                passwd: kairos
        - users:
            kairos:
                groups:
                    - sudo
                passwd: kairos
        - if: '[ ! -f /oem/80_stylus.yaml ]'
          name: set_inotify_max_values
          sysctl:
            fs.inotify.max_user_instances: "8192"
            fs.inotify.max_user_watches: "524288"
stylus:
    includeTui: false
    installationMode: airgap
    skipStylusUpgrade: true
upgrade:
    grub-entry-name: Palette eXtended Kubernetes Edge
    passive:
        size: 8192
    recovery-system:
        size: 8192
    system:
        size: 8192
verify: false

This might be related to this: https://github.com/kairos-io/kairos/issues/2492

Missing here is the info that the sshd user did indeed disappeared from the /etc/passwd

@nianyush can you confirm that this is also the same issue you experienced with the fully deleted /etc/passwd/ after a kairos-agent upgrade?

@mauromorales yes it's exactly the same issue. Only sshd user is lost from /etc/passwd and rest looks fine

encountered this issue again yesterday with kairos v3.0.6 and uki mode. After doing kairos-agent upgrade with a new image and then reboot, i cannot ssh into the vm anymore.

@nianyush thanks for the extra info. To which version did you upgrade to? the same?

@mauromorales yes there is no difference in kairos or os version

@nianyush do you by any chance have this system still online? if so, could you share the mounts?

yes i still have those systems. from 3.0.6 with uki

While this was detected becasue of the lack of ssh access, the issue is not related to sshd, but to the fact that a bunch of users are missing from the /etc/passwd. I've renamed the ticket to reflect this.

@nianyush if you still got access to the machines would it be possible to extract the logs from it?
Kairos logs, journalctl logs, immucore+stages logs would all be very useful. Especially the 2.4.5 which we have access to the original qcow2 file so we can try to reproduce.
Also, is there any metadata attached to the machine? cdrom/usb with a config drive?

@nianyush also if possible, can you check for any other units breaking in systemd? And is it possible to compare the user list vrs a system that is working correctly, want to validate my previous comment

Managed to reproduce after several runs
root@localhost:/home/kairos# cat /etc/os-release
PRETTY_NAME="Ubuntu 23.10"
NAME="Ubuntu"
VERSION_ID="23.10"
VERSION="23.10 (Mantic Minotaur)"
VERSION_CODENAME=mantic
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=mantic
LOGO=ubuntu-logo
KAIROS_IMAGE_LABEL="23.10-core-amd64-generic-v3.0.7"
KAIROS_ARTIFACT="kairos-ubuntu-23.10-core-amd64-generic-v3.0.7"
KAIROS_FLAVOR="ubuntu"
KAIROS_MODEL="generic"
KAIROS_BUG_REPORT_URL="https://github.com/kairos-io/kairos/issues"
KAIROS_VARIANT="core"
KAIROS_TARGETARCH="amd64"
KAIROS_ID="kairos"
KAIROS_NAME="kairos-core-ubuntu-23.10"
KAIROS_VERSION="v3.0.7"
KAIROS_PRETTY_NAME="kairos-core-ubuntu-23.10 v3.0.7"
KAIROS_IMAGE_REPO="quay.io/kairos/ubuntu:23.10-core-amd64-generic-v3.0.7"
KAIROS_FAMILY="ubuntu"
KAIROS_REGISTRY_AND_ORG="quay.io/kairos"
KAIROS_VERSION_ID="v3.0.7"
KAIROS_FLAVOR_RELEASE="23.10"
KAIROS_RELEASE="v3.0.7"
KAIROS_HOME_URL="https://github.com/kairos-io/kairos"
KAIROS_SOFTWARE_VERSION_PREFIX="k3s"
KAIROS_ID_LIKE="kairos-core-ubuntu-23.10"
KAIROS_GITHUB_REPO="kairos-io/kairos"

root@localhost:/home/kairos# cat /etc/passwd
kairos:x:1000:65538:Created by entities:/home/kairos:/bin/sh
root:x:0:0::/root:/bin/bash
daemon:x:1:1::/usr/sbin:/usr/sbin/nologin
bin:x:2:2::/bin:/usr/sbin/nologin
sys:x:3:3::/dev:/usr/sbin/nologin
sync:x:4:65534::/bin:/bin/sync
games:x:5:60::/usr/games:/usr/sbin/nologin
man:x:6:12::/var/cache/man:/usr/sbin/nologin
lp:x:7:7::/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8::/var/mail:/usr/sbin/nologin
news:x:9:9::/var/spool/news:/usr/sbin/nologin
uucp:x:10:10::/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13::/bin:/usr/sbin/nologin
www-data:x:33:33::/var/www:/usr/sbin/nologin
backup:x:34:34::/var/backups:/usr/sbin/nologin
list:x:38:38::/var/list:/usr/sbin/nologin
irc:x:39:39::/run/ircd:/usr/sbin/nologin
_apt:x:42:65534::/nonexistent:/usr/sbin/nologin
nobody:x:65534:65534::/nonexistent:/usr/sbin/nologin
messagebus:x:109:109:System Message Bus:/:/usr/sbin/nologin
polkitd:x:996:996:polkit:/nonexistent:/usr/sbin/nologin
systemd-network:x:998:998:systemd Network Management:/:/usr/sbin/nologin
systemd-resolve:x:995:995:systemd Resolver:/:/usr/sbin/nologin
systemd-timesync:x:997:997:systemd Time Synchronization:/:/usr/sbin/nologin

Looking at the previous yip analysis, it seems like 2 of the user creation get executed in parallel, when normally they should be done in serial (they are all touching the /etc/passwd file and there's no mutex mechanism as far as I can tell)
I think this somehow comes from having those name: Create kairos user attributes. On a config with 4 duplicated users but without a name they all get evaluated as a single step:
root@localhost:/home/kairos# ./yip -a -s initramfs no-name.yaml
INFO[0000] yip version v1.6.1-g9484451dac23973ab3cd8a76df42edb2415f7f3e 2024-04-22 13:12:56 UTC
INFO[0000] 1.
INFO[0000]  <init> (background: false) (weak: false)
INFO[0000] 2.
INFO[0000]  <no-name.yaml.0> (background: false) (weak: true)
INFO[0000] 3.
INFO[0000]  <no-name.yaml.1> (background: false) (weak: true)
INFO[0000] 4.
INFO[0000]  <no-name.yaml.2> (background: false) (weak: true)
INFO[0000] 5.
INFO[0000]  <no-name.yaml.3> (background: false) (weak: true)
INFO[0000] 6.
INFO[0000]  <no-name.yaml.set_inotify_max_values> (background: false) (weak: true)

I think that the problem comes because of the duplicated name of those user creations, if the names are different, the analysis is similar to the one in the previous comment.
However, because the names are the same, when yip starts adding dependencies, it uses the name as the identifier of the dependency, which when inverting the graph will group them together

Glad to hear you can reproduce it. I don't have that 2.4.5 vm anymore :(

@nianyush thanks a lot for opening the issue and providing all the info though, if it wasn't for your screenshots I wouldn't have had an idea where to look

The fix for this issue is now in the latest Kairos release (artifacts building, give it a couple of hours)
Kairos: https://github.com/kairos-io/kairos/releases/tag/v3.0.8
Agent: https://github.com/kairos-io/kairos-agent/releases/tag/v2.8.13

@mauromorales @Itxaka facing this issue again with 3.0.10 kairos

this is still an issue

the backported version of the agent depends on the right yip version but unfortunately we didn't bump it on immucore backports only on main branch

seems to be fixed in the latest


generate_dataset fails for 1d signals

Because of this step: https://github.com/deepinv/deepinv/blob/9e61435e68e7906fd8cf043b71e8a3900c0c4868/deepinv/datasets/datagenerator.py#L198
generate_dataset expects a 4d tensor which is not ideal for working with 1d signals (and so work with 3d tensor).
I propose to change in x[:bsize,...].to("cpu").numpy() .

this has been fixed


New layer control, idea.

I've been working in a new layer control directive with this features:

Order layers
Opacity control.
Font awesome integration.

Example: http://elesdoar.github.io/angular-leaflet-directive/examples/layer-control-example.html
Any idea for more features or design?

Closed as old. Please reopen if needed.


Create VM - Change default diskType for Template and ISO provisioned VMs

Fixes: #1237
Following the description in issue #1237, change the diskType as per the template VM type and where disks will be created.
Summary of changes:

Storage: When creating a new disk, default diskType to 'thin'.  This matches behavior in VM Details Disk card.

CreateVmWizard: When preparing Template Disks for the Storage card, default the disk's diskType to the template disk's sparse flag when the template is optimizedFor (VM type of) "desktop" and the user can use the disk's storage domain.  When optimizedFor is not "desktop", or if a "desktop" disk resides in a storage domain the user does not have access to use, set disk type to preallocated.

composeAndCreateVm() saga: To be able to have a template disk created in a different target storage domain, or to change its diskType/sparsity on creation, disks need to specified on the VM's creation JSON object.  The compose sagas and supporting functions now support this kind of creation.

The disk default values look ok to me. However, in the Create VM Wizard, when choosing the template with "Optimized For" field set to "Desktop", I can see the new disks based on the template with thin provision, but if I change the "Optimized For" to "Server" field, nothing changes regarding the disks. The default is still thin provision, for the new disks. Is this behavior expected? I'm not sure.

Ah, I'm looking at the template's optimizedFor value, not the one on basic settings.  So switching it up on basic would have no effect on the template's diskType.
@sgratch - I think it is safer to consider the template's optimizedFor (VM type) instead of the basic details value.  WDYT?  It is an easy change to use user selected, but I'm not sure it would be correct.

This PR is to be replaced with #1323.

Moved the last comment to #1323, closing this PR.


fix attach cause goroutine leak

fix https://github.com/containerd/containerd/issues/8443
if use crictl attach (or kubectl attach ) without -i   will exit after 10mintes which can be seted by using "attach_nostdin_timeout"
otherwise will exit untill crictl attach (or kubectl attach) process is stopped.

This doesn't really seem to fix the underlying problem with attach.
I believe there's also similar issues in moby (and has been around since forever). See https://github.com/moby/moby/pull/45052
The only way I could make that work reliably, at least for the docker case where the client will half-close a connection, is to setup epoll to watch the client fd's (see 2nd commit in that PR).
The simpler solution may work for cri (3rd commit), but is wholly dependent on how the client handles the connection.

This doesn't really seem to fix the underlying problem with attach. I believe there's also similar issues in moby (and has been around since forever). See moby/moby#45052
The only way I could make that work reliably, at least for the docker case where the client will half-close a connection, is to setup epoll to watch the client fd's (see 2nd commit in that PR). The simpler solution may work for cri (3rd commit), but is wholly dependent on how the client handles the connection.

I find    ctx.closeChan = conn.CloseChan() can get event when crictl is exited or killed, I think it is not suitable let client do it. because if client is kiilled may still have some goroutine leak.


Feature Request:  Add Areas to Entity Registry

I'm creating an issue in the hopes that one of the developers will see this and decide it's worthy to code and not too much trouble.
Currently only devices that have an integration can be placed in an Area in Home Assistant.  Devices that must be configured through the configuration.yaml file have no way of being placed in an Area.  A simple solution to this would be to add a line in the UI for the Entity Registry to allow each entity to be placed in an Area.
I cannot express how backwards it is to only be able to put some of your devices in an Area and not the rest.  It would almost make sense to remove the Areas feature if the developers are not willing to make it feature complete.  It is not fun creating an Area and having a pretty lovelace card show up in your overview and not being able to get all your devices to that card.  I know I can configure the UI separately but it would be nice to not have to do that.

Thank you for reaching out. We use GitHub for tracking issues, not for providing support or tracking feature requests.
If you want to suggest a feature, you should try our Community Forum: Feature Requests.
If you have additional questions, feel free to join our Discord chat server.
Thanks! 👍


Unexpected handling of binary annotations containing signed long values

I noticed after upgrading from version 1.7 to 1.8 (and later 1.8.1) of Zipkin, that the recent Codec changes may have introduced a regression in the handling of binary annotations containing negative ints or longs.
I found it easy to reproduce using the TracingBasics demo in activator-akka-tracing which records the result of Random.nextLong() as a binary annotation.
After running this demo, attempting to 'Find Traces' using the UI results in an error similar to:
Error executing query: Expected -1005656679588439279 to be unsigned

I've been able to trace this back to the checkArgument call in Buffer.java:246
Admittedly, I don't understand Zipkin well enough to know whether this was/is now intended behaviour. If it is, I can raise an issue with the authors of the akka-tracing / activator-akka-tracing projects.

this probably wasn't caught because people don't use Long annotations (as
they are unqueryable and likely to be removed in the future).
That said, happy to fix the regression.. will have a go shortly!
On Mon, Sep 5, 2016 at 10:48 AM, Tristan Penman<EMAIL_ADDRESS>wrote:

I noticed after upgrading from version 1.7 to 1.8 (and later 1.8.1) of
Zipkin, that the recent Codec changes may have introduced a regression in
the handling of binary annotations containing negative ints or longs.
I found it easy to reproduce using the TracingBasics demo in
activator-akka-tracing
https://github.com/levkhomich/activator-akka-tracing which records the
result of Random.nextLong() as a binary annotation.
After running this demo, attempting to 'Find Traces' using the UI results
in an error similar to:
Error executing query: Expected -1005656679588439279 to be unsigned
I've been able to trace this back to the checkArgument call in
Buffer.java:246
Admittedly, I don't understand Zipkin well enough to know whether this
was/is now intended behaviour. If it is, I can raise an issue with the
authors of the akka-tracing / activator-akka-tracing projects.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/openzipkin/zipkin/issues/1268, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAD613oKg43fHfDA3FQkSCqB-08qW1l9ks5qm4MVgaJpZM4J0s4i
.

in general, tracers toString inputs like numbers, which allows them to be
queryable.
here's the model v2 thing which hopefully will remove the niche numeric
types like i16 https://github.com/openzipkin/zipkin/issues/939
On Mon, Sep 5, 2016 at 10:51 AM, Adrian Cole<EMAIL_ADDRESS>wrote:

this probably wasn't caught because people don't use Long annotations (as
they are unqueryable and likely to be removed in the future).
That said, happy to fix the regression.. will have a go shortly!
On Mon, Sep 5, 2016 at 10:48 AM, Tristan Penman<EMAIL_ADDRESS>wrote:

I noticed after upgrading from version 1.7 to 1.8 (and later 1.8.1) of
Zipkin, that the recent Codec changes may have introduced a regression in
the handling of binary annotations containing negative ints or longs.
I found it easy to reproduce using the TracingBasics demo in
activator-akka-tracing
https://github.com/levkhomich/activator-akka-tracing which records the
result of Random.nextLong() as a binary annotation.
After running this demo, attempting to 'Find Traces' using the UI results
in an error similar to:
Error executing query: Expected -1005656679588439279 to be unsigned
I've been able to trace this back to the checkArgument call in
Buffer.java:246
Admittedly, I don't understand Zipkin well enough to know whether this
was/is now intended behaviour. If it is, I can raise an issue with the
authors of the akka-tracing / activator-akka-tracing projects.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/openzipkin/zipkin/issues/1268, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAD613oKg43fHfDA3FQkSCqB-08qW1l9ks5qm4MVgaJpZM4J0s4i
.

You might have set a record for fastest issue response there. Thanks for looking into it!
So it sounds like the right thing for me to do here would be to raise issues (or submit PRs) for the projects that I'm using, since string values are clearly the direction forward.

oh interesting.. I think that there's an issue with B3 in that demo. Ex.
trace ids are being toString'ed as opposed to lower-hex.
you can copy/paste stuff from here until we have extracted a  B3 library
https://github.com/uber/jaeger-client-java/blob/master/jaeger-zipkin/src/main/java/com/uber/jaeger/propagation/b3/B3TextMapCodec.java
On Mon, Sep 5, 2016 at 10:57 AM, Tristan Penman<EMAIL_ADDRESS>wrote:

You might have set a record for fastest issue response there. Thanks for
looking into it!
So it sounds like the right thing for me to do here would be to raise
issues (or submit PRs) for the projects that I'm using, since string values
are clearly the direction forward.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/openzipkin/zipkin/issues/1268#issuecomment-244648948,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAD61_QMilNmAIXpKu2oRyMFfxAaxlv9ks5qm4UpgaJpZM4J0s4i
.

I can't find that line number (with checkArgument), but I can add some
tests to flush out a bug hopefully.
On Mon, Sep 5, 2016 at 10:48 AM, Tristan Penman<EMAIL_ADDRESS>wrote:

I noticed after upgrading from version 1.7 to 1.8 (and later 1.8.1) of
Zipkin, that the recent Codec changes may have introduced a regression in
the handling of binary annotations containing negative ints or longs.
I found it easy to reproduce using the TracingBasics demo in
activator-akka-tracing
https://github.com/levkhomich/activator-akka-tracing which records the
result of Random.nextLong() as a binary annotation.
After running this demo, attempting to 'Find Traces' using the UI results
in an error similar to:
Error executing query: Expected -1005656679588439279 to be unsigned
I've been able to trace this back to the checkArgument call in
Buffer.java:246
Admittedly, I don't understand Zipkin well enough to know whether this
was/is now intended behaviour. If it is, I can raise an issue with the
authors of the akka-tracing / activator-akka-tracing projects.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/openzipkin/zipkin/issues/1268, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAD613oKg43fHfDA3FQkSCqB-08qW1l9ks5qm4MVgaJpZM4J0s4i
.

It might help if I paste the code block and path.
/zipkin/zipkin/src/main/java/zipkin/internal/Buffer.java:
Buffer writeAscii(long v) {
    if (v == 0) return writeByte('0');
    checkArgument(v > 0, "Expected %s to be unsigned", v);
    int width = asciiSizeInBytes(v);
    int pos = this.pos += width; // We write backwards from right to left.
    while (v != 0) {
      int digit = (int) (v % 10);
      buf[--pos] = HEX_DIGITS[digit];
      v /= 10;
    }
    return this;
  }

just found it, but thanks for the assist!!

I was on a wrong branch :)

gonna take me an hour (developer hour.. so maybe a couple :) ) to fix
this, as I intentionally special-cased and forgot that this function
was used for binary annotations. stand by!
On Mon, Sep 5, 2016 at 11:15 AM, Adrian Cole<EMAIL_ADDRESS>wrote:

I was on a wrong branch :)

No problem at all. This response has already exceeded all of my expectations! 👍

I'm pleased to say that your fix in commit 3b8d56ac1b817729517e32c7a3d311b7ceaa2fb7 has resolved the issue.
Thanks again for your help!

Thanks for your help identifying this! 1.8.2 will be out shortly


redirect all messages to log

When some plugin crushed messages output to vim. This is uncomfortably. It would be nice to be able to forward all messages to a log.
exampe:
set debug_msg_log = 1
set debug_msg_log_path = '/home/user/.vim/debug.log'

are you looking for verbosefile setting?

I am closing this, as I am not sure, what exactly is asked here. Please use the mailinglist for user questions.


Feature request: Disable viewer popper completely

Hi,
first of all thank for the awesome library!
I have a feature request: I have the use case where the user clicks on a calendar event and gets redirected to a different view. Currently, I use the onEventClick callback to navigate to the new view and use this as a hack to get rid of the unwanted popper:
customViewer={(_event, close) => {
  setTimeout(function () {
    close();
  }, 50);
}}

This seems not very good to me and could lead to race conditions.
Could you introduce a property, say disableViewer: boolean that disables the viewer popper completely?

Hi
you can use disableViewer prop in next release

Thanks!

@aldabil21 Just tried it out. I have to mention one shortcoming: If the disableViewer option is set, the onEventClick callback does not fire. Could you fix that?

@marcauberer try with version 2.8.4 that enables the use of onEventClick with disableViewer. https://github.com/aldabil21/react-scheduler/pull/338

Will do, thanks!

@aldabil21 @slash-84 onEventClick works now, but the viewer is still showing when agenda view is active. Can you fix that as well?

i created https://github.com/aldabil21/react-scheduler/pull/340


fix pythonw and pyinstaller 5.7 issue

Kivy apps will crash if run from pythonw or if they are built with pyinstaller 5.7.  The reason is that these runtimes set sys.stderr  to None, causing a recursion error in the python logger.  This fix sets the KIVY_NO_CONSOLELOG environment if sys.stderr is None.  This preserves the behavior prior to pyinstaller 5.7, and allows correct operation under pythonw.exe
This will fix this issue: https://github.com/kivy/kivy/issues/8074
Here is a small test I used developing the fix. The design of the logger redirects messages written to stderr to the logfile. That behavior is retained. If this code is executed with pythonw (or is built with pyinstaller 5.7) on a version of kivy without the fix - it will fail to run.
import sys

initial_stderror = sys.stderr  # at startup sys.stderror == None

from kivy.app import App
from kivy.uix.label import Label
from kivy.logger import Logger
from kivy.lang.builder import Builder
import itertools

kv = """
BoxLayout:
    orientation: 'vertical'
    AnchorLayout
        Button:
            size_hint: None, None
            size: dp(200), dp(48)
            text: 'Say Hello'
            on_release: label.say_hello()
    HelloLabel:
        id: label
        size_hint_y: None
        height: dp(48)
        text: 'Nice to meet you'
"""

class HelloLabel(Label):
    def __init__(self, **kwargs):
        super().__init__(**kwargs)
        self.hellos = itertools.cycle(['Hello to you!', 'Hey There!', "What's up?"])

    def say_hello(self):
        self.text = next(self.hellos)
        Logger.info(f'{self.text=}')
        # writes to stderr should be logged under pythonw or pyinstaller, but not written to the console
        print('print to stderr', file=sys.stderr)
        sys.stderr.write('write to stderr\n')

class ExampleWithPyinstallerApp(App):
    def build(self):
        return Builder.load_string(kv)

    def on_stop(self):
        Logger.info(f'sys.stderr before kivy loads: {initial_stderror}; sys.stderr at on_stop: {sys.stderr}')

ExampleWithPyinstallerApp().run()

Maintainer merge checklist

[x] Title is descriptive/clear for inclusion in release notes.
[x] Applied a Component: xxx label.
[ ] Applied the api-deprecation or api-break label.
[ ] Applied the release-highlight label to be highlighted in release notes.
[x] Added to the milestone version it was merged into.
[ ] Unittests are included in PR.
[ ] Properly documented, including versionadded, versionchanged as needed.

Why not test if stderr exist at line 598 and change it to if sys.stderr and 'KIVY_NO_CONSOLELOG' not in os.environ:?
I don't think Kivy should set environment variables as that should be left to users.

Why not test if stderr exist at line 598 and change it to if sys.stderr and 'KIVY_NO_CONSOLELOG' not in os.environ:?
I don't think Kivy should set environment variables as that should be left to users.

Fair enough -that was my original implementation.  I changed it for 2 reasons.

I thought setting the environment variable was more explicit
There is an ordering dependency between line 629 https://github.com/kivy/kivy/blob/d69693256d3bd8202922e3784cc75daf6e39aa46/kivy/logger.py#L629
where stderr is redefined, and line 620 where the call to add_kivy_handlers(logging.root) would be using stderr in the if statement.

This is not a strongly held opinion.  If you would like me to do in the other way, I'm happy to update the PR.  Let me know your thoughts.

@pythonic64
Here is an idea to capture the "benefits" of my approach, without setting the environment variable.   Create a new global variable that mirrors the name of the environment variable and use this in the add_kivy_handlers() function.
At around line 616:
KIVY_NO_CONSOLE_LOG =  not sys.stderr or 'KIVY_NO_CONSOLELOG' in os.environ

and then in add_kivy_handler(), at line 598
 if not KIVY_NO_CONSOLELOG:
    # load console log handler

What do you think?

Requested change completed

@ElliotGarbus Parenthesis are redundant and and you could have used my suggestion https://github.com/kivy/kivy/pull/8345#issuecomment-1675214065 which is shorter.

@ElliotGarbus Parenthesis are redundant and and you could have used my suggestion #8345 (comment) which is shorter.

Thanks for the feedback.
I used the suggestion from  @Julian-O.  I think testing for None is more precises and the parenthesis improve readability.
If you're an approving reviewer, and would like the change I would be happy to do it.  Otherwise, I'll let it stand until the code is reviewed by an approver.

@ElliotGarbus:

This function should be included in test_logger.py (which already imports sys).
I know pytest fiddles with sys.stderr before calling your test method, function, but I don't know if it gets upset it you fiddle with it too. I would play it safe and record the old value (original_stderr = sys.stderr' before sys.stderr = Noneand thensys.stderr = original_stderr` at the end.
I think you need to set stderror to None before the import of logger, because that is when the check is done, isn't it?
The test scripts are executed three different times , with three different values for KIVY_LOG_MODE. [This is done in the action scripts that call the test code.] You may need to put a @pytest.mark.skipif check on your test - there are examples in the file - so it only runs in some modes, not others.
In KIVY mode (the default) and MIXED, the handlers should be added automatically, so you don't need to call add_kivy_handlers. In PYTHON mode, the handlers aren't added, so you will need to call it yourself.
Purely a style issue: I would make the search for a console handler into one line:

console_handler_found  = any(isinstance(handler, ConsoleHandler) for handler in Logger.handlers)

Generally, avoid using is for values apart from None. The last line should read:

assert not console_handler_found

or even better, make the assert self-commenting if it fails.
assert not console_handler_found, "Console handler added, despite sys.stderr being None"

I am worried we might be talking about different things, and confusing each other.
I see three different levels that you could test at.
You could do an integration test. This would be to call the code with pythonw.exe or pyinstaller, and show it works now where it didn't before. That would be a solid test, and would test your understanding of the cause of the problem, but will be tricky to produce in pytest.
You could do a low-level unit test. This would be to test just the code in kivy_add_handlers() without any of the surrounding code. That would be a reasonable approach. I think that is what you were aiming to do. The best way to do that would be to only run the test when in PYTHON mode. (i.e. decorate the test to skipif it is not python mode). In that case, the implicit steps (stderr being redirected to a class and add_kivy_handlers being called) are not performed, so you don't need to do the work to "undo" them. You can redirect stderr and call add_kivy_handlers() yourself, and check that the console handlers are not added.
I thought you were doing a mid-level unit-test, where you test the way the whole module behaves. In that case, you would test it in Kivy and Mixed modes. You would redirect sys.stderr to None first, before the import, and then immediately after the import check that the implicit call to add_kivy_handlers worked correctly, without calling it again. If you were being thorough, you would repeat the test in Python mode, but this time explicitly call add_kivy_handlers(), because even though I don't think many people will use this feature [i.e. manually add the Kivy loggers] it is advertised as possible.
I think I would prefer a mid-level test, but I would accept a low-level one. Doing both a low-level and mid-level test is a bit "belt-and-braces" - I would suggest only doing one, unless you really want to be sure.
Finally: The order of the code (except in PYTHON mode) is add the handlers first and then redirect stderr (so any output to stderr is captured by the logging systems).  I don't think this is very important for this discussion.

@Julian-O
Thanks for the additional feedback.  I don't think we were talking past each other at all.  I will admit to only narrowly thinking about the KIVY mode of the logger.  Using PYTHON mode for the low-level test makes lots of sense.  It had not even occurred to me.
And looking back at the logger.py source code I see I misspoke about the order of event 😞.  Thanks for catching that.  I'll get back to this later today.

@Julian-O
How should I invoke pytest?  I think I have a configuration issue or an simply calling pytest incorrectly. Do I need to set the env vars?
I'm using a pip installed kivy, and jumping into the venv, and editing the test file.
I'm current invoking:
(venv) PS C:\Users\ellio\PycharmProjects\ExampleWithPyinstaller\venv\Lib\site-packages\kivy\tests> pytest test_logger.py::test_logger_fix_8345
Here is my test, with some added logging output:
def test_logger_fix_8345():
    """
    The test checks that the ConsoleHandler is not in the Logger
    handlers list if stderr is None.  Test sets stderr to None,
    if the Console handler is found, the test fails.
    Pythonw and Pyinstaller 5.7+ (with console set to false) set stderr
    to None.
    """
    from kivy.logger import Logger, add_kivy_handlers, ConsoleHandler
    Logger.info(f'Initial state: {Logger.handlers=} {LOG_MODE=} {os.environ.get("KIVY_LOG_MODE")=}')
    original_sys_stderr = sys.stderr
    sys.stderr = None
    add_kivy_handlers(Logger)
    Logger.info(f'{Logger.handlers=} {LOG_MODE=}')
    sys.stderr = original_sys_stderr  # restore sys.stderr
    console_handler_found = any(isinstance(handler, ConsoleHandler) for handler in Logger.handlers)
    assert not console_handler_found, "Console handler added, despite sys.stderr being None"

Here is the relevant log outputs:
[INFO   ] Initial state: Logger.handlers=[] LOG_MODE='KIVY' os.environ.get("KIVY_LOG_MODE")=None
[INFO   ] Logger.handlers=[<LoggerHistory (NOTSET)>, <FileHandler (NOTSET)>] LOG_MODE='KIVY'

I'm surprised to see KIVY_LOG_MODE is None,
Thanks again!

I'm surprised to see KIVY_LOG_MODE is None,

That's working as designed. You haven't set the environment variable, so it is None. There is a line in test_logger.py that says:
LOG_MODE = os.environ.get("KIVY_LOG_MODE", "KIVY")

i.e. if no environment variable is set, default to KIVY mode. [Defaulting to KIVY mode was to make sure existing Kivy apps still worked like they used to.]

How should I invoke pytest?

The automated tests (which run when you push to GitHub or do a pull request) runs the test three times. (Look at windows_ci.ps1 for an example of where that is specified.)
First it leaves KIVY_LOG_MODE unset and runs all the tests (except those covered with a skip)
Then it sets KIVY_LOG_MODE to PYTHON, and runs only the tests marked as "logmodepython".
Then it sets KIVY_LOG_MODE to MIXED, and runs only the tests marked as "logmodemixed".
Because you don't want to run the test in KIVY mode, you should add a decorator:
@pytest.mark.skipif(
    LOG_MODE != "PYTHON",
    reason="Requires KIVY_LOG_MODE==PYTHON to run.",
)

You can run pytest test_logger.py::test_logger_fix_8345 and confirm that the test is skipped.
Because you do want to the test to be run in the second pass, you should add another decorator:
@pytest.mark.logmodepython

Now, to invoke it, you need to first set the environment variable. I see you are on Windows so the command should be SET KIVY_LOGGING_MODE=PYTHON.
Running the tests now with pytest test_logger.py::test_logger_fix_8345 should work.
If you run pytest -m logmodepython test_logger.py it should run a small suite of tests, including your test.
I am happy with what I am seeing, but one thing confuses me. Because you ran your existing test in KIVY mode, add_kivy_handlers() was presumably called twice - once implicitly on import (including a Console Log), and once explicitly by your test (without adding another ConsoleLog). I would have expected the test to fail, but you don't mention that it did.

I am happy with what I am seeing, but one thing confuses me. Because you ran your existing test in KIVY mode, add_kivy_handlers() was presumably called twice - once implicitly on import (including a Console Log), and once explicitly by your test (without adding another ConsoleLog). I would have expected the test to fail, but you don't mention that it did.
The environment variable is not set to 'KIVY', it is None.  Note the message from the logger, this is after kivy.logger is imported:
[INFO   ] Initial state: Logger.handlers=[] LOG_MODE='KIVY' os.environ.get("KIVY_LOG_MODE")=None
The Logger evaluates the environment variable - and in this case effectively defaults to PYTHON. We can see none of the handlers are loaded.  How/where does pyinstaller set the environment variable?

The environment variable is not set to 'KIVY', it is None.

Yes. (Well, pedantically it is not set at all, and the os.environ.get call defaults to None, but yes.)

The Logger evaluates the environment variable - and in this case effectively defaults to PYTHON.

It shouldn't be the case that it defaults to PYTHON. There is a line in logger.py:
KIVY_LOG_MODE = os.environ.get("KIVY_LOG_MODE", "KIVY")

i.e. if the environment variable is not set, default to KIVY.

We can see none of the handlers are loaded.

That has me flustered. I wonder why not.

How/where does pyinstaller set the environment variable?

I have almost no knowledge about pyinstaller. I doubt it sets the KIVY_LOG_MODE environment variable. Does it set NO_CONSOLE_LOG one?

Slaps forehead Of course! I see the problem!
In KIVY mode (the default), a logger called "Kivy" is created, but the handlers are added to the root logger. Kivy sends log messages to the Kivy logger, but it has no handlers, so the event escalate up the tree to the root logger, and is handled there. Any custom logger that a client creates will also be handled by root logger, and go through the Kivy handlers.
In MIXED mode, a logger called "Kivy" is created and the handlers are added directly to that. So now, the events raised by Kivy are handled by the Kivy loggers, and events send to other loggers can be handled however the user wants.
In PYTHON mode, a logger called "Kivy" is created, but no handlers are added. A user may choose to add Kivy handlers, or not, wherever they like.
So, in the case of this test:

No environment variable is set, so it defaults to KIVY mode.
A logger called Kivy is created, and no handlers are implicitly added.
The root logger has kivy handlers implicitly added.
The test checks if the kivy logger has handlers, and finds it doesn't. It doesn't notice that the root logger DOES have handlers!
It adds more handlers to the kivy logger (so now there are two sets of handlers at different points in the logger tree).

This explains why it is running now.
I think limiting it to PYTHON mode, as described earlier, is still the right direction.

KIVY_LOG_MODE = os.environ.get("KIVY_LOG_MODE", "KIVY")

This sets the KIVY_LOG_MODE variable for the test suite, it does not set the environment variable.  It is the environment variable that changes the behavior of the logger.

Agreed!
(And looking at windows_c1.ps1 I see how the tests are run.)

@misl6  Requested changes have been made, and a test has been added.
@Julian-O Thanks for the assistance!


Fix parse_logs implementation

Not relevant after https://github.com/valory-xyz/open-autonomy/pull/1794


Install musl tools, rust, and libcnb-cargo prior to release

The release buildpack script is failing for rust based buildpacks: https://github.com/heroku/buildpacks-nodejs/actions/runs/1959345733.
We need to install musl-tools, rust, and libcnb-cargo so that we can build/release the libcnb-based buildpacks like heroku/nodejs-engine that was introduced in #184.
This code was lifted from https://github.com/heroku/buildpacks-jvm/blob/main/.github/workflows/release.yml#L31-L44
GUS-W-10729118

It worked: https://github.com/heroku/buildpacks-nodejs/actions/runs/1959502868


Meteor 3.0 support

Is there a plan to enable meteor 3.0 support for this package? Currently, an old blaze dependency is preventing the package from being used with meteor 3.0 alpha 19...
<EMAIL_ADDRESS>|| 2.1.4-beta.10 || 2.1.4-modules.0 <- gadicc:blaze-react-component 1.4.3
^^^ the blaze dependency in question

Will happily accept a PR for this 😅
On Thu, 14 Dec 2023, 01:07 Daniel Allman, @.***> wrote:

Is there a plan to enable meteor 3.0 support for this package? Currently,
an old blaze dependency is preventing the package from being used with
meteor 3.0 alpha 19...
@.*** || 2.1.4-beta.10 || 2.1.4-modules.0 <-
gadicc:blaze-react-component 1.4.3
^^^ the blaze dependency in question
—
Reply to this email directly, view it on GitHub
https://github.com/gadicc/meteor-blaze-react-component/issues/28, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAC5IGSDDHSX45WZDHRBJVTYJIYLNAVCNFSM6AAAAABAT536FWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA2DANRQGMYDENI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Clone API initial draft

@schristley any reason we don't merge this into master?

good to merge, we were just waiting for 1.3.1 to be released.

I believe 1.3.1 has been tagged and released, correct @javh

Yep. v1.3.1 has been tagged.


cli: unit tests for validation/utils.go and utils/utils.go

closes #70

Currently, LogCmdFlags and BindViperToCmdFlag are not being tested. Do you think it's worth it to introduce a mocking library to test this type of functions? We could test if they right methods are being called with given parameters
I was checking some libraries and found 2 good options: GoMock and testify


More precise install instructions

Patches / pull requests welcome :-)

@kinow This is a PR 😉

Looks good to me! Thanks for the update.

Oh, sorry @ZJvandeWeg I hadn't noticed it. And thanks @tylermauthe for merging :)


[KYUUBI #2850][FOLLOWUP] Fix default log4j2 configuration

Why are the changes needed?

Remove conf/log4j2.properties.template as it has been replaced by conf/log4j2.xml.template
Remove <ThresholdFilter level="FATAL"/> in default stdout appender.
How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[ ] Run test locally before make a pull request

Thanks, merging to master


describe should show int vs float, min, max etc

To display this in a sane way we might need to unnest for display ie
foo struct...
foo.bar int...

We should also have an option for "full scan",
ie describe full scan json ''
or describe json '' full scan


Update user guide for delete

Update user guide for delete

Codecov Report

Merging #27 (3bea01f) into master (482eb68) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #27   +/-   ##
=========================================
  Coverage     72.15%   72.15%
  Complexity      399      399
=========================================
  Files            70       70
  Lines          1232     1232
  Branches        125      125
=========================================
  Hits            889      889
  Misses          311      311
  Partials         32       32

Continue to review full report at Codecov.

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

Would it be possible to add back the deleted lines?

Added back.


OkHttp can't override Accept-Encoding

With the OKHttpBackend I can't override de Accept-Encoding it always defaults to GZIP and OkHttp supports brotli.
I think that the problem comes from this lines, in OkHttpBackend.scala:
request.headers
    .filterNot(h => h.is(HeaderNames.AcceptEncoding) || h.is(HeaderNames.ContentType))
    .foreach {
          case Header(name, value) => builder.addHeader(name, value)
    }

I can change it from the OkHttp Client

I will keep it reopen so we could improve user's experience here.

Done via #542


Crash on exit iOS application

iPhone 5( 32bit) - Godot version: 2.1.2
Crash on exit application in godot/servers/audio/audio_server_sw.cpp on line 774:
void AudioServerSW::_thread_func(void *self) {

	Thread::set_name("AudioServerSW");

	AudioServerSW *as=(AudioServerSW *)self;

	while (!as->exit_update_thread) {
		as->_update_streams(true);
		OS::get_singleton()->delay_usec(5000); <<--  Crash here
	}

}

Resume: OS::get_singleton() -- not thread save (maybe do "delay_usec" as static) and not correct finalize class.
In my case  OS::get_singleton() === NULL.

It seems to me that this can be the same issue as (see the last comment) https://github.com/godotengine/godot/issues/5426

It looks like the crash occurs in different places when exit the application. It looks like a memory leak somewhere. Only iOS version. It takes more time to search for a leak.

First of all thank you for your report and sorry for the delay.
We released Godot 3.0 in January 2018 after 18 months of work, fixing many old issues either directly, or by obsoleting/replacing the features they were referring to.
We still have hundreds of issues whose relevance/reproducibility needs to be checked against the current stable version, and that's where you can help us.
Could you check if the issue that you described initially is still relevant/reproducible in Godot 3.0 or any newer version, and comment about its current status here?
For bug reports, please also make sure that the issue contains detailed steps to reproduce the bug and, if possible, a zipped project that can be used to reproduce it right away. This greatly speeds up debugging and bugfixing tasks for our contributors.
Our Bugsquad will review this issue more in-depth in 15 days, and potentially close it if its relevance could not be confirmed.
Thanks in advance.
Note: This message is being copy-pasted to many "stale" issues (90+ days without activity). It might happen that it is not meaningful for this specific issue or appears oblivious of the issue's context, if so please comment to notify the Bugsquad about it.

I cannot test it in Godot 3.0 version, because in this case i must rewrite all project code for Godot 3.0, but it's cannot be done in this time point. Godot 3.0 is slower than 2.1.4 and I'm waiting 3.1 with Vulcan version. Android version (Adreno GPU) very slowely and crossplatform developing in this case breaked.

Oh ok I see. Will need to test in 3.1 in such case

Godot 3.1 will not have Vulkan support, you will have to wait for 3.2 for that.
You should update your project for Godot 3.x to confirm if the issue still exists. If Godot is slower for you then that's another issue that should be addressed. But if you are not willing to test it in the latest releases I'm not sure how much we can help you.
On a related note, do we want to keep supporting 32-bit iPhones? Apple killed off 32-bit iPhone apps this year with the release of iOS 11.

I have this issue in 3.1.  I've only recently gotten the error message after adding low processor mode.  I can look into this further but it might stem from there.

Did some tests and I discovered it was not due to the low processor mode but due to the ios13 beta.  When not on a beta firmware for iOS I'm not having any crashes on exit.

I just upgraded to official iOS 13. It crashed when killing the app.

2.1.2 only or 3.1.1 as well?

Godot 3.1.1
Previously, I tested on my iPad (with iOS 13 beta). It crashed when killing the app but it works fine on my iPhone iOS 12. After upgrading my iPhone to official iOS 13, I receive the same crash. :)
Noticed that when I just open the app, at the home screen, killing it has no crash. But when I open the app then change to another screen. Then it crashed when I kill the app.

According to the verge (https://www.theverge.com/2019/9/19/20874293/apple-ios-13-1-ipados-september-24th-early-release-date-update-bug-fixes-features) ios 13.1 will be out on the 24th.  This bug doesn't exist on the 13.1 beta that I'm currently in but did in a previous 13 beta.  Maybe the issue will be patched in 13.1?
"More importantly, Apple promises that 13.1 will bring general bug fixes to iOS 13, which the current software could definitely benefit from. (Our review of the current 13.0 software notes a litany of issues we encountered while testing the new update.)"

I just follow #32194 to remove both [self drawView] in layoutSubviews  and recompile for v3.1. After that, there is no crash when app enter background or terminate the app.

Godot 3.1.1
Confirmed crashes on iOS 13.0 simulator and 13.1 iPhone XR when switching the game to the background (press device Home button). GLES2/GLES3 driver same. Crash logs attached.
Cannot reproduce on previous iOS versions.
gles2.txt
gles3.txt

Follow #32194 remove [self drawView] in layoutSubviews and re-compile can fix crashes when switching to the background (press Home button), but it still crashes when closing in the app switcher.

Hi all. I removed duplicated drawView and moving this part of code
from
- (void)drawView {
	if (useCADisplayLink) {
		// Pause the CADisplayLink to avoid recursion
		[displayLink setPaused:YES];

		// Process all input events
		while (CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.01, TRUE) == kCFRunLoopRunHandledSource)
			;

		// We are good to go, resume the CADisplayLink
		[displayLink setPaused:NO];
	}

	if (!active) {
		printf("draw view not active!\n");
		return;
	};

to
- (void)drawView {

	if (!active) {
		printf("draw view not active!\n");
		return;
	};

	if (useCADisplayLink) {
		// Pause the CADisplayLink to avoid recursion
		[displayLink setPaused:YES];

		// Process all input events
		while (CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.01, TRUE) == kCFRunLoopRunHandledSource)
			;

		// We are good to go, resume the CADisplayLink
		[displayLink setPaused:NO];
	}

And crashes is gone. Tested many time and not catched yet.

@ealataur would you make a PR? 😄

@ealataur could you post your diff? This is a major problem for all iOS apps made with Godot.
Not fixed in the published 3.2 alpha 3 export template.

@gerald1248
This patch for 3.1.1 stable [66baa3b63]
patch.diff.zip

@ealataur awesome, thanks!

@ealataur can confirm your patch fixes the issue. Uploading to  App Store Connect now. Thanks again! (BTW I could swear I see dropped frames where previously I didn't. Am I missing optimisation flags I should pass to scons when compiling? I simply used scons p=iphone tools=no target=release arch=x86_64 and the matching 32-bit variant before creating the universal library.)

A pull request would be welcome so that we can review and hopefully merge the fix.

I created a pull request
https://github.com/godotengine/godot/pull/33154

@ealataur I have rebuilt using optimize=speed but I still observe a serious performance degradation. Happy to believe that I'm not building for iOS correctly, but do you think it's worth checking if the modified CFRunLoopRunInMode call has an impact on frame rate?

@gerald1248
please try change back this
while (CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.01, TRUE) == kCFRunLoopRunHandledSource)
to this
while (CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.0, TRUE) == kCFRunLoopRunHandledSource)

I don't have measurements, but switching back seems to have brought
performance back to a normal level.
On Wed, 30 Oct 2019, 09:21 Max Pestov<EMAIL_ADDRESS>wrote:

@gerald1248 https://github.com/gerald1248
please try change back this
while (CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.01, TRUE) ==
kCFRunLoopRunHandledSource)
to this
while (CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.0, TRUE) ==
kCFRunLoopRunHandledSource)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7966?email_source=notifications&email_token=AAFWFQBYJDXXNYKZTBVLM73QRFGZLA5CNFSM4DCPOT32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECTON6Q#issuecomment-547809018,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFWFQCE5XFYLT2GYVLG6JTQRFGZLANCNFSM4DCPOT3Q
.

@gerald1248
Ok. I will make a commit and pull request

@gerald1248
Ok. I will make a commit and pull request

I have this problem with my game. Is this fix on version 3.2 stable? or do I have to recompile from the latest master? (I actually tried, but the export templates I got gave me errors when exporting).
@ealataur can you please share which export templates you used after you recompiled godot with the fix?

Use one of the later betas: I'm using 3.2b3 and it works fine. Avoid
3.2b1-2 as performance was much worse then. The betas are useful as they
come with precompiled templates.
On Mon, 30 Dec 2019, 05:22 jeudy-ua<EMAIL_ADDRESS>wrote:

@gerald1248 https://github.com/gerald1248
Ok. I will make a commit and pull request
I have this problem with my game. Is this fix on version 3.2 stable? or do
I have to recompile from the latest master? (I actually tried, but the
export templates I got gave me errors when exporting).
@ealataur https://github.com/ealataur can you please share which export
templates you used after you recompiled godot with the fix?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7966?email_source=notifications&email_token=AAFWFQGABAG3YVEOHAOIJSDQ3GAR3A5CNFSM4DCPOT32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHZTMFQ#issuecomment-569587222,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFWFQCLZGDHZIW3QVLHBC3Q3GAR3ANCNFSM4DCPOT3Q
.


Bugfix/107

@praveenweb any update on this?

@kpalatzky - Hi, thanks for the PR. Will review in a bit 👍


Uundo and redo

In undo an redo onchange event not working; Is possible to get all changes of table in one array?

This feature is available in the new version 1.3.0 available in a different
repository. (beta testing)
On Fri, Sep 8, 2017 at 10:22 PM, cevc96<EMAIL_ADDRESS>wrote:

In undo an redo onchange event not working; Is possible to get all changes
of table in one array?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/paulhodel/jexcel/issues/35, or mute the thread
https://github.com/notifications/unsubscribe-auth/AFvagc1Uc-DiILITQ7T-P6e3EYC61tJCks5sgbAqgaJpZM4PRtRt
.

I saw that you update the repository, can i see this feature?, that really help me so much.
Thanks

bossanova.uk/jexcel
On Mon, Sep 11, 2017 at 8:06 PM, cevc96<EMAIL_ADDRESS>wrote:

I saw that you update the repository, can i see this feature?, that really
help me so much.
Thanks
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/paulhodel/jexcel/issues/35#issuecomment-328628047,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFvagXvZUhJpMbkr-bp5DmgOoaZ6RVw5ks5shYSvgaJpZM4PRtRt
.


Update last few projects to target netcoreapp3.0

#3754
remove #if's for multi-targeting where source is never multi-targeted

:up::date: to revert changes to a few classes


Milvus - update object type in fromTexts method

update object type of dbConfig in fromTexts method, so will be consistent where dbConfig defined.

Good catch, thank you!


Numbering starts from 2

I checked in my bot and the gif in the README as well. In both, the numbering of the Cogs starts from 2 only.
Is this intentional or a known bug?

https://github.com/stroupbslayen/discord-pretty-help/issues/34


Fix WQ "Withered Wrangling: Meredil and Ambervale" in suramar

When player has accomplish some quest in suramar, he gets the spell "Branch of the Arcan'dor" instead of "Spellstone of Kel'danath" and the WQ don't work anymore
See: http://www.wowhead.com/spell=223826/branch-of-the-arcandor#comments:id=2360213

Well, the profile is simply not coded good enough.
Add ScriptObjective for the version without the quest 40125 done.
And the one with the quest 40125 completed.
return Quest.GetQuestCompleted(40125);

I will do the change next time I get the WQ

You'll need to active the button with a LUA RunMacroText then InteractWith.
Note that you can also uses a custom Script to do an objective even if I don't really like it.

I found something working. "UseSpellAOE"
Need someone without the quest completed to test.

It wont work if it's an ExtraActionButton1.
You better use the action button then target it with UseSpellAoE later. (with a spell that wont cancel the AoE)

I need someone without the quest completed to test this.
WIth the quest completed it works well


Popup module retains last hanzi

Popup module retains the last hanzi even after its closed and a new is opened on mobile

needs screenshot


JFR report uploading failed

Please provide a brief summary of the bug
Getting the following error while using JFR in container logs
ERROR c.m.a.s.profiler.JfrUploadService - Failed to upload file
io.netty.handler.ssl.SslHandshakeTimeoutException: handshake timed out after 10000ms
at io.netty.handler.ssl.SslHandler$7.run(SslHandler.java:2113)
at io.netty.util.concurrent.PromiseTask.runTask(PromiseTask.java:98)
at io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:170)
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:469)
at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:391)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Unknown Source)
Please provide steps to reproduce where possible
Use base image
https://hub.docker.com/layers/eclipse-temurin/library/eclipse-temurin/11-jre/images/sha256-f8971fd7d202674e80743b5591e88bce60f10e02c8f69fcec3776b1b99a5f660?context=explore
Expected Results
No error
Actual Results
Failed to upload jfr report
What Java Version are you using?
openjdk 11
What is your operating system and platform?
linux/amd64
How did you install Java?
used base image --> https://hub.docker.com/layers/eclipse-temurin/library/eclipse-temurin/11-jre/images/sha256-f8971fd7d202674e80743b5591e88bce60f10e02c8f69fcec3776b1b99a5f660?context=explore
Did it work before?
NA

Did you test with other Java versions?
Strangely it worked when I use
eclipse-temurin:11-jre-focal

Relevant log output
No response

@Sachin1O1 This sounds like a a change with the set of SSL certs that are part of 11.0.16 JRE bundle and/or the O/S.  Are you able to share the certififcate chain you are using (public info only)

Can you give me more clarity on the certificate chain that you are asking to share? And moreover, I guess its the issue with the SSL certificates of image itself as I mentioned above it works smoothly on eclipse-temurin:11-jre-focal but not on eclipse-temurin:11-jre

Can you try sudo apt-get install ca-certificates -y in the container and see if it works after that?

Hi @karianna,
I used the above command in the docker file just after the base image and no lock. Getting same error in logs.
ERROR c.m.a.s.profiler.JfrUploadService - Failed to upload file io.netty.handler.ssl.SslHandshakeTimeoutException: handshake timed out after 10000ms 	at io.netty.handler.ssl.SslHandler$7.run(SslHandler.java:2113) 	at io.netty.util.concurrent.PromiseTask.runTask(PromiseTask.java:98) 	at io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:170) 	at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164) 	at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:469) 	at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:391) 	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986) 	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) 	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) 	at java.base/java.lang.Thread.run(Unknown Source)

@Sachin1O1 this is caused by https://github.com/netty/netty/issues/12343
Fixing this requires Application Insights bumping the netty dependencies to 4.1.77+, this has already been committed and will go out in the next release.

(@Sachin1O1 if you are able, can you try with the latest Application Insights snapshot build? https://github.com/microsoft/ApplicationInsights-Java/suites/7822243872/artifacts/330538498)


All tenants see all devices

No matter what tenant adds devices, when logged in all devices are shown

what version are you running?

Wasn't sure so i upgraded to latest version and it seems fine now. Thanks


Doc: Fix GitHub link navigation

A lot of links didn't have .md behind them so navigation didn't work in GitHub.
I think I have changed all of them.

The reason for that is it would destroy browsing on our website. While the thought is appreciated, the majority of current documentation is preferred to be browsed there instead of directly from the repository, so the links will remain as is.

I am going to re-open this, since it is not going to break the website.
For example, the homepage uses links that ends with .md and it still work. The reason is because the page builder is smart enough to detect .md and converts it into .htm.

Yeah I did notice that the page builder did work correctly because there were already links with .md and they worked. If there's a link broken it could be that I made a typo I haven't tested all the link changes. :)


what does "resolution" mean

convert probabilities to cumulative integer frequency table
cumFreq = prob_to_cum_freq(prob, resolution=128)
resolution = 128, what does it mean?

A range coder represents probabilities using integer intervals. So, e.g., probabilities [0.1, 0.25, 0.65] correspond to a CDF of [0.0, 0.1, 0.35, 1.0] and would be represented as [0, 20, 70, 200] if the resolution was 200. If the resolution is 128, the smallest probability that can be represented is 1/128.


fix $fpath some time has double slash ending

For example:
/Users/user/.antigen/repos/https-COLON--SLASH--SLASH-github.com-SLASH-zsh-users-SLASH-zsh-syntax-highlighting.git//

loc is an argument that defaults to "/" and it can naturally be overwritten. So, removing it will break things.
If you feel the need to remove the extra slash then you should check if the value is "/" and if it isn't then append it, otherwise do not:
 if [ "$loc" == "/" ]; then
     loc=""
 fi

 if $make_local_clone; then
     location="$(-antigen-get-clone-dir "$url")/$loc"
 else
     location="$url/$loc"
 fi

@desyncr

Your idea is
empty the `$loc` if it is a slash, then append it to `$location`

My idea is
if the `$loc` is a slash, then do not append it to `$location`

I think we will get the same result, isn't it? :)

Oh, yeah, my bad. For some reason I didn't saw line 268 :+1:

Thank you and sorry for the delay :)

@sharat87 :)


Stuck scrollbar on webkit, maybe an issue due to 2k resolution

Issue summary
Scrollbar get stuck when I scroll down after have scrolled to top
Expected behavior
Scrolling should work correctly using the mouse scroll
Actual behavior
Scrollbar get stuck using the mouse scroll
Steps to reproduce

Send some commands in any jQuery terminal instance
Scroll to top using the mouse
Scroll to down using the mouse
Scrollbar get stuck (it scrolls a little but then rip)

(I can still scroll dragging the scroll thumb)
Browser and OS
Chrome 85 and Brave with Chromium 84 on Linux @ 2560x1440
On Firefox it works correctly

It work for me on linux. Do you use mousewheel plugin, I've stopped using it long ago, but it should not change anything it just don't needed?
Can you provide demo where this is visible, maybe full screen example that is included with the library or do it need something extra.

I was checking your website with full screen console and it works fine, but I only have FullHD screen but resolution should not matter.

Hey jcubic, thank you for the reply.
I can reproduce this issue on every instance, also on terminal.jcubic.pl
I'm not using the mousewheel plugin, anyway I just tried @ 1920x1080 and the problem persists... dunno.
I'll post here if I find more about this issue

Maybe you have an error in JavaScript console, maybe other part of the code stopped JS to execute or maybe there is other code that use mousewheel and that interfere. Does the app use just the terminal full screen or in window with other code?

I specify that the problem happens only when the scrollbar is visible and I reached the top of the terminal.
I can reproduce it also on https://terminal.jcubic.pl/#demo
Sometimes an error appears in the demo but it doesn't seem to be related to the scroll problem
https://www.youtube.com/watch?v=xAmwYHepXso

You some how make terminal throw internal error, did you modified $.terminal.defaults.formatters. Do you do something in console. can you copy paste what did you typed to the terminal?

Ok I got the exception, will investigate, when I fix the error we need test again the scroll issue.

Can you test again on the terminal website have few bugs, I accidentaly deployed src version and didn't update the demo code after 2.18.0. It was small change in the API but it make my demo broke.

Yes, the problem persists. The throwed error that you see in the video isn't related at all, because the scroll issue that starts from 0:15 happens also on my website and elsewhere.
(video is uncut and the error has been recorded because occurred after a focus out)

Sorry I cannot reproduce it, can you tell me exact steps, maybe you do some kind any clicks or keystrokes. The only issue I see is that the page scroll down when there are no scrollbar when I press enter.

I have to try on some other devices.
The only thing that is changed here over time is my monitor.
I thought it was responsible for this bug, but I can't confirm it.
Anyway, to reproduce this bug on my computer:

I send random commands to make the scrollbar appears
I send other commands just for spacing a bit more
I scroll to the top
Now I'm stuck at the top like in the video @ 0:15
I can back to the terminal input by pressing "enter"

Do you have anything in the console after that exception go away? You can try to debug it in the browser.
Try adding break point in this line:
                function mousewheel(event, delta) {
                    if (!shift) {

The only idea I have is that shift is true don't change, this is something I was not able to make to work, but the code is there. I wanted the shift to disable the mousewheel so you can scroll whole page instead of the terminal.

Console is ok, anyway no problem it's just a minor issue.
It fixes itself by pressing enter, dragging the scrollbar or (on some instances) clicking on the terminal.
I tried keeping the shift key pressed and mousewheel stops, but then the problem persists.
I'll investigate more (also on Windows and with other pc).


Update jsoniter-scala-core, ... to 2.13.35

Updates

com.github.plokhotnyuk.jsoniter-scala:jsoniter-scala-core
com.github.plokhotnyuk.jsoniter-scala:jsoniter-scala-macros

from 2.13.17 to 2.13.35.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.github.plokhotnyuk.jsoniter-scala" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "com.github.plokhotnyuk.jsoniter-scala" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #297.


can i post instagram reels with instapy? [F+]

You can't post anything with instapy, rn. See the other issues. IG API has changed, not this code base.
Posting on IG with this solution is no longer possible atm.


Add 1559 transaction support to 1.5 translator

Created a small test for this on tevmc repo and passed it to @tomtomcrypto who is handling the rpc integration


consensys.net -> consensys.io

Hi @kevin-chassagne ,
The consensys.io is currently not having trailing slash enabled. Some of the links with trailing slash may work, since I have manually added redirect rules during our migration from consensys.net. The majority of pages originated from consensys.io do not support trailing slash. Please check the sitemap to ensure we use the correct url.

Hi @Kevin,
Excellent!!


By default, return float64, but provide options for reading different formats.

I think it's a good idea to return np.float32 by default (although I'm not 100% sure because the default type in NumPy is np.float64).
If the file has 64bit values, however, they shouldn't be truncated by default.
So probably the default argument to read() should be format=None which should be changed appropriately within the function.
BTW, format may not be the best name choice for this parameter, maybe dtype would be rather what people would expect?

What, then, is the proposed way to discover and load the native format? I am moving audio from a file system to a database and would like to store them in their native resolution.

Essentially, check the subtype manually, then read with a matching dtype.

Is there a function available for this manual check? Or do I need to inspect the header directly? Or use python's built-in io.wave package?

subtype is a property of soundfile.SoundFile and can have any value of soundfile._subtypes.


Generate examples int README.md with code

I want to verify that the examples are valid and up to date

Codecov Report
Attention: Patch coverage is 0% with 2 lines in your changes missing coverage. Please review.

Project coverage is 44.57%. Comparing base (270aed5) to head (81709ce).

Files with missing lines
Patch %
Lines

pkg/dto/restore_request.go
0.00%
2 Missing :warning:

Additional details and impacted files
@@           Coverage Diff           @@
##               v2     #289   +/-   ##
=======================================
  Coverage   44.57%   44.57%
=======================================
  Files          51       51
  Lines        2809     2809
=======================================
  Hits         1252     1252
  Misses       1432     1432
  Partials      125      125

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.