text:
vagrant@127.0.0.1: Permission denied (publickey)

Platform: Windows 11, AMD64
Git Bash CLI
To get Vagrant to use the included SSH instead of Window's version:
$ export VAGRANT_PREFER_SYSTEM_BIN="0" && echo $VAGRANT_PREFER_SYSTEM_BIN 0
The error appears at the end of this report. What may be related are these lines earlier in execution:
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...

The whole execution log:
Thomas@Sammy MINGW64 ~/development/rpi-cloud-init (main)
$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'ubuntu/focal64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ubuntu/focal64' version '20230215.0.0' is up to date...
==> default: Setting the name of the VM: rpi-cloud-init_default_1698610755247_31594
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection reset. Retrying...
    default: Warning: Connection aborted. Retrying...
    default:
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
    default: The guest additions on this VM do not match the installed version of
    default: VirtualBox! In most cases this is fine, but in rare cases it can
    default: prevent things such as shared folders from working properly. If you see
    default: shared folder errors, please make sure the guest additions within the
    default: virtual machine match the version of VirtualBox you have installed on
    default: your host and reload your VM.
    default:
    default: Guest Additions Version: 6.1.38
    default: VirtualBox Version: 7.0
==> default: Mounting shared folders...
    default: /vagrant => C:/Users/Thomas/Development/rpi-cloud-init
==> default: Running provisioner: shell...
    default: Running: inline script
    default: Downloading package https://github.com/jsiebens/hashi-up/releases/download/v0.16.0/hashi-up as /tmp/hashi-up
    default: Download complete.
    default:
    default: Running with sufficient permissions to attempt to move hashi-up to /usr/local/bin
    default: New version of hashi-up installed to /usr/local/bin
    default: Version: 0.16.0
    default: Git Commit: b062f5d
    default: Downloading file https://releases.hashicorp.com/packer/1.9.4/packer_1.9.4_linux_amd64.zip
    default: Extracting file: packer to /usr/local/bin
    default: 534.18 KiB / 21.96 MiB [->___________________________________________________________________] 2.38%1.49 MiB / 21.96 MiB [---->__________________________________________________________________] 6.79%2.15 MiB / 21.96 MiB [------>________________________________________________________________] 9.78%3.33 MiB / 21.96 MiB [---------->___________________________________________________________] 15.19%4.58 MiB / 21.96 MiB [-------------->_______________________________________________________] 20.88%5.27 MiB / 21.96 MiB [---------------->_____________________________________________________] 24.01%6.26 MiB / 21.96 MiB [------------------->__________________________________________________] 28.49%7.04 MiB / 21.96 MiB [---------------------->_______________________________________________] 32.05%7.57 MiB / 21.96 MiB [------------------------>_____________________________________________] 34.47%8.19 MiB / 21.96 MiB [-------------------------->___________________________________________] 37.32%8.88 MiB / 21.96 MiB [---------------------------->_________________________________________] 40.45%10.51 MiB / 21.96 MiB [--------------------------------->___________________________________] 47.85%11.52 MiB / 21.96 MiB [------------------------------------>________________________________] 52.48%12.57 MiB / 21.96 MiB [--------------------------------------->_____________________________] 57.25%13.71 MiB / 21.96 MiB [------------------------------------------->_________________________] 62.44%14.63 MiB / 21.96 MiB [--------------------------------------------->_______________________] 66.64%15.43 MiB / 21.96 MiB [------------------------------------------------>____________________] 70.27%16.33 MiB / 21.96 MiB [--------------------------------------------------->_________________] 74.40%17.33 MiB / 21.96 MiB [------------------------------------------------------>______________] 78.95%18.27 MiB / 21.96 MiB [--------------------------------------------------------->___________] 83.22%19.21 MiB / 21.96 MiB [------------------------------------------------------------>________] 87.49%19.82 MiB / 21.96 MiB [-------------------------------------------------------------->______] 90.27%20.57 MiB / 21.96 MiB [---------------------------------------------------------------->____] 93.68%21.52 MiB / 21.96 MiB [------------------------------------------------------------------->_] 98.02%21.96 MiB / 21.96 MiB [--------------------------------------------------------------------] 100.00%

Thomas@Sammy MINGW64 ~/development/rpi-cloud-init (main)
$ vagrant ssh
vagrant@127.0.0.1: Permission denied (publickey).

Thomas@Sammy MINGW64 ~/development/rpi-cloud-init (main)
$ vagrant ssh --debug
' INFO global: Vagrant version: 2.4.0
 INFO global: Ruby version: 3.1.3
 INFO global: RubyGems version: 3.3.26
 INFO global: VAGRANT_EXECUTABLE="C:\\Program Files\\Vagrant\\embedded\\gems\\gems\\vagrant-2.4.0\\bin\\vagrant"
 INFO global: VAGRANT_INSTALLER_EMBEDDED_DIR="C:\\Program Files\\Vagrant\\embedded"
 INFO global: VAGRANT_INSTALLER_ENV="1"
 INFO global: VAGRANT_INSTALLER_VERSION="2"
 INFO global: VAGRANT_LOG="debug"
 INFO global: VAGRANT_PREFER_SYSTEM_BIN="0"
DEBUG global: vagrant ssl helper found for loading ssl providers
DEBUG global: ssl providers successfully loaded
 WARN global: resolv replacement has not been enabled!
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/autocomplete/plugin.rb
 INFO manager: Registered plugin: autocomplete command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/box/plugin.rb
 INFO manager: Registered plugin: box command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/cap/plugin.rb
 INFO manager: Registered plugin: cap command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/cloud/plugin.rb
 INFO manager: Registered plugin: vagrant-cloud
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/destroy/plugin.rb
 INFO manager: Registered plugin: destroy command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/global-status/plugin.rb
 INFO manager: Registered plugin: global-status command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/halt/plugin.rb
 INFO manager: Registered plugin: halt command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/help/plugin.rb
 INFO manager: Registered plugin: help command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/init/plugin.rb
 INFO manager: Registered plugin: init command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/list-commands/plugin.rb
 INFO manager: Registered plugin: list-commands command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/login/plugin.rb
 INFO manager: Registered plugin: vagrant-login
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/package/plugin.rb
 INFO manager: Registered plugin: package command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/plugin/plugin.rb
 INFO manager: Registered plugin: plugin command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/port/plugin.rb
 INFO manager: Registered plugin: port command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/powershell/plugin.rb
 INFO manager: Registered plugin: powershell command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/provider/plugin.rb
 INFO manager: Registered plugin: provider command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/provision/plugin.rb
 INFO manager: Registered plugin: provision command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/push/plugin.rb
 INFO manager: Registered plugin: push command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/rdp/plugin.rb
 INFO manager: Registered plugin: rdp command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/reload/plugin.rb
 INFO manager: Registered plugin: reload command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/resume/plugin.rb
 INFO manager: Registered plugin: resume command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/serve/plugin.rb
 INFO manager: Registered plugin: start Vagrant server
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/snapshot/plugin.rb
 INFO manager: Registered plugin: snapshot command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/ssh/plugin.rb
 INFO manager: Registered plugin: ssh command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/ssh_config/plugin.rb
 INFO manager: Registered plugin: ssh-config command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/status/plugin.rb
 INFO manager: Registered plugin: status command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/suspend/plugin.rb
 INFO manager: Registered plugin: suspend command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/up/plugin.rb
 INFO manager: Registered plugin: up command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/upload/plugin.rb
 INFO manager: Registered plugin: upload command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/validate/plugin.rb
 INFO manager: Registered plugin: validate command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/version/plugin.rb
 INFO manager: Registered plugin: version command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/winrm/plugin.rb
 INFO manager: Registered plugin: winrm command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/commands/winrm_config/plugin.rb
 INFO manager: Registered plugin: winrm-config command
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/communicators/ssh/plugin.rb
 INFO manager: Registered plugin: ssh communicator
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/communicators/winrm/plugin.rb
 INFO manager: Registered plugin: winrm communicator
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/communicators/winssh/plugin.rb
 INFO manager: Registered plugin: windows ssh communicator
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/alma/plugin.rb
 INFO manager: Registered plugin: Alma guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/alpine/plugin.rb
 INFO manager: Registered plugin: Alpine guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/alt/plugin.rb
 INFO manager: Registered plugin: ALT Platform guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/amazon/plugin.rb
 INFO manager: Registered plugin: Amazon Linux guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/arch/plugin.rb
 INFO manager: Registered plugin: Arch guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/atomic/plugin.rb
 INFO manager: Registered plugin: Atomic Host guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/bsd/plugin.rb
 INFO manager: Registered plugin: BSD-based guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/centos/plugin.rb
 INFO manager: Registered plugin: CentOS guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/coreos/plugin.rb
 INFO manager: Registered plugin: CoreOS guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/darwin/plugin.rb
 INFO manager: Registered plugin: Darwin guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/debian/plugin.rb
 INFO manager: Registered plugin: Debian guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/dragonflybsd/plugin.rb
 INFO manager: Registered plugin: DragonFly BSD guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/elementary/plugin.rb
 INFO manager: Registered plugin: Elementary guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/esxi/plugin.rb
 INFO manager: Registered plugin: ESXi guest.
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/fedora/plugin.rb
 INFO manager: Registered plugin: Fedora guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/freebsd/plugin.rb
 INFO manager: Registered plugin: FreeBSD guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/funtoo/plugin.rb
 INFO manager: Registered plugin: Funtoo guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/gentoo/plugin.rb
 INFO manager: Registered plugin: Gentoo guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/haiku/plugin.rb
 INFO manager: Registered plugin: Haiku guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/kali/plugin.rb
 INFO manager: Registered plugin: Kali guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/linux/plugin.rb
 INFO manager: Registered plugin: Linux guest.
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/mint/plugin.rb
 INFO manager: Registered plugin: Mint guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/netbsd/plugin.rb
 INFO manager: Registered plugin: NetBSD guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/nixos/plugin.rb
 INFO manager: Registered plugin: NixOS guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/omnios/plugin.rb
 INFO manager: Registered plugin: OmniOS guest.
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/openbsd/plugin.rb
 INFO manager: Registered plugin: OpenBSD guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/openwrt/plugin.rb
 INFO manager: Registered plugin: OpenWrt guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/photon/plugin.rb
 INFO manager: Registered plugin: VMware Photon guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/pld/plugin.rb
 INFO manager: Registered plugin: PLD Linux guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/redhat/plugin.rb
 INFO manager: Registered plugin: Red Hat Enterprise Linux guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/rocky/plugin.rb
 INFO manager: Registered plugin: Rocky guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/slackware/plugin.rb
 INFO manager: Registered plugin: Slackware guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/smartos/plugin.rb
 INFO manager: Registered plugin: SmartOS guest.
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/solaris/plugin.rb
 INFO manager: Registered plugin: Solaris guest.
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/solaris11/plugin.rb
 INFO manager: Registered plugin: Solaris 11 guest.
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/suse/plugin.rb
 INFO manager: Registered plugin: SUSE guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/tinycore/plugin.rb
 INFO manager: Registered plugin: TinyCore Linux guest.
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/trisquel/plugin.rb
 INFO manager: Registered plugin: Trisquel guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/ubuntu/plugin.rb
 INFO manager: Registered plugin: Ubuntu guest
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/guests/windows/plugin.rb
 INFO manager: Registered plugin: Windows guest.
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/hosts/alt/plugin.rb
 INFO manager: Registered plugin: ALT Platform host
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/hosts/arch/plugin.rb
 INFO manager: Registered plugin: Arch host
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/hosts/bsd/plugin.rb
 INFO manager: Registered plugin: BSD host
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/hosts/darwin/plugin.rb
 INFO manager: Registered plugin: Mac OS X host
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/hosts/freebsd/plugin.rb
 INFO manager: Registered plugin: FreeBSD host
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/hosts/gentoo/plugin.rb
 INFO manager: Registered plugin: Gentoo host
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/hosts/linux/plugin.rb
 INFO manager: Registered plugin: Linux host
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/hosts/null/plugin.rb
 INFO manager: Registered plugin: null host
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/hosts/redhat/plugin.rb
 INFO manager: Registered plugin: Red Hat Enterprise Linux host
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/hosts/slackware/plugin.rb
 INFO manager: Registered plugin: Slackware host
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/hosts/suse/plugin.rb
 INFO manager: Registered plugin: SUSE host
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/hosts/void/plugin.rb
 INFO manager: Registered plugin: Void host
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/hosts/windows/plugin.rb
 INFO manager: Registered plugin: Windows host
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/kernel_v1/plugin.rb
 INFO manager: Registered plugin: kernel
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/kernel_v2/plugin.rb
 INFO manager: Registered plugin: kernel
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/providers/docker/plugin.rb
 INFO manager: Registered plugin: docker-provider
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/providers/hyperv/plugin.rb
 INFO manager: Registered plugin: Hyper-V provider
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/providers/virtualbox/plugin.rb
 INFO manager: Registered plugin: VirtualBox provider
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/provisioners/ansible/plugin.rb
 INFO manager: Registered plugin: ansible
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/provisioners/cfengine/plugin.rb
 INFO manager: Registered plugin: CFEngine Provisioner
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/provisioners/chef/plugin.rb
 INFO manager: Registered plugin: chef
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/provisioners/container/plugin.rb
 INFO manager: Registered plugin: container
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/provisioners/docker/plugin.rb
 INFO manager: Registered plugin: docker
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/provisioners/file/plugin.rb
 INFO manager: Registered plugin: file
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/provisioners/podman/plugin.rb
 INFO manager: Registered plugin: podman
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/provisioners/puppet/plugin.rb
 INFO manager: Registered plugin: puppet
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/provisioners/salt/plugin.rb
 INFO manager: Registered plugin: salt
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/provisioners/shell/plugin.rb
 INFO manager: Registered plugin: shell
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/pushes/atlas/plugin.rb
 INFO manager: Registered plugin: atlas
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/pushes/ftp/plugin.rb
 INFO manager: Registered plugin: ftp
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/pushes/heroku/plugin.rb
 INFO manager: Registered plugin: heroku
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/pushes/local-exec/plugin.rb
 INFO manager: Registered plugin: local-exec
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/pushes/noop/plugin.rb
 INFO manager: Registered plugin: noop
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/synced_folders/nfs/plugin.rb
 INFO manager: Registered plugin: NFS synced folders
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/synced_folders/rsync/plugin.rb
 INFO manager: Registered plugin: RSync synced folders
DEBUG global: Loading core plugin: C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/synced_folders/smb/plugin.rb
 INFO manager: Registered plugin: SMB synced folders
 INFO vagrant: `vagrant` invoked: ["ssh", "--debug"]
DEBUG vagrant: Creating Vagrant environment
 INFO environment: Environment initialized (#<Vagrant::Environment:0x0000024a9d3fa900>)
 INFO environment:   - cwd: C:/Users/Thomas/development/rpi-cloud-init
 INFO environment: Home path: C:/Users/Thomas/.vagrant.d
DEBUG environment: Effective local data path: C:/Users/Thomas/development/rpi-cloud-init/.vagrant
 INFO environment: Local data path: C:/Users/Thomas/development/rpi-cloud-init/.vagrant
DEBUG environment: Creating: C:/Users/Thomas/development/rpi-cloud-init/.vagrant
DEBUG manager: Enabling localized plugins
 INFO manager: Plugins:
DEBUG solution_file: new solution file instance plugin_file=C:/Users/Thomas/development/rpi-cloud-init/.vagrant/plugins.json solution_file=C:/Users/Thomas/development/rpi-cloud-init/.vagrant/bundler/local.sol
DEBUG solution_file: missing file so skipping loading
DEBUG bundler: solution file in use for init: <Vagrant::Bundler::SolutionFile:C:/Users/Thomas/development/rpi-cloud-init/.vagrant/plugins.json:C:/Users/Thomas/development/rpi-cloud-init/.vagrant/bundler/local.sol:invalid>
DEBUG bundler: Generating new builtin set instance.
DEBUG bundler: Generating new plugin set instance. Skip gems - []
DEBUG bundler: generating solution set for configured plugins
DEBUG bundler: Current generated plugin dependency list: []
DEBUG bundler: resolving solution from available specification set
DEBUG bundler: solution set for configured plugins has been resolved
DEBUG bundler: activating solution set
DEBUG bundler: Activating solution set: []
DEBUG solution_file: plugin file does not exist, not storing solution
DEBUG bundler: solution set stored to - <Vagrant::Bundler::SolutionFile:C:/Users/Thomas/development/rpi-cloud-init/.vagrant/plugins.json:C:/Users/Thomas/development/rpi-cloud-init/.vagrant/bundler/local.sol:invalid>
 INFO manager: Loading plugins...
DEBUG manager: Enabling globalized plugins
 INFO manager: Plugins:
DEBUG solution_file: new solution file instance plugin_file=C:/Users/Thomas/.vagrant.d/plugins.json solution_file=C:/Users/Thomas/development/rpi-cloud-init/.vagrant/bundler/global.sol
DEBUG solution_file: missing file so skipping loading
DEBUG bundler: solution file in use for init: <Vagrant::Bundler::SolutionFile:C:/Users/Thomas/.vagrant.d/plugins.json:C:/Users/Thomas/development/rpi-cloud-init/.vagrant/bundler/global.sol:invalid>
DEBUG bundler: Generating new builtin set instance.
DEBUG bundler: Generating new plugin set instance. Skip gems - []
DEBUG bundler: generating solution set for configured plugins
DEBUG bundler: Current generated plugin dependency list: []
DEBUG bundler: resolving solution from available specification set
DEBUG bundler: solution set for configured plugins has been resolved
DEBUG bundler: activating solution set
DEBUG bundler: Activating solution set: []
DEBUG solution_file: plugin file does not exist, not storing solution
DEBUG bundler: solution set stored to - <Vagrant::Bundler::SolutionFile:C:/Users/Thomas/.vagrant.d/plugins.json:C:/Users/Thomas/development/rpi-cloud-init/.vagrant/bundler/global.sol:invalid>
 INFO manager: Loading plugins...
 INFO loader: Set :root = ["#<Pathname:C:/Users/Thomas/development/rpi-cloud-init/Vagrantfile>"]
DEBUG loader: Populating proc cache for #<Pathname:C:/Users/Thomas/development/rpi-cloud-init/Vagrantfile>
DEBUG loader: Load procs for pathname: C:/Users/Thomas/development/rpi-cloud-init/Vagrantfile
 INFO loader: Loading configuration in order: [:home, :root]
DEBUG loader: Loading from: root (evaluating)
DEBUG provisioner: Provisioner defined:
DEBUG loader: Configuration loaded successfully, finalizing and returning
DEBUG push: finalizing
 INFO vmconfig: config class lookup for provider :virtualbox gave us base class: VagrantPlugins::ProviderVirtualBox::Config
 INFO subprocess: Starting process: ["C:\\Windows\\System32\\WindowsPowerShell\\v1.0/powershell.EXE", "-NoLogo", "-NoProfile", "-NonInteractive", "-ExecutionPolicy", "Bypass", "-Command", "Write-Output $PSVersionTable.PSVersion.Major"]
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 30
DEBUG subprocess: Exit status: 0
 INFO subprocess: Starting process: ["C:\\Windows\\System32\\WindowsPowerShell\\v1.0/powershell.EXE", "-NoLogo", "-NoProfile", "-NonInteractive", "-ExecutionPolicy", "Bypass", "-Command", "(new-object System.Security.Principal.WindowsPrincipal([System.Security.Principal.WindowsIdentity]::GetCurrent())).IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)"]
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 31999
DEBUG subprocess: Exit status: 0
 INFO subprocess: Starting process: ["C:\\Windows\\System32\\WindowsPowerShell\\v1.0/powershell.EXE", "-NoLogo", "-NoProfile", "-NonInteractive", "-ExecutionPolicy", "Bypass", "-Command", "Write-Output ([System.Security.Principal.WindowsIdentity]::GetCurrent().Groups | Select-Object Value | ConvertTo-JSON)"]
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
 INFO subprocess: Starting process: ["C:\\Windows\\System32\\WindowsPowerShell\\v1.0/powershell.EXE", "-NoLogo", "-NoProfile", "-NonInteractive", "-ExecutionPolicy", "Bypass", "-Command", "$x = (Get-VMHost).Name; if($x -eq [System.Net.Dns]::GetHostName()){ Write-Output 'true'}"]
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 1
DEBUG base: Windows, checking for VBoxManage on PATH first
DEBUG base: Windows. Trying VBOX_INSTALL_PATH for VBoxManage
DEBUG base: VBOX_INSTALL_PATH value: C:\Program Files\Oracle\VirtualBox\
 INFO base: VBoxManage path: C:/Program Files/Oracle/VirtualBox/VBoxManage.exe
DEBUG meta: validating LANG value for virtualbox cli commands
 INFO subprocess: Starting process: ["C:\\Program Files\\Vagrant\\embedded\\usr\\bin/locale.EXE", "-a"]
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
DEBUG meta: list of available C locales: ["C", "C.utf8", "POSIX", "en_US.utf8"]
DEBUG meta: valid variation found for LANG value: C.utf8
DEBUG meta: LANG value set: "C.utf8"
 INFO subprocess: Starting process: ["C:/Program Files/Oracle/VirtualBox/VBoxManage.exe", "--version"]
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
DEBUG meta: Finding driver for VirtualBox version: 7.0.12
 INFO meta: Using VirtualBox driver: VagrantPlugins::ProviderVirtualBox::Driver::Version_7_0
DEBUG base: Windows, checking for VBoxManage on PATH first
DEBUG base: Windows. Trying VBOX_INSTALL_PATH for VBoxManage
DEBUG base: VBOX_INSTALL_PATH value: C:\Program Files\Oracle\VirtualBox\
 INFO base: VBoxManage path: C:/Program Files/Oracle/VirtualBox/VBoxManage.exe
DEBUG environment: Initial usable provider list: [[6, :virtualbox]]
DEBUG environment: Priority sorted usable provider list: [:virtualbox]
DEBUG environment: Preferred provider list: []
DEBUG environment: Using provider `virtualbox` detected in configuration and usable.
 INFO loader: Set "920_machine_default" = []
 INFO loader: Loading configuration in order: [:home, :root, "920_machine_default"]
DEBUG loader: Loading from: root (cache)
DEBUG loader: Configuration loaded successfully, finalizing and returning
DEBUG push: finalizing
 INFO vmconfig: config class lookup for provider :virtualbox gave us base class: VagrantPlugins::ProviderVirtualBox::Config
 INFO box_collection: Box found: ubuntu/focal64 (virtualbox)
 INFO environment: Running hook: authenticate_box_url
 INFO host: Autodetecting host type for [#<Vagrant::Environment: C:/Users/Thomas/development/rpi-cloud-init>]
DEBUG host: Trying: alt
DEBUG host: Trying: arch
DEBUG host: Trying: darwin
DEBUG host: Trying: freebsd
DEBUG host: Trying: gentoo
DEBUG host: Trying: redhat
DEBUG host: Trying: slackware
DEBUG host: Trying: suse
DEBUG host: Trying: void
DEBUG host: Trying: bsd
DEBUG host: Trying: linux
DEBUG host: Trying: null
DEBUG host: Trying: windows
 INFO host: Detected: windows!
 INFO runner: Running action: authenticate_box_url #<Vagrant::Action::Builder:0x0000024a9d24c2e8>
 INFO warden: Calling IN action: #<VagrantPlugins::CloudCommand::AddAuthentication:0x0000024a9d8b4810>
 WARN authenticate-box-url: Authentication token not found as GET parameter.
 INFO warden: Calling OUT action: #<VagrantPlugins::CloudCommand::AddAuthentication:0x0000024a9d8b4810>
 INFO loader: Set :"1020_ubuntu/focal64_virtualbox" = ["#<Pathname:C:/Users/Thomas/.vagrant.d/boxes/ubuntu-VAGRANTSLASH-focal64/20230215.0.0/virtualbox/Vagrantfile>"]
DEBUG loader: Populating proc cache for #<Pathname:C:/Users/Thomas/.vagrant.d/boxes/ubuntu-VAGRANTSLASH-focal64/20230215.0.0/virtualbox/Vagrantfile>
DEBUG loader: Load procs for pathname: C:/Users/Thomas/.vagrant.d/boxes/ubuntu-VAGRANTSLASH-focal64/20230215.0.0/virtualbox/Vagrantfile
 INFO loader: Loading configuration in order: [:"1020_ubuntu/focal64_virtualbox", :home, :root, "920_machine_default"]
DEBUG loader: Loading from: 1020_ubuntu/focal64_virtualbox (evaluating)
DEBUG loader: Loading from: root (cache)
DEBUG loader: Configuration loaded successfully, finalizing and returning
DEBUG push: finalizing
 INFO vmconfig: config class lookup for provider :virtualbox gave us base class: VagrantPlugins::ProviderVirtualBox::Config
 INFO environment: Running hook: environment_plugins_loaded
 INFO runner: Running action: environment_plugins_loaded #<Vagrant::Action::Builder:0x0000024a9d170a68>
 INFO environment: Running hook: environment_load
 INFO runner: Running action: environment_load #<Vagrant::Action::Builder:0x0000024a9d4a1c78>
DEBUG checkpoint_client: starting plugin check
 INFO cli: CLI: [] "ssh" []
DEBUG checkpoint_client: plugin check complete
DEBUG cli: Invoking command class: VagrantPlugins::CommandSSH::Command []
DEBUG checkpoint_client: no information received from checkpoint
DEBUG command: Getting target VMs for command. Arguments:
DEBUG command:  -- names: []
DEBUG command:  -- options: {:single_target=>true}
 INFO command: getting active machines
DEBUG command: Loading all machines...
 INFO command: Active machine found with name default. Using provider: virtualbox
 INFO environment: Getting machine: default (virtualbox)
 INFO environment: Uncached load of machine.
DEBUG base: Windows, checking for VBoxManage on PATH first
DEBUG base: Windows. Trying VBOX_INSTALL_PATH for VBoxManage
DEBUG base: VBOX_INSTALL_PATH value: C:\Program Files\Oracle\VirtualBox\
 INFO base: VBoxManage path: C:/Program Files/Oracle/VirtualBox/VBoxManage.exe
DEBUG meta: Finding driver for VirtualBox version: 7.0.12
 INFO meta: Using VirtualBox driver: VagrantPlugins::ProviderVirtualBox::Driver::Version_7_0
DEBUG base: Windows, checking for VBoxManage on PATH first
DEBUG base: Windows. Trying VBOX_INSTALL_PATH for VBoxManage
DEBUG base: VBOX_INSTALL_PATH value: C:\Program Files\Oracle\VirtualBox\
 INFO base: VBoxManage path: C:/Program Files/Oracle/VirtualBox/VBoxManage.exe
 INFO loader: Set "920_machine_default" = []
 INFO loader: Loading configuration in order: [:home, :root, "920_machine_default"]
 WARN loader: Unknown config sources: [:"1020_ubuntu/focal64_virtualbox"]
DEBUG loader: Loading from: root (cache)
DEBUG loader: Configuration loaded successfully, finalizing and returning
DEBUG push: finalizing
 INFO vmconfig: config class lookup for provider :virtualbox gave us base class: VagrantPlugins::ProviderVirtualBox::Config
 INFO box_collection: Box found: ubuntu/focal64 (virtualbox)
 INFO environment: Running hook: authenticate_box_url
 INFO runner: Running action: authenticate_box_url #<Vagrant::Action::Builder:0x0000024a9db07158>
 INFO warden: Calling IN action: #<VagrantPlugins::CloudCommand::AddAuthentication:0x0000024a9dbb20d0>
 WARN authenticate-box-url: Authentication token not found as GET parameter.
 INFO warden: Calling OUT action: #<VagrantPlugins::CloudCommand::AddAuthentication:0x0000024a9dbb20d0>
 INFO loader: Set :"1020_ubuntu/focal64_virtualbox" = ["#<Pathname:C:/Users/Thomas/.vagrant.d/boxes/ubuntu-VAGRANTSLASH-focal64/20230215.0.0/virtualbox/Vagrantfile>"]
 INFO loader: Loading configuration in order: [:"1020_ubuntu/focal64_virtualbox", :home, :root, "920_machine_default"]
DEBUG loader: Loading from: 1020_ubuntu/focal64_virtualbox (cache)
DEBUG loader: Loading from: root (cache)
DEBUG loader: Configuration loaded successfully, finalizing and returning
DEBUG push: finalizing
 INFO vmconfig: config class lookup for provider :virtualbox gave us base class: VagrantPlugins::ProviderVirtualBox::Config
 INFO vmconfig: looking up provider config for: :virtualbox
 INFO vmconfig: provider config value that was stored: #<VagrantPlugins::ProviderVirtualBox::Config:0x0000024a9d429ac0 @auto_nat_dns_proxy=true, @check_guest_additions=true, @customizations=[["pre-boot", ["modifyvm", :id, "--uart1", "0x3F8", "4"]], ["pre-boot", ["modifyvm", :id, "--uartmode1", "file", "NUL"]], ["pre-boot", ["modifyvm", :id, "--uartmode1", "disconnected"]]], @default_nic_type=nil, @destroy_unused_network_interfaces=false, @functional_vboxsf=true, @name=nil, @network_adapters={1=>[:nat, {}]}, @gui=false, @linked_clone=false, @linked_clone_snapshot=nil, @__invalid_methods=#<Set: {}>>
 INFO machine: Initializing machine: default
 INFO machine:   - Provider: VagrantPlugins::ProviderVirtualBox::Provider
 INFO machine:   - Box: #<Vagrant::Box:0x0000024a9dbeb2e0>
 INFO machine:   - Data dir: C:/Users/Thomas/development/rpi-cloud-init/.vagrant/machines/default/virtualbox
DEBUG virtualbox: Instantiating the driver for machine ID: "f840f6c3-6daf-4b93-8770-98a83b217450"
DEBUG base: Windows, checking for VBoxManage on PATH first
DEBUG base: Windows. Trying VBOX_INSTALL_PATH for VBoxManage
DEBUG base: VBOX_INSTALL_PATH value: C:\Program Files\Oracle\VirtualBox\
 INFO base: VBoxManage path: C:/Program Files/Oracle/VirtualBox/VBoxManage.exe
DEBUG meta: Finding driver for VirtualBox version: 7.0.12
 INFO meta: Using VirtualBox driver: VagrantPlugins::ProviderVirtualBox::Driver::Version_7_0
DEBUG base: Windows, checking for VBoxManage on PATH first
DEBUG base: Windows. Trying VBOX_INSTALL_PATH for VBoxManage
DEBUG base: VBOX_INSTALL_PATH value: C:\Program Files\Oracle\VirtualBox\
 INFO base: VBoxManage path: C:/Program Files/Oracle/VirtualBox/VBoxManage.exe
 INFO subprocess: Starting process: ["C:/Program Files/Oracle/VirtualBox/VBoxManage.exe", "showvminfo", "f840f6c3-6daf-4b93-8770-98a83b217450"]
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
 INFO subprocess: Starting process: ["C:/Program Files/Oracle/VirtualBox/VBoxManage.exe", "showvminfo", "f840f6c3-6daf-4b93-8770-98a83b217450", "--machinereadable"]
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
 INFO interface: Machine: metadata ["provider", :virtualbox, {:target=>:default}]
DEBUG command: have machine list to process
 INFO subprocess: Starting process: ["C:/Program Files/Oracle/VirtualBox/VBoxManage.exe", "showvminfo", "f840f6c3-6daf-4b93-8770-98a83b217450", "--machinereadable"]
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
 INFO subprocess: Starting process: ["C:/Program Files/Oracle/VirtualBox/VBoxManage.exe", "showvminfo", "f840f6c3-6daf-4b93-8770-98a83b217450", "--machinereadable"]
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
 INFO command: With machine: default (#<VagrantPlugins::ProviderVirtualBox::Provider:0x0000024a9db16388 @logger=#<Log4r::Logger:0x0000024a9db162e8 @fullname="vagrant::provider::virtualbox", @outputters=[], @additive=true, @name="virtualbox", @path="vagrant::provider", @parent=#<VagrantLogger:0x0000024a9c01cd48 @fullname="vagrant", @outputters=[#<Log4r::StderrOutputter:0x0000024a9bfb4950 @name="stderr", @level=0, @formatter=#<Vagrant::Util::LoggingFormatter:0x0000024a9c1a2e38 @formatter=#<Log4r::BasicFormatter:0x0000024a9c1e20b0 @depth=7>>, @out=#<IO:<STDERR>>>], @additive=true, @name="vagrant", @path="", @parent=#<Log4r::RootLogger:0x0000024a9c01ca28 @level=2, @outputters=[]>, @level=2, @trace=false>, @level=2, @trace=false>, @machine=#<Vagrant::Machine: default (VagrantPlugins::ProviderVirtualBox::Provider)>, @driver=#<VagrantPlugins::ProviderVirtualBox::Driver::Meta:0x0000024a9dba2798 @logger=#<Log4r::Logger:0x0000024a9dbeacf0 @fullname="vagrant::provider::virtualbox::meta", @outputters=[], @additive=true, @name="meta", @path="vagrant::provider::virtualbox", @parent=#<Log4r::Logger:0x0000024a9db162e8 @fullname="vagrant::provider::virtualbox", @outputters=[], @additive=true, @name="virtualbox", @path="vagrant::provider", @parent=#<VagrantLogger:0x0000024a9c01cd48 @fullname="vagrant", @outputters=[#<Log4r::StderrOutputter:0x0000024a9bfb4950 @name="stderr", @level=0, @formatter=#<Vagrant::Util::LoggingFormatter:0x0000024a9c1a2e38 @formatter=#<Log4r::BasicFormatter:0x0000024a9c1e20b0 @depth=7>>, @out=#<IO:<STDERR>>>], @additive=true, @name="vagrant", @path="", @parent=#<Log4r::RootLogger:0x0000024a9c01ca28 @level=2, @outputters=[]>, @level=2, @trace=false>, @level=2, @trace=false>, @level=2, @trace=false>, @interrupted=false, @vboxmanage_path="C:/Program Files/Oracle/VirtualBox/VBoxManage.exe", @uuid="f840f6c3-6daf-4b93-8770-98a83b217450", @driver=#<VagrantPlugins::ProviderVirtualBox::Driver::Version_7_0:0x0000024a9dc6ec80 @logger=#<Log4r::Logger:0x0000024a9ddf4370 @fullname="vagrant::provider::virtualbox_7_0", @outputters=[], @additive=true, @name="virtualbox_7_0", @path="vagrant::provider", @parent=#<VagrantLogger:0x0000024a9c01cd48 @fullname="vagrant", @outputters=[#<Log4r::StderrOutputter:0x0000024a9bfb4950 @name="stderr", @level=0, @formatter=#<Vagrant::Util::LoggingFormatter:0x0000024a9c1a2e38 @formatter=#<Log4r::BasicFormatter:0x0000024a9c1e20b0 @depth=7>>, @out=#<IO:<STDERR>>>], @additive=true, @name="vagrant", @path="", @parent=#<Log4r::RootLogger:0x0000024a9c01ca28 @level=2, @outputters=[]>, @level=2, @trace=false>, @level=2, @trace=false>, @interrupted=false, @vboxmanage_path="C:/Program Files/Oracle/VirtualBox/VBoxManage.exe", @uuid="f840f6c3-6daf-4b93-8770-98a83b217450", @env_lang={:LANG=>"C.utf8"}>, @version="7.0.12">, @cap_logger=#<Log4r::Logger:0x0000024a9d0e2cb8 @fullname="vagrant::capability_host::vagrantplugins::providervirtualbox::provider", @outputters=[], @additive=true, @name="provider", @path="vagrant::capability_host::vagrantplugins::providervirtualbox", @parent=#<VagrantLogger:0x0000024a9c01cd48 @fullname="vagrant", @outputters=[#<Log4r::StderrOutputter:0x0000024a9bfb4950 @name="stderr", @level=0, @formatter=#<Vagrant::Util::LoggingFormatter:0x0000024a9c1a2e38 @formatter=#<Log4r::BasicFormatter:0x0000024a9c1e20b0 @depth=7>>, @out=#<IO:<STDERR>>>], @additive=true, @name="vagrant", @path="", @parent=#<Log4r::RootLogger:0x0000024a9c01ca28 @level=2, @outputters=[]>, @level=2, @trace=false>, @level=2, @trace=false>, @cap_host_chain=[[:virtualbox, #<#<Class:0x0000024a9d0ed230>:0x0000024a9d1c3948>]], @cap_args=[#<Vagrant::Machine: default (VagrantPlugins::ProviderVirtualBox::Provider)>], @cap_caps={:docker=>#<Vagrant::Registry:0x0000024a9d0e3c58 @items={:public_address=>#<Proc:0x0000024a9d0d9e38 C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/providers/docker/plugin.rb:63>, :proxy_machine=>#<Proc:0x0000024a9d0d9d70 C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/providers/docker/plugin.rb:68>, :has_communicator=>#<Proc:0x0000024a9d0d9ca8 C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/providers/docker/plugin.rb:73>}, @results_cache={}>, :hyperv=>#<Vagrant::Registry:0x0000024a9d0e3b18 @items={:public_address=>#<Proc:0x0000024a9d2f3fc0 C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/providers/hyperv/plugin.rb:28>, :snapshot_list=>#<Proc:0x0000024a9d2f3ed0 C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/providers/hyperv/plugin.rb:33>, :configure_disks=>#<Proc:0x0000024a9d2f3e80 C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/providers/hyperv/plugin.rb:38>, :cleanup_disks=>#<Proc:0x0000024a9d2f3c00 C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/providers/hyperv/plugin.rb:43>, :validate_disk_ext=>#<Proc:0x0000024a9d2f3bd8 C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/providers/hyperv/plugin.rb:48>, :default_disk_exts=>#<Proc:0x0000024a9d2f3bb0 C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/providers/hyperv/plugin.rb:53>, :set_default_disk_ext=>#<Proc:0x0000024a9d2f3b88 C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/providers/hyperv/plugin.rb:58>}, @results_cache={}>, :virtualbox=>#<Vagrant::Registry:0x0000024a9d0e3640 @items={:forwarded_ports=>#<Proc:0x0000024a9d0f7de8 C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/providers/virtualbox/plugin.rb:30>, :nic_mac_addresses=>#<Proc:0x0000024a9d0f7dc0 C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/providers/virtualbox/plugin.rb:35>, :public_address=>#<Proc:0x0000024a9d0f7d98 C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/providers/virtualbox/plugin.rb:40>, :configure_disks=>#<Proc:0x0000024a9d0f7d70 C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/providers/virtualbox/plugin.rb:45>, :cleanup_disks=>#<Proc:0x0000024a9d0f7d48 C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/providers/virtualbox/plugin.rb:50>, :validate_disk_ext=>#<Proc:0x0000024a9d0f7d20 C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/providers/virtualbox/plugin.rb:55>, :default_disk_exts=>#<Proc:0x0000024a9d0f7cf8 C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/providers/virtualbox/plugin.rb:60>, :set_default_disk_ext=>#<Proc:0x0000024a9d0f7cd0 C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/providers/virtualbox/plugin.rb:65>, :snapshot_list=>#<Proc:0x0000024a9d0f7ca8 C:/Program Files/Vagrant/embedded/gems/gems/vagrant-2.4.0/plugins/providers/virtualbox/plugin.rb:70>}, @results_cache={}>}>)
DEBUG command: Invoking `ssh` action on machine
 INFO machine: Calling action: ssh on provider VirtualBox (f840f6c3-6daf-4b93-8770-98a83b217450)
 INFO interface: Machine: action ["ssh", "start", {:target=>:default}]
 INFO runner: Running action: machine_action_ssh #<Vagrant::Action::Builder:0x0000024a9b9c5698>
 INFO warden: Calling IN action: #<VagrantPlugins::ProviderVirtualBox::Action::CheckVirtualbox:0x0000024a9db07f68>
DEBUG base: Windows, checking for VBoxManage on PATH first
DEBUG base: Windows. Trying VBOX_INSTALL_PATH for VBoxManage
DEBUG base: VBOX_INSTALL_PATH value: C:\Program Files\Oracle\VirtualBox\
 INFO base: VBoxManage path: C:/Program Files/Oracle/VirtualBox/VBoxManage.exe
DEBUG meta: Finding driver for VirtualBox version: 7.0.12
 INFO meta: Using VirtualBox driver: VagrantPlugins::ProviderVirtualBox::Driver::Version_7_0
DEBUG base: Windows, checking for VBoxManage on PATH first
DEBUG base: Windows. Trying VBOX_INSTALL_PATH for VBoxManage
DEBUG base: VBOX_INSTALL_PATH value: C:\Program Files\Oracle\VirtualBox\
 INFO base: VBoxManage path: C:/Program Files/Oracle/VirtualBox/VBoxManage.exe
 INFO subprocess: Starting process: ["C:/Program Files/Oracle/VirtualBox/VBoxManage.exe", "list", "hostonlyifs"]
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
 INFO warden: Calling IN action: #<VagrantPlugins::ProviderVirtualBox::Action::CheckCreated:0x0000024a9dba2478>
 INFO subprocess: Starting process: ["C:/Program Files/Oracle/VirtualBox/VBoxManage.exe", "showvminfo", "f840f6c3-6daf-4b93-8770-98a83b217450", "--machinereadable"]
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
 INFO warden: Calling IN action: #<VagrantPlugins::ProviderVirtualBox::Action::CheckAccessible:0x0000024a9dba2400>
 INFO subprocess: Starting process: ["C:/Program Files/Oracle/VirtualBox/VBoxManage.exe", "showvminfo", "f840f6c3-6daf-4b93-8770-98a83b217450", "--machinereadable"]
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
 INFO warden: Calling IN action: #<VagrantPlugins::ProviderVirtualBox::Action::CheckRunning:0x0000024a9dba2310>
 INFO subprocess: Starting process: ["C:/Program Files/Oracle/VirtualBox/VBoxManage.exe", "showvminfo", "f840f6c3-6daf-4b93-8770-98a83b217450", "--machinereadable"]
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
 INFO warden: Calling IN action: #<Vagrant::Action::Builtin::SSHExec:0x0000024a9dba2298>
 INFO subprocess: Starting process: ["C:/Program Files/Oracle/VirtualBox/VBoxManage.exe", "showvminfo", "f840f6c3-6daf-4b93-8770-98a83b217450", "--machinereadable"]
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 31999
DEBUG subprocess: Exit status: 0
DEBUG virtualbox_7_0: Searching for SSH port: 22
DEBUG base: Windows, checking for VBoxManage on PATH first
DEBUG base: Windows. Trying VBOX_INSTALL_PATH for VBoxManage
DEBUG base: VBOX_INSTALL_PATH value: C:\Program Files\Oracle\VirtualBox\
 INFO base: VBoxManage path: C:/Program Files/Oracle/VirtualBox/VBoxManage.exe
DEBUG meta: Finding driver for VirtualBox version: 7.0.12
 INFO meta: Using VirtualBox driver: VagrantPlugins::ProviderVirtualBox::Driver::Version_7_0
DEBUG base: Windows, checking for VBoxManage on PATH first
DEBUG base: Windows. Trying VBOX_INSTALL_PATH for VBoxManage
DEBUG base: VBOX_INSTALL_PATH value: C:\Program Files\Oracle\VirtualBox\
 INFO base: VBoxManage path: C:/Program Files/Oracle/VirtualBox/VBoxManage.exe
DEBUG virtualbox_7_0: read_forward_ports: uuid=f840f6c3-6daf-4b93-8770-98a83b217450 active_only=false
 INFO subprocess: Starting process: ["C:/Program Files/Oracle/VirtualBox/VBoxManage.exe", "showvminfo", "f840f6c3-6daf-4b93-8770-98a83b217450", "--machinereadable"]
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
DEBUG virtualbox_7_0:   - [1, "ssh", 2222, 22, "127.0.0.1"]
 INFO subprocess: Starting process: ["C:\\Program Files\\Vagrant\\embedded\\usr\\bin/ssh.EXE"]
DEBUG subprocess: Selecting on IO
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 255
 INFO ssh: Invoking SSH: C:\Program Files\Vagrant\embedded\usr\bin/ssh.EXE ["vagrant@127.0.0.1", "-p", "2222", "-o", "LogLevel=FATAL", "-o", "Compression=yes", "-o", "DSAAuthentication=yes", "-o", "IdentitiesOnly=yes", "-o", "StrictHostKeyChecking=no", "-o", "UserKnownHostsFile=/dev/null", "-o", "PubkeyAcceptedKeyTypes=+ssh-rsa", "-o", "HostKeyAlgorithms=+ssh-rsa", "-i", "C:/Users/Thomas/development/rpi-cloud-init/.vagrant/machines/default/virtualbox/private_key"]
DEBUG safe_exec: Converting command and arguments to common UTF-8 encoding for exec.
DEBUG safe_exec: Command: `"C:\\Program Files\\Vagrant\\embedded\\usr\\bin/ssh.EXE"` Args: `["vagrant@127.0.0.1", "-p", "2222", "-o", "LogLevel=FATAL", "-o", "Compression=yes", "-o", "DSAAuthentication=yes", "-o", "IdentitiesOnly=yes", "-o", "StrictHostKeyChecking=no", "-o", "UserKnownHostsFile=/dev/null", "-o", "PubkeyAcceptedKeyTypes=+ssh-rsa", "-o", "HostKeyAlgorithms=+ssh-rsa", "-i", "C:/Users/Thomas/development/rpi-cloud-init/.vagrant/machines/default/virtualbox/private_key"]`
DEBUG safe_exec: Converted - Command: `"C:\\Program Files\\Vagrant\\embedded\\usr\\bin/ssh.EXE"` Args: `["vagrant@127.0.0.1", "-p", "2222", "-o", "LogLevel=FATAL", "-o", "Compression=yes", "-o", "DSAAuthentication=yes", "-o", "IdentitiesOnly=yes", "-o", "StrictHostKeyChecking=no", "-o", "UserKnownHostsFile=/dev/null", "-o", "PubkeyAcceptedKeyTypes=+ssh-rsa", "-o", "HostKeyAlgorithms=+ssh-rsa", "-i", "C:/Users/Thomas/development/rpi-cloud-init/.vagrant/machines/default/virtualbox/private_key"]`
vagrant@127.0.0.1: Permission denied (publickey).

Thomas@Sammy MINGW64 ~/development/rpi-cloud-init (main)

The vagrant@127.0.0.1: Permission denied (publickey) error is a common issue per Google search.
Vagrant insecure key detected appears to be a normal warning. However, that didn't help get through to the next step. What helped was the following:
After vagrant halt && vagrant destroy, adding config.ssh.insert_key = false to Vagrantfile helped get through this error.
Thomas@Sammy MINGW64 ~/development/rpi-cloud-init (main)
$ cat Vagrantfile
$script = <<-SCRIPT
curl -sL get.hashi-up.dev | sudo sh
sudo hashi-up packer get --version 1.9.4 -d /usr/local/bin
SCRIPT

Vagrant.configure("2") do |config|

    config.vm.box = "ubuntu/focal64"

    config.ssh.insert_key = false

    config.vm.boot_timeout = 600

    config.vm.provider "virtualbox" do |vb|
      vb.customize [ "modifyvm", :id, "--uartmode1", "disconnected" ]
    end

    config.vm.provision "shell", inline: $script

  end

Feel free to close this issue once you review it.

repo: jsiebens/rpi-cloud-init


text:
Is this still maintained?

There are open PR's from 2013 and it's been over 2 years since the last release to npm.
Also, #161 still hasn't been addressed
@jsoma

It took a while, but this issue slowly guilted me into active maintenance! Thanks a million!

source: gharchive/issue

repo: jsoma/tabletop

license: mit

license_type: permissive

license_source: bigquery


text:
Add some meta schema tests

We should have some tests whose schema is a meta schema and whose instances are schemas.
This would constitute essentially a test suite for the meta schemas, but is also likely useful for downstream implementors (like well, me!).
(This is a note to basically move these two tests here, along with some more, after deciding how to represent these in the suite).

Random likely-doable idea: the meta schema is a finite document, so we can likely at very least compute coverage over it (and make sure each property is covered).

Random likely-doable idea: the meta schema is a finite document, so we can likely at very least compute coverage over it (and make sure each property is covered).

Considering we backed some of these out (in #718 via https://github.com/json-schema-org/JSON-Schema-Test-Suite/pull/716#issuecomment-1932765403) it actually probably makes sense to close these I think.
Thanks for giving it a shot though.

repo: json-schema-org/JSON-Schema-Test-Suite


text:
Refactor descriptions and test for big numbers

That is just a little refactoring of the tests for big numbers. For my test-runner, I need unique names for descriptions. I think it is also a little bit more readable in this form.

Hey!
Thanks (again).
I'm not so comfortable with this to be honest :/
I'd love to resolve #223 first before merging these kinds of changes, for two reasons:

I don't want to cater to properties that we do not currently guarantee (like "all descriptions are unique") -- either we should make that so and add a (suite) test guaranteeing it is the case, or, I suspect more likely, you should change your suite loader :) -- the reasoning there is simple, either it's a guarantee going forward, or someone will introduce some later test that will again not have this property, and again we'll churn on it

At the minute it's a gray area on what's safe to change for backwards compatibility (#223) -- all there is is the description essentially at the minute (which you can use as a fully-qualified-path to the test), so when you change that, anyone who might have pinned away from that test might now be broken (or well, might need to update their suite loader)

Hope that makes sense, but if not, lemme know, and definitely definitely would appreciate help on #223.

Hello,
that makes sense. I will tell my suite loader to be a little bit more relaxed.
Maybe I can write my opinions to #223 if I find some time.
Thanks, have a nice day.

That would be great :)
Thanks!!

source: gharchive/pull-request

authors: Julian NickNeck


text:
泛型多层嵌套bug

泛型多层嵌套bug

兄弟，可不可以吧代码和报错的异常栈贴出来。

不要了，我找了一个更加强大的mock开源库，稍微自己修改了一下，支持多层嵌套泛型。功能强大到我自己都不敢相信，哈哈哈

https://github.com/mtedone/podam

authors: jsonzoup luckyQing

repo: jsonzou/jmockdata


text:
Suggestion: change thead children from td to th

The advantage of th elements is that they can be used with position:sticky CSS. Which means it become very easy to always keep the headers frozen at the top with some CSS.
I've hacked the library to output th's in the thead, and have seen no adverse effects (yet). I've done this for the headers and the filters.

Any new on this please?

authors: flatsiedatsie matthieumastadenis

repo: jspreadsheet/ce

license: MIT

license_source: github-api


text:
152

Fix for #152 and #153.
Includes commit for #153 as I was unable to successfully build the project without it.

I'll try to check this PR still this week. Thanks for patience.

This looks awesome, thanks @techtangents 🙌

Would you like me to rebase to fix the conflicts?

rebase would be great!

rebased myself

authors: markalfred phadej techtangents

repo: jsverify/jsverify


text:
Simplify definition of MaybeDefault

The previous version of MaybeDefault stores pointers to the Eq, Show, and Read instances of the defaulted value.
MaybeDefault is used with Style, Color, and Text. All of these types already have all of the necessary instances, and we never work with MaybeDefault generically. Defering the Show, Eq, and Read instances down to the SetTo case isn't helping us to work with types that don't have these instances.
My particular reason for wanting this change is that I want to be able to store Attr in a compact region as implemented in ghc-compact. This GHC feature doesn't work with functions, and the encoding of putting the constraints in the context of SetTo is that you're putting functions as parameters to that constructor. Making this code less clever makes the SetTo constructor smaller (by at least 3 pointers) and allows us to remove functions from the image representation types.

Thank you!

authors: glguy jtdaugherty

repo: jtdaugherty/vty


text:
SSH Data Bag

Following the cookbook installation instructions, I created a databag called ossec and an ssh item inside of it. I cannot however get it to work correctly though after trying the following:
Copy output of ruby -e 'puts IO.read("/tmp/id_rsa")' directly between the "" for "privkey": "" which causes an error when I attempt to knife upload data bag.
Copy output of ruby -e 'puts IO.read("/tmp/id_rsa")' | tr -d '\n' allows the privkey section to be accepted during a knife upload but causes the clients to error with ossec-agentd(4101): WARN: Waiting for server reply (not started). Tried: '10.9.8.210'. in the client and ossec-remoted(1403): ERROR: Incorrectly formated message from '10.9.8.20'. in the server which I believe indicates a bad SSH key.
Can someone show me an example of a working ssh data bag item or tell me what I'm doing wrong?

Try:
cat /tmp/id_rsa |perl -pe 's!(\x0d)?\x0a!\n!g'
and
cat /tmp/id_rsa.pub |perl -pe 's!(\x0d)?\x0a!\n!g'
and use the output of each command as the data you put into the data bag

When I do a "knife upload data bag from file data_bags/ossec/ssh.json", I get:
ERROR: data_bags/ossec/ssh.json failed to write: Parse error reading JSON: lexical error: invalid character inside string.
----BEGIN RSA PRIVATE KEY----- MIIJKQIBAAKCAgEAvbVSM0of/fee7
(right here) ------^
With the (right here) pointing to the newline.

You need to replace the actual new lines with \n.

Ah, that seems to have gotten the SSH key uploaded. Thanks for the tip jtimberman. Still getting the incorrectly formatted message error but I'll keep poking at the server/client

authors: Natrinicle huwge jtimberman

repo: jtimberman/ossec-cookbook


text:
Error occurred when executing InstantMeshLoader

Hi Terry,
followed the install instructions on windows11 - rtx3090 - Cuda 12.1

Visual Studio Build Tools](https://visualstudio.microsoft.com/downloads/?q=build+tools)
ComfyUI-3D-Pack
ComfyUI-InstantMesh

and got error message
Error occurred when executing InstantMeshLoader:
Error building extension 'nvdiffrast_plugin': [1/16] C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.1;
Thanks

hi @RegRurutu , could you refer to https://github.com/jtydhr88/ComfyUI-InstantMesh/issues/6, looks like someone got fix this issue.

installing CUDA 12.1 ?
I removed every other version installed previously !
and double checked the env variable CUDA_HOME to point to C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.1
Still the same error !


text:
Doesn’t support HTTP/1 style response

Just skimmed the source code; one thing that jumps out is that it expects either a chunked response, or a content-length. But another common option is neither of these: the response body just extends till EOF on the stream.

I do like the idea, if you know how to do it, Pull Request welcome, will merge, add yourself as author.
I do not have time to do it myself right now. 🙂:+1:

I've definitely run across real-world servers that do this, especially simple CGI-type scripts that generate the response dynamically and don't bother to buffer it first or insert the chunked metadata.

authors: juancarlospaco snej

repo: juancarlospaco/harpoon


text:
[Bug] Node registered with preauthkey has expiration of 0001-01-01 00:00:00 in Beta 2.

Is this a support request?

[X] This is not a support request

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
When creating a preauthkey with the following command:
docker exec -it headscale headscale preauthkeys list --user system
The preauthkey gets created correctly;
ID | Key                                              | Reusable | Ephemeral | Used  | Expiration          | Created             | Tags
1  | KEYID | true     | false     | false | 2024-09-01 06:54:03 | 2024-08-30 06:54:03 |
However, as soon as I register a node with it, the expiration of that node is set to 0001-01-01 00:00:00.
Expected Behavior
I'd expect a node to get the same expiration as the preauthkey or, at least set the expiration to something which doesn't render the node unusable.
Steps To Reproduce
Create a preauthkey, and register a node with it, check the expiry of that node.
Environment
- OS: Debian, docker.
- Headscale version: v0.23.0-beta2
- Tailscale version: 1.72.1

Runtime environment

[X] Headscale is behind a (reverse) proxy
[X] Headscale runs in a container

Anything else?
No response

Does this also apply to 0.22.3?

I'd expect a node to get the same expiration as the preauthkey or, at least set the expiration to something which doesn't render the node unusable.

This is by design.
A node getting 0001-01... expiry implies that it will never expire. The expiry for the preauth key is for how lon the given key can be used, which is not related to how long the node is approved.
If you want to set an expiry for your node, you can do it with the CLI, or you can set a default in the configuration.
However, if the node is not working because its set to 0001-01..., then this is a bug, it should work forever, please let me know if that is the case.

Did this happen for 0.22.3? I'm just trying to understand if it is a regression or have been there all the time.

can't be enabled in the Tailscale app for iOS

Is this something you observe on other OSes? (Linux/macOS/Windows)?

This might also be related;
I have my exit-node in a container via docker-compose
  exit-node:     container_name: exit-node     image: tailscale/tailscale:latest     restart: unless-stopped     network_mode: host     privileged: true     environment:       - TS_USERSPACE=false       - TS_STATE_DIR=/var/lib/tailscale       - TS_AUTHKEY=REMOVED       - TS_AUTH_ONCE=true       - TS_HOSTNAME=VPN       - TS_ROUTES=192.168.0.0/16       - TS_EXTRA_ARGS=--login-server=https://vpn.domain.com --accept-routes=false --snat-subnet-routes=false --advertise-exit-node --advertise-tags=tag:exitNode --reset     volumes:       - /opt/tailscale/config/tailscale:/var/lib/tailscale       - /dev/net/tun:/dev/net/tun       - /etc/timezone:/etc/timezone:ro       - /etc/localtime:/etc/localtime:ro     cap_add:       - net_admin       - SYS_MODULE       - NET_RAW
When I run docker exec -it exit-node tailscale status I get an answer "Logged out".
But when I'm checking with Headscale, it says my machine is connected and working.
ID | Hostname       | Name           | MachineKey | NodeKey | User   | IP addresses                  | Ephemeral | Last seen           | Expiration          | Connected | Expired
11 | VPN            | vpn            | [WQ9sh]    | [d/CnX] | system | 100.64.0.5, fd7a:115c:a1e0::5 | false     | 2024-08-30 11:21:23 | 0001-01-01 00:00:00 | online    | no

I am having a hard time replicating this. I have a my headscale on beta2, my Macbook connected to it and an exit node added via pre auth key, showing 0001-01... expiration and my exit node is showing correctly on the Macbook.
Are you using Postgres og SQLite?

When I run docker exec -it exit-node tailscale status I get an answer "Logged out".

Is there anything interesting in the logs in regards to logging it out?

I'm using Postgres. Here's the logs from my exit-node container:
boot: 2024/08/30 14:06:38 Running 'tailscale up'
Warning: IPv6 forwarding is disabled.
Subnet routes and exit nodes may not work correctly.
See https://tailscale.com/s/ip-forwarding
2024/08/30 14:06:38 Start
2024/08/30 14:06:38 active login:
2024/08/30 14:06:38 Backend: logs: be:4dff1321c8609b7e49e8b6499de698098222334ba1511748e526ddd539c9edac fe:
2024/08/30 14:06:38 control: client.Login(0)
2024/08/30 14:06:38 control: client.Shutdown ...
2024/08/30 14:06:38 control: doLogin(regen=false, hasUrl=false)
2024/08/30 14:06:38 control: authRoutine: exiting
2024/08/30 14:06:38 control: updateRoutine: exiting
2024/08/30 14:06:38 control: mapRoutine: exiting
2024/08/30 14:06:38 control: Client.Shutdown done.
2024/08/30 14:06:38 control: control server key from https://vpn.yeyeoke.com: ts2021=[umTao], legacy=
2024/08/30 14:06:38 control: RegisterReq: onode= node=[d/CnX] fup=false nks=false
2024/08/30 14:06:38 control: RegisterReq: got response; nodeKeyExpired=false, machineAuthorized=true; authURL=false
2024/08/30 14:06:38 blockEngineUpdates(false)
2024/08/30 14:06:38 active login: system
2024/08/30 14:06:38 Switching ipn state NoState -> NeedsLogin (WantRunning=true, nm=true)
2024/08/30 14:06:38 blockEngineUpdates(true)
2024/08/30 14:06:38 control: NetInfo: NetInfo{varies=false hairpin= ipv6=false ipv6os=true udp=true icmpv4=false derp=#4 portmap= link="" firewallmode="ipt-default"}
2024/08/30 14:06:38 magicsock: endpoints changed: 95.209.138.76:40309 (stun), 172.17.0.1:40309 (local), 172.18.0.1:40309 (local), 192.168.4.9:40309 (local)
2024/08/30 14:06:43 health(warnable=warming-up): ok
2024/08/30 14:06:48 health(warnable=no-derp-home): error: Tailscale could not connect to any relay server. Check your Internet connection.
2024/08/30 14:06:48 health(warnable=no-derp-connection): error: Tailscale could not connect to the 'Frankfurt' relay server. Your Internet connection might be down, or the server might be temporarily unavailable.
boot: 2024/08/30 14:07:37 failed to auth tailscale: failed to auth tailscale: tailscale up failed: signal: killed

I'm using Postgres. Here's the logs from my exit-node container:

Sounds like you are running into #764 then, I'm not sure for whom this is triggered, it is a bit surprising since the integration tests run for postgres as well.
We do not actively work on the postgres support, if you do not have a good reason for using postgres, I suggest you try SQLite.

Oh, that's actually a simple fix in my use-case since I have no reason at all for using Postgres. I'll try that and see if it works better.

Great, please let me know how it works, we will eventually try to resolve the other issue, but since there is little reason to use postgres with headscale, so it isnt really on our priority list considering other work we have to get resolved.

Yeah, I get it. I can report that this solved my issue. Everything works now 👍

authors: kradalby yeyeoke

repo: juanfont/headscale


text:
Add padding to last chunk instead of ignoring it

Problem
If the duration of the last chunk is lower than the desired duration, the chunk is ignored.
Idea
Pad the last (incomplete) chunk with zeros. This mainly affects FileAudioSource and AudioFileReader. It is important that num_chunks() (that estimates the number of chunks without actually doing the chunking) also counts this incomplete chunk.

Implemented in PR #55


text:
Support configuration of expected results in the three-valued temporal logic

Currently we use org.scalacheck.Prop.Undecided for the value ? of the logic. Specs2 interprets that as a failing test, and you cannot use org.specs2.matcher.ResultMatchers to mark a property as expecting undecided because the integration of specs2 with scalacheck understands Undecided as a failure, and there is no matcher in ResultMatchers for Undecided. To solve this we could do one of these:

define a new specs2 matcher sin the line of ResultMatchers for undecided properties. This is the preferred approach as the undecided result could be expressed in the definition of is, or even several alternatives by using specs2 or
add an argument to DStreamProp.forall to specify a set of aceptable prop status, so for example we can specify that undecided, proof and true are aceptable final results for a temporal property. This is very easy to implement

Note ScalaCheck is not a problem here, because when it gets a undecided result for a test case it continues with the next test case. This can we tested by using a forall formula with a during longer than the size of the input generator

currently converting  Prop.Undecided into Prop.passed as we are interested in finding counterexamples, this should be the default but also should be configurable

repo: juanrh/sscheck


text:
Implement foreground tapping under assisted tap

[ ] Need to finish assisted tap flow
[ ] Change icon image based on phone OS (iPhone vs Android)

Can use this repo https://github.com/hgoebl/mobile-detect.js to detect if it's iOS (display the image with card tap on the top) and detect if it's Android (display the image with card in the center).


text:
adding hacking tutorial for reflexted xss

Description

This PR adds a hacking tutorial for reflected XSS. As the reflected XSS challenge requires page reload after adding the payload in the url, the tutorial can't persist after the page reload giving the usual: 'Congratulations, you solved this challenge' message. Therefore, I added a helper function to compare if the hash contains the correct parameters with the payload. Once that is correct, the user gets notified. So the tutorial goes as far as it can go.
I also modified the waitForAngularRouteToBeVisited() function to not only compare the route but also allow for parameters that could come after. That will allow for detection of routes including parameters without breaking any existing functionality.
Resolved or fixed issue:
Affirmation

[x] My code follows the CONTRIBUTING.md guidelines

👋 Thanks for this tutorial PR! For my liking it is a little bit too straightforward, i.e. there is no real sense of progression. You go to the tracking page, enter the actual payload, refresh, done. Maybe you could insert one step where you instead have a non-solving payload as step 1 injected to see the effect (like some image or whatnot) and then as step 2 do the solving payload?

I see your point! I'll add another step in between.

I added a non-solving step but needed to improvise a bit as a page reload ends the tutorial. Let me know if you have a better idea to represent this. I also tagged the tutorial in the yaml file. I placed it right behind the other xss tutorials, that made most sense to me although it is a 2 star challenge and another 1 star challenge comes after. I could move it more to the back though if you disagree.

I didn't mention this, but we need to keep the recommendation order grouped by difficulty because of the Tutorial Mode. That one unlocks challenges in batches of difficulty, and a mixed order might mess with it.

Got it. I changed the order to keep them grouped by difficulty.

authors: ThReinecke bkimminich

repo: juice-shop/juice-shop


text:
[FEATURE] When a Mount Pod is deleted, the CSI driver should update the Mount Pod

In current code, when deleted a in-use(has reference annnotation) mount pod, the csi driver would create a new mount pod with same configuration:
Here is the relevant code:
https://github.com/juicedata/juicefs-csi-driver/blob/master/pkg/controller/pod_driver.go#L376C1-L384C6
var newPod = &corev1.Pod{
	ObjectMeta: metav1.ObjectMeta{
		Name:        pod.Name,
		Namespace:   pod.Namespace,
		Labels:      pod.Labels,
		Annotations: annotation,
	},
	Spec: pod.Spec,
}

However, In many case, deleting a mount pod means that we want to update the mount pod, such as using a new Juicefs client image.

currently, it will apply the new spec based on the config  https://github.com/juicedata/juicefs-csi-driver/blob/337603e1897f87b5946265baa28ee148255b8d0d/pkg/controller/pod_driver.go#L387-L389
but, there will be an issue in the CE version that causes it to not take effect, fixed in https://github.com/juicedata/juicefs-csi-driver/pull/1014
a fixed version will be released in this week.

currently, it will apply the new spec based on the config  https://github.com/juicedata/juicefs-csi-driver/blob/337603e1897f87b5946265baa28ee148255b8d0d/pkg/controller/pod_driver.go#L387-L389
but, there will be an issue in the CE version that causes it to not take effect, fixed in https://github.com/juicedata/juicefs-csi-driver/pull/1014
a fixed version will be released in this week.

Thanks for your efforts. I had this question due to the old version of the code.

repo: juicedata/juicefs-csi-driver


text:
Format failing with "parse info: EOF"

Running a droplet on DO pointing to a redis instance and Backblaze. I tried both s3 storage option and b2 option with the same result.
Any ideas?
./juicefs format --storage s3 --bucket https://s3.us-west-002.backblazeb2.com/bucket $REDIS folder
<INFO>: Meta address: redis://doadmin:@private-db-redis
<WARNING>: parse info: EOF
<INFO>: Data uses s3://bucket/folder/
<FATAL>: format: EOF

@hyprnick It seems there's some error when parsing the redis URL, please check the format doc

This redis://doadmin:@private-db-redis URL looks like should be redis://:doadmin@private-db-redis.

Thanks all. I’ll give that a shot.
I tried to connect directly using redis-cli and running into problems because digital ocean’s managed redis requires TLS.
Does juice support tls for redis?

Thanks all. I’ll give that a shot.
I tried to connect directly using redis-cli and running into problems because digital ocean’s managed redis requires TLS.
Does juice support tls for redis?

Use scheme rediss:// for TLS

authors: chnliyong hyprnick xiaogaozi

repo: juicedata/juicefs


text:
Document proxy settings for deployment bundle

One of the requested features was to support environments which enforce proxy access.
This can be done at the docker level, by specifying the following env vars in the systemd job
Environment="HTTP_PROXY=http://squid.internal:3128"
Environment="HTTPS_PROXY=https://squid.internal:3128"

Loosely related to #61, and should be documented in the Bundle README

Merged and resolved as of  https://github.com/juju-solutions/bundle-canonical-kubernetes/pull/81


text:
Friendly type paramaters

This PR renames the type parameters in optics from A, B to From and To, e.g.
trait Lens[From, To] {
  def get(from: From): To
  def set(to: To): From => From
}

I believe it should make the code more readable, especially for beginners.

Given that the traditional intuitive approximation to lenses is "A field in a record", would the names Record and Field suit it?

@diesalbla Yes it will probably help for Lens but it is not the case for other optics, e.g. Prism or Iso. IMO, we should aim for consistent type parameters across all optics.
However, there is a case for changing the "traditional" names of optics to something like tofu-optics: https://github.com/TinkoffCreditSystems/tofu/blob/master/optics/core/src/main/scala/tofu/optics/classic.scala#L8

I can see how for a subset of people having the traditional A, B would be easier, however I think it is easier for beginners. I often get confused by the types so for me it is a 👍

I wonder a better name for X in the compose Operations, maybe Next, Last, Final Or Target. I admit none of the is very satisfying

Perhaps Context and Elem may be a bit more general. You can see a lens as an optic to see the element (the field) inside its context. For a Prism, the context of one element is that it is one alternatives.

@cquiroz I also tried Next but I wasn't convinced. I agree X is not amazing, what would be your preference?

@diesalbla Thanks for your proposal. To be honest, I don't have a strong opinion either way. Unfortunately, naming is really subjective and asking a poll on twitter will probably not target the beginner audience we are looking for :(
I would suggest to go ahead with the current proposal and re-evaluate when we discuss renaming optics.

authors: cquiroz diesalbla julien-truffaut

repo: julien-truffaut/Monocle


text:
French translation of friends.

friends.html file to help on rust-lang#501

👍

authors: LeMoussel julienXX

repo: julienXX/rust-www


text:
Harmonize Rack dependencies and tests

Set up Appraisal for testing against both Rack 2 and 3
Ensure all HTTP header uses are lowercase
Support non-rewindable request bodies
Use Rack::Lint when running tests
Bring tests more in line with the Rack spec

@skatkov feel free to chime in on the review if you feel like it, I've integrated as much of your prior work as I could

@franzliedke take a look when you have a moment

repo: julik/idempo


text:
Consistent kill behaviour

This addresses issue #385 .

Thanks, but it's a 6+-year-old behavior and we don't have a consensus if we should do this or not. I'll leave this open.

A nice middle ground would be to support both cases, i.e. kill <tab> and kill foo**<tab>.

Awesome! Thanks a lot.

Awesome! Thanks a lot.

authors: RobSis hellricer junegunn

repo: junegunn/fzf


text:
PlugInstall Crashes on Vim 8.0

PlugInstall is crashing on Vim version 8.0. See error message in second screenshot below. Vim exits with error message printed to the terminal.

8.0

Type:

[X] Bug
[ ] Enhancement
[ ] Feature Request
[ ] Question

OS:

[ ] All/Other
[ ] Linux
[X] OS X
[ ] Windows

Vim:

[X] Terminal Vim
[ ] GVim
[ ] Neovim

Do you use RVM? Please see if this link helps: https://github.com/junegunn/vim-plug/wiki/faq#vim-caught-deadly-signal-segv

I was getting the same issue and the link that Junegunn gave fixed the issue. Thanks !

Oh interesting thanks for the tip @junegunn. I use rbenv with the 2.3.1 global version of ruby. I compiled vim by hand with the enable-rubyinterp config option but maybe I also need to provide a path to the correct ruby install. I'll report back my findings.

I was able to fix this but I'm not entirely clear what happened. I'll reproduce the fix below for anyone it might help. I started off with Ruby 2.3.1 set with rbenv global 2.3.1 and then compiled vim with the --enable-rubyinterp flag. I still had issues even though I noticed with vim --version that the compiled version was pointing to the correct ruby folder. When I recompiled vim using the system version of ruby it seems to work.
To fix I did this:
> rbenv shell system
> ruby --version //=> ruby 2.0.0p648
> cd ~/src/vim
> ./configure --enable-rubyinterp
> make && sudo make install

So maybe it's a Ruby 2.3.1 issue or perhaps more likely it's a conflict between vim being compiled with version 2.3.1. and trying to use the system version.

authors: benoittgt cmather junegunn

repo: junegunn/vim-plug


text:
Update Publishing Workflows

See https://github.com/jupyter-server/jupyter_releaser/pull/557 for background.
If y'all set up Trusted Publishing (https://pypi.org/manage/project/jupyter-scheduler/settings/publishing/#errors) for this repo, I can make a PR to update the workflows to use the Jupyter Server GitHub App for publishing.

I have replaced the branch rules with  a branch "Ruleset"
I added a tag Ruleset
I configured the Release environment with appropriate credentials.

@blink1073 Thank you for upgrading workflows and creating this issue.
JupyterLab PR for more context: https://github.com/jupyterlab/jupyterlab/pull/15973

@Zsailer can you please add me (blink1073) to the project on pypi?  https://pypi.org/manage/project/jupyter-scheduler/collaboration/

cc @3coins @dlqqq this is the last repo using a bot account.

I added you @blink1073! 😎 🚀

authors: Zsailer andrii-i blink1073

repo: jupyter-server/jupyter-scheduler


text:
Change steering council language about "ultimately make the final decisions."

When the site was in draft, I complained about this sounding very authoritarian and completely contrary to the sprit of our community, but I was told that this was just temporary placeholder text.  Instead, it went live.
Let's please not have that language anywhere on the site: it sends completely the wrong message to our community.
Ping @ellisonbg.

What's the right language for this? "Take responsibility when consensus cannot be reached"? cc @willingc as well.

A link to the governance docs / repo would be good in that section too. People / companies need to understand that even council membership can be obtained.

Min, I like that way of putting it, but maybe add "Take responsibility for
the decision..."
On Mon, Oct 12, 2015 at 10:17 AM, Peter Parente notifications@github.com
wrote:

A link to the governance docs / repo would be good in that section too.
People / companies need to understand that even council membership can be
obtained.
—
Reply to this email directly or view it on GitHub
https://github.com/jupyter/jupyter.github.io/issues/46#issuecomment-147410980
.

--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@calpoly.edu and ellisonbg@gmail.com

@cameronoelsen Typo in Steering Council description. Should be "led" in this sentence.
Our team is primarily lead by 10 steering committee members who ultimately make the final decisions.

How about this wording?
Technical decisions are guided by open community discussion.
The steering council (link to governance docs as suggested by @parente), as a representative of the greater community, may make decisions to benefit the project's overall health and strategic direction. BDFL Fernando Perez may take responsibility for making a decision when unusual, and likely infrequent, situations warrant, such as steering council deadlock or a time sensitive response.

I will fix this right when I get back in the office around 11 ☺

On Oct 12, 2015, at 8:05 AM, Carol Willing notifications@github.com wrote:
@cameronoelsen Typo in Steering Council description. Should be "led" in this sentence.
Our team is primarily lead by 10 steering committee members who ultimately make the final decisions.
—
Reply to this email directly or view it on GitHub.

I like where @willingc is going, thanks! That's precisely what I was looking for, we want to convey that the role of the SC/BDFL is:

primarily one of sustaining and  nurturing a healthy and open community, where participation in discussion is encouraged from all, where new voices are welcome, and where a diversity of opinion and participants is explicitly desired.  We encourage respectful dissent, we value disagreement as a sign of creativity, and we try to steer that community towards better solutions to the many technical and governance problems the project deals with.

only when necessary, do the SC/BDFL act as a backstop if the open community discussion and consensus process falters.

Thank you so much, Carol, for your input.  Great perspective! Sorry to be going offline now, but I think this is going in a great direction, I trust you to find a good solution for now, we can always iterate again in a few weeks if fine-tuning is needed later.
I'm happy if you all close this with some version of the language in this discussion. If later I think it needs tuning, I'll take it upon myself to just open a PR.
Thanks everyone!

ping @cameronoelsen on this, since it's been a couple of weeks.

So do we want to add one or two buttons under the material cards (names of the members on the steering council) that leads outwards to documents describing how we are composed as an organization? As for the supporting subhead, how is this:
"Our team is primarily led by 10 steering committee members who ultimately, when open community discussion and consensus process falters, take responsibility for the final decision."

@cameronoelsen I think @fperez wanted a warmer, more collaborative tone for the Steering Council and Governance sections.

Your suggested wording with minor edits would work for steering council:
"Our team is primarily led by 10 steering committee members who, when open community discussion falters on reaching consensus, take responsibility for the project direction and final decision."

Under Governance -> Decisions, perhaps just use @fperez's suggested wording:
The Steering Council fosters project governance "... as primarily one of sustaining and nurturing a healthy and open community, where participation in discussion is encouraged from all, where new voices are welcome, and where a diversity of opinion and participants is explicitly desired. We encourage respectful dissent, we value disagreement as a sign of creativity, and we try to steer that community towards better solutions to the many technical and governance problems the project deals with."
Perhaps also followed by the existing wording too.
cc/ @minrk @ellisonbg @fperez

pinging @fperez on this one.
When @cameronoelsen and I work on the website, I usually take passes on the actual content and its language. @cameronoelsen tries to fill in the content when he can, but I think he should focus on the visual design and work with us on the content side of things - especially for stuff like this.
@fperez you pinged me on this one at the start and I should have taken a stab and fixing the content myself but it dropped off my radar in my travels. Do you want to me to submit a PR with a potential fix or would you like to do that?

authors: cameronoelsen ellisonbg fperez minrk parente willingc


text:
Bump xterm.js version to 1.1.3

Major feature upgrade is that IMEs now work, so people
can type non-latin characters into them!
Also has:
Better mouse support
Signed releases
Scrollbar
https://github.com/sourcelair/xterm.js/releases/tag/1.1.3

Much obliged!

repo: jupyter/jupyterlab


text:
Selecting objects is not smooth

Sometimes even after clicking on an object 2-3 times the objects are not selected.
Potentially related to https://github.com/jupytercad/JupyterCAD/pull/542

I think that the system often confuses a simple 'click' with a 'click and hold'.

I think that the system often confuses a simple 'click' with a 'click and hold'.

Currently the very next click after panning is disabled, so when we want to select but it is also very likely that a very small panning/mouse movement has happened while or before clicking - it is leading one to click 2-3 or more times to select the object
We'll be on it how we can carve the logic to be smoother :)

Yeah it looks like my PR https://github.com/jupytercad/JupyterCAD/pull/542 is not handling that correctly in some cases.

Yeah it looks like my PR https://github.com/jupytercad/JupyterCAD/pull/542 is not handling that correctly in some cases.

It does not seem to be a question of time between the mousedown and mouseup, but rather than any (tiny) change of mouse position between when the mouse button is pressed and release prevents it to be considered as a click.

position between when the mouse button is pressed and release prevents it to be considered as a click

That's exactly what the implementation does in #542

Maybe we should count the number of pixels it has moved, and if it's less than a small amount of pixels (say 4), we consider it's a click

I'm not even convinced this is the only issue though.
There seems to be a wrong order of events that breaks the logic introduced in #542

Assigned this to myself to give a try (I might just be shooting in the dark at first 😅)

Adding a note that the introduction of the transform controls for object now brings another point of complexity.
The transform controls deselects the selected object after transform. We should try to prevent that.
The mamba-jambo with all those events is starting to get very difficult to track this clicking behavior. We need to think of a robust approach for this.

authors: SylvainCorlay arjxn-py martinRenou

repo: jupytercad/JupyterCAD


text:
Point binder to the branch

I think it will make more sense to spin binder on the PR branch than on a PR commit.

I think this makes perfect sense, given that this comment workflow is triggered on pull_request_target such as "Opened" rather every time there is a new commit. It would also make sense to make it only trigger on "Opened" rather than all of "opened", "assigned", "reopened", etc.
Thank you @fcollonval for contributing this improvement!

authors: consideRatio fcollonval

repo: jupyterhub/binder


text:
GitHub Actions

You can see the results of the Action runs on this branch here.
Looks like this was easier than I thought (yay for copying @sgibson91's workflows in mybinder.org-deploy!). This PR trades one Microsoft CI product (Azure pipelines) for another (GitHub actions). GitHub actions have more concurrency and capacity at the free tier, plus we don't have to manage a separate collection of permissions, which is a big plus.
includes #940
closes #941
Marked WIP for discussion, since we haven't actually decided to drop Azure, but this shows what it might look like.

I realized that the actions aren't running on this PR, so folks need a link to runs on my fork, which are here

I'd be happy to switch to GH Actions. The UI of the Azure pipelines confuses me (trying to find the button that lets me restart things is always a 5-10min exercise and sometimes I give up :( ) and the fact that I have to login to Azure with a separate account and don't get redirected back to where I was doesn't help. So a big 👍  from me.

One thing to keep in mind re: updating branches is when you turn on branch
protection GitHub surfaces a new button on PRs “update this branch with
master” that makes rebasing easy as a click for maintainers.  But, totally
get that we don’t want this in this project!  Just letting you know!
On Thu, Aug 13, 2020 at 12:14 AM Min RK notifications@github.com wrote:

@minrk commented on this pull request.

In .github/workflows/test.yml
https://github.com/jupyterhub/repo2docker/pull/942#discussion_r469744154
:

+on:

push

pull_request

I also agree with @manics https://github.com/manics that the
require-up-to-date rule is a contributor-busywork vs test rigor trade-off
that doesn't quite pay off for our projects, but I now know it's an option,
which is great, thanks @hamelsmu https://github.com/hamelsmu!
Thanks for everyone's input! This is super valuable, as there's always a
variety of good ways to work with these tools. If I understood the latest
comments correctly, I think we want to keep both pull_request and push
triggers. Does that means there isn't more to do on this front?
It would definitely be useful to jot down some of the notes about events
and what they mean and what downsides there are, e.g. summarizing from this
discussion:

pull_request builds merge commits, which is useful as other PRs are
merged

push events can be sufficient and may eliminate the benefit of
pull_request building merge if branches are required to be up-to-date

requiring branches to be up-to-date adds some work for contributors,
in exchange for ensuring that tests have been run with exactly what
will result after merge. Downside: extra work for contributors if
maintainers take a while to merge PRs, as authors keep needing to update
their branch while waiting for maintainers to review & merge

push may not trigger on close/reopen PR, which is a common "poke CI"
practice, especially for contributors who don't have access to the "re-run
CI button" (is this correct?)

push & pull_request together can result in fairly redundant builds
(HEAD and MERGE may differ slightly) when a PR is made from within the
target repo

avoiding redundant builds by restricting push triggers to the
default branch make it harder to test one's own forks without opening PRs
(I do this a lot, including in writing this PR!)

Does that sound right?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jupyterhub/repo2docker/pull/942#discussion_r469744154,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AALKJETYTSC552R5HBYYPPLSAOHFTANCNFSM4P3ARDMA
.

@hamelsmu I wasn't aware of that, definitely makes it a practical option! In the interests of getting this PR merged how about we keep the PR as it currently is, and make further changes in a followup? It's something we might want to discuss as a Team Compass issue so we don't end up with too many different CI and branch setups across the organisation.

By all means please don’t hold up this PR!  I was only commenting as an
FYI.  I think this PR is good to merge LGTM!
On Thu, Aug 13, 2020 at 7:28 AM Simon Li notifications@github.com wrote:

@hamelsmu https://github.com/hamelsmu I wasn't aware of that,
definitely makes it a practical option! In the interests of getting this PR
merged how about we keep the PR as it currently is, and make further
changes in a followup? It's something we might want to discuss as a Team
Compass issue https://github.com/jupyterhub/team-compass/issues so we
don't end up with too many different CI and branch setups across the
organisation.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jupyterhub/repo2docker/pull/942#issuecomment-673511938,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AALKJEVJK4DTL3MZJV2EQILSAP2BRANCNFSM4P3ARDMA
.

I'm learning a lot, @hamelsmu! Keep the insights coming :)

Merge?

authors: betatim hamelsmu manics minrk


text:
Move the kernel status plugin to its own repo

The notebook-extension currently has a plugin to show the kernel status in the menu area:
https://github.com/jtpio/jupyterlab-classic/blob/d6b870ad5b55a8362f9d1b890297216a53db2ce5/packages/notebook-extension/src/index.ts#L155-L210

This plugin could actually move to its own repo and be managed separately, so it could for example be installed as a prebuilt extension in JupyterLab too.
Also it might make more sense to have it in the notebook toolbar instead, next to the existing kernel status indicator:

Closing as we can keep it in the repo for now. If anyone would like to work on that feel free!

repo: jupyterlab/retrolab