Duplicate disks created

I've had the same issues with Proxmox 8 as a lot of people (like #882 and #863), but when I build this project locally from master and use that, then both these problems are solved. However, a new problem arises. The provider is supposed to increase the size of the 2G base image disk that I have, but instead, it seems like it just detaches that disk and creates a new empty one (with the correct size). This new disk is of course not bootable, and the terraform apply command stalls.

Any idea if this is a known problem? It didn't seem to me like a duplicate of any other open issues right now.
Proxmox: 8.1.3
Provider: local build of latest commit, https://github.com/Telmate/terraform-provider-proxmox/commit/a8675d3967710bab4ac08fad9dbc05eed3ae2c58

Cause pxapi.NewConfigQemuFromApi function now returns disks in  Disks *QemuStorages part of ConfigQemu struct. However, the code expects them in QemuDisks
Disks structure differs in format from QemuDisks QemuDevices
https://github.com/Telmate/terraform-provider-proxmox/blob/a8675d3967710bab4ac08fad9dbc05eed3ae2c58/proxmox/resource_vm_qemu.go#L1148C2-L1148C2

So have you found a solution to this problem? I'm guessing it's something that needs to be fixed with the provider, and not the .tf configuration I've used.

Unfortunately, it isn't very easy for me. ( insufficient knowledge of GoLang )
As I can see, it is necessary to rewrite a significant part of disk logic.

same problem from proxmox  8.1.3 thanks in advance

@mleone87 Anything new regarding this?

Having the same problem but with TheGameProfi/proxmox.
It seems defining file and volume fixes it but you need to know the id beforehand....
  disk {
    size    = "16G"
    type    = "scsi"
    storage = "vg_nvme"
    ssd     = 1
    file    = "vm-108-disk-0"
    volume  = "vg_nvme:vm-108-disk-0"
  }

Not sure how to go around this.

Having the same issue myself. For now, the provider seems to be unusable.

I was able to duplicate this issue in Proxmox 7.4-17 as well. This issue doesn't seem to be related to the version of Proxmox.
I don't think the issues is where [https://github.com/Telmate/terraform-provider-proxmox/issues/887#issuecomment-1868043544] pointed to because that line hasn't changed in 3 years.
I tried to find the exact commit where this stopped working so we could get a better idea of where the problem was introduced. Unfortunately, there are a lot of commits where the code doesn't compile, which made it difficult to see where the issue was introduced.  Here's the best I could do:

e51e787c3a792176a6401c2db1b15cb2a30449e0 has this problem
704db887ccbe636e2d97bafbc969eee56f99c13a did not have this problem

I spot checked the 24 commits in between and none of them compiled except a8675d3967710bab4ac08fad9dbc05eed3ae2c58, but that one failed because my VM name was var.fqdn and dots were not allowed in this version (which was fixed in the e51e787c3a792176a6401c2db1b15cb2a30449e0 commit, which is where I was able to reproduce this issue).
My two guesses for where the problem was introduced are:
I. commit 4a602733bbb5b767eeb79e1b27cf98665c904bb4, specifically the block starting on line 1066 which adds an additional disk. That change was merged into the default branch with https://github.com/Telmate/terraform-provider-proxmox/pull/732, or
II. commit d02bb5dba45bdb8e65ed58fccaa885fd6432e6fa, specifically the code block starting line 2202 which transforms a list of qemu devices (which includes disk drives).  This was merged into the default branch in https://github.com/Telmate/terraform-provider-proxmox/pull/866
Those guesses are listed in the order of where my gut tells me the issue lies. It's also possible that there was some change in some library that the provider uses, of which there are a ton of them and a lot of them were updated between when I could confirm this issue was not present and when I could reproduce this issue.
I was actually trying to investigate a issue https://github.com/Telmate/terraform-provider-proxmox/issues/704 when I came across this one, so I'm going to go back to trying to identifying the root cause of that issue. Hopefully my notes here will be helpful in someone getting to the bottom of this one before another release is cut.

Noticed my recent EFI changes were referenced here (#732). Happy to help debug as well.

Can someone provide steps to reproduce and/or proxmox_vm_qemu resource block? I cannot reproduce on Proxmox 8.0.4 / telmate master.
// before
disk {
  type    = "sata"
  size    = "60G"
  storage = "local-lvm"
  cache   = "writethrough"
  discard = "on"
}

// after
disk {
  type    = "sata"
  size    = "62G"
  storage = "local-lvm"
  cache   = "writethrough"
  discard = "on"
}

// plan
  # proxmox_vm_qemu.vm1011 will be updated in-place
  ~ resource "proxmox_vm_qemu" "vm1011" {
      ...
      ~ disk {
          ~ size               = "60G" -> "62G"
            # (27 unchanged attributes hidden)
        }

Target machine via Proxmox UI:

I am able to reproduce the issue with the small example below using a provider compiled from commit e51e787c3a792176a6401c2db1b15cb2a30449e0 (the latest as of right now):
# Define the usual provider things
terraform {
  required_providers {
    proxmox = {
      source = "registry.example.com/telmate/proxmox"
      version = ">=1.0.0"
      #source = "Telmate/proxmox"
      #version = "=2.9.11"
    }
  }
  required_version = ">= 0.14"
}

resource "proxmox_vm_qemu" "server" {
  name              = "test.example.com"
  target_node       = "ra"
  clone             = "debian-12"
  full_clone        = true
  os_type           = "cloud-init"
  cores             = 1
  sockets           = "1"
  cpu               = "host"
  memory            = 512
  scsihw            = "virtio-scsi-pci"
  bootdisk          = "virtio0"
  disk {
    size            = "20G"
    type            = "virtio"
    cache           = "writeback"
    storage         = "local-zfs"
  }
  network {
    model           = "virtio"
    bridge          = "vmbr0"
  }

  # Cloud Init Settings
  # Reference: https://pve.proxmox.com/wiki/Cloud-Init_Support
  ipconfig0 = "ip=<IP_ADDRESS>/22,gw=<IP_ADDRESS>"
  nameserver = "<IP_ADDRESS> <IP_ADDRESS>"
  sshkeys = file("${path.root}/test.pub")
}

I am testing against Proxmox 7.4-17. That created test.example.com with two disks: disk-0 (unused), and disk-1 (virtio0). It attempts to boot but just boot loops because it can't find any bootable media.

Hm, it's not clear if master remains compatible with Proxmox 7.x. Does this repro with the latest release? https://github.com/Telmate/terraform-provider-proxmox/tree/v2.9.14

Thanks! Can reproduce here now.

Looks like this has broken due to an upstream qemu disks overhaul (https://github.com/Telmate/proxmox-api-go/pull/255) as @everythings-gonna-be-alright suggested (tagging @Tinyblargon), which changed ConfigQemu.QemuDisks behavior. (I suspect the "deprecated" label is in error and it's really just gone/obsolete now.)
This may be expected churn for the master branch, so not faulting anyone here. We just need to do the work to bring the terraform provider back in alignment.

@riverar #794 was supposed to change this behavior when the functionality was changed in the upstream library. Due to some setbacks, this kept getting delayed.

@Tinyblargon Oh nice, I missed that PR. Thanks!

We are also hitting this problem with proxmox 8.1.3 and provider TheGameProfi/proxmox version 2.9.15

while debugging this issue I have realized that once I create a new qemu VM and I try terraform state show there is no disk section for the VM state and that's why the provider tries to add it again.
Weird that during the initial creation of the VM the disk is properly created in the right storage pool and with the right size defined in the terraform code but it's just not added to the terraform state

I can confirm that the code that @Tinyblargon wrote does fix this problem. I tested using the same small example that I posted earlier this week.
I've submitted a merge request with Tinyblargon's changes that can be applied cleanly to the HEAD of the default branch here in this repo. I'm pretty sure I've resolved all the merge conflicts correctly, and I have tested it to make sure it fixes this issue, but if anyone else would be willing and able to give it a review, I'd appreciate having a second pair of eyes on this.
And if anyone wants to just check out the code, compile it and verify that it fixes the issue, the code can be found here: https://github.com/hestiahacker/terraform-provider-proxmox/tree/overhaul-qemu-disks Having someone else reproduce my results would be good for avoiding that "works on my box" problem. :slightly_smiling_face:

I've also tested an updated terraform file which uses the new syntax for configuring multiple disks. This avoids a deprecation warning from being printed, which makes me happy. My updated terraform file is below.
# Define the usual provider things
terraform {
  required_providers {
    proxmox = {
      source = "registry.example.com/telmate/proxmox"
      version = ">=1.0.0"
      #source = "Telmate/proxmox"
      #version = "=2.9.11"
    }
  }
  required_version = ">= 0.14"
}

resource "proxmox_vm_qemu" "server" {
  name              = "test.example.com"
  target_node       = "ra"
  clone             = "debian-12"
  full_clone        = true
  os_type           = "cloud-init"
  cores             = 1
  sockets           = "1"
  cpu               = "host"
  memory            = 512
  scsihw            = "virtio-scsi-pci"
  bootdisk          = "virtio0"
  disks {
    virtio {
      virtio0 {
        disk {
          size            = 20
          cache           = "writeback"
          storage         = "local-zfs"
        }
      }
    }
  }
  network {
    model           = "virtio"
    bridge          = "vmbr0"
  }

  # Cloud Init Settings
  # Reference: https://pve.proxmox.com/wiki/Cloud-Init_Support
  ipconfig0 = "ip=<IP_ADDRESS>/22,gw=<IP_ADDRESS>"
  nameserver = "<IP_ADDRESS> <IP_ADDRESS>"
  sshkeys = file("${path.root}/test.pub")
}

@hestiahacker what should we do? are we have to wait until new version release?

I compiled the latest code and have been using that and it seems to have fixed this issue and #704. If you need a solution now, I'd suggest you take this route.
There are instructions for compiling from source but if you are compiling it on a Debian based machine, it'd look something like this:
git clone https://github.com/hestiahacker/terraform-provider-proxmox
cd terraform-provider-proxmox
git checkout overhaul-qemu-disks
sudo apt install -y ansible make
ansible-galaxy install gantsign.ansible-role-golang
ansible-playbook go.yml
. /etc/profile.d/golang.sh
make

At that point the new provider should be in the ./bin directory. If you aren't compiling it on your deployment machine, copy the executable over to the deployer. You'll need to copy the executable into a particular directory on the deployer. Here are the commands from the aforementioned installation guide:
PLUGIN_ARCH=linux_amd64
mkdir -p ~/.terraform.d/plugins/registry.example.com/telmate/proxmox/1.0.0/${PLUGIN_ARCH}
cp bin/terraform-provider-proxmox ~/.terraform.d/plugins/registry.example.com/telmate/proxmox/1.0.0/${PLUGIN_ARCH}/

That source path of the cp command will change if you are compiling on a different machine, but that should be easy enough. The last step is to tell Terraform to use this new module. That means updating your terraform to look like this:
terraform {
  required_providers {
    proxmox = {
      source  = "telmate/proxmox"
      version = ">=1.0.0"
    }
  }
  required_version = ">= 0.14"
}

That should work, but if you ever need to recompile it, terraform will complain about the checksum having changed. To deal with that you can either manually remove the offending checksum from the .terraform.lock.hcl file with a text editor, or what I personally do is just delete that lock file and regenerate it like so:
rm .terraform.lock.hcl && terraform get -update && terraform init -upgrade && terraform version

Also, do realize that this is the latest code that hasn't even been merged into this repo yet, and a fair amount has changed. So there's some risk of bugs causing you problems. I'd suggest you test the code in your environment and with your configuration even more than you would a new, official release. I've tested it in my environment, but if you're using different features than me, you could hit some code path that has a bug that I didn't run into.
If you are in an environment that has a low risk tolerance and you can't test this out, I have two suggestions:

Get a test environment! :scream:
Wait for the official release :grin:

@hestiahacker thanks for much for the instructions, I was able to follow them (which is saying something).
I'm not a developer and have only started using proxmox / terraform in the last few weeks.
I'm just "testing" this all out in my lab so I have nothing to loose if this all goes wrong.
previously, terraform would create a duplicate scsi disk as well as the virtio, further more each time you "apply" changes it would create another duplicate.
For example making a network device change etc, would result in another additional disk.
Anyway moving on.
I've followed your instructions, tested out, but I have a new error, which I've not seen before:
panic: interface conversion: interface {} is string, not float64

goroutine 52 [running]:
github.com/Telmate/proxmox-api-go/proxmox.NewConfigQemuFromApi(0xc0003e8718, 0xc9d509?)
        github.com/Telmate/proxmox-api-go@v0.0.0-20230319185744-e7cde7198cdf/proxmox/config_qemu.go:584 +0x4605
github.com/Telmate/terraform-provider-proxmox/proxmox.resourceVmQemuCreate(0xc0003be300, {0xb66f60?, 0xc0003d2e60})
        github.com/Telmate/terraform-provider-proxmox/proxmox/resource_vm_qemu.go:972 +0x2c4d
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).create(0xdd7840?, {0xdd7840?, 0xc0002f6570?}, 0xd?, {0xb66f60?, 0xc0003d2e60?})
        github.com/hashicorp/terraform-plugin-sdk/v2@v2.25.0/helper/schema/resource.go:695 +0x178
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).Apply(0xc0000e2ee0, {0xdd7840, 0xc0002f6570}, 0xc00037cc30, 0xc0003bf080, {0xb66f60, 0xc0003d2e60})
        github.com/hashicorp/terraform-plugin-sdk/v2@v2.25.0/helper/schema/resource.go:837 +0xa85
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).ApplyResourceChange(0xc0002e1ef0, {0xdd7840?, 0xc0002f6450?}, 0xc0001ef810)
        github.com/hashicorp/terraform-plugin-sdk/v2@v2.25.0/helper/schema/grpc_provider.go:1021 +0xe8d
github.com/hashicorp/terraform-plugin-go/tfprotov5/tf5server.(*server).ApplyResourceChange(0xc0001a0500, {0xdd7840?, 0xc000525b60?}, 0xc00043fdc0)
        github.com/hashicorp/terraform-plugin-go@v0.14.3/tfprotov5/tf5server/server.go:818 +0x574
github.com/hashicorp/terraform-plugin-go/tfprotov5/internal/tfplugin5._Provider_ApplyResourceChange_Handler({0xc6bc20?, 0xc0001a0500}, {0xdd7840, 0xc000525b60}, 0xc00043fd50, 0x0)
        github.com/hashicorp/terraform-plugin-go@v0.14.3/tfprotov5/internal/tfplugin5/tfplugin5_grpc.pb.go:385 +0x170
google.golang.org/grpc.(*Server).processUnaryRPC(0xc00019a1e0, {0xddb420, 0xc0003144e0}, 0xc000515680, 0xc0002edce0, 0x128f7a0, 0x0)
        google.golang.org/grpc@v1.53.0/server.go:1336 +0xd23
google.golang.org/grpc.(*Server).handleStream(0xc00019a1e0, {0xddb420, 0xc0003144e0}, 0xc000515680, 0x0)
        google.golang.org/grpc@v1.53.0/server.go:1704 +0xa2f
google.golang.org/grpc.(*Server).serveStreams.func1.2()
        google.golang.org/grpc@v1.53.0/server.go:965 +0x98
created by google.golang.org/grpc.(*Server).serveStreams.func1
        google.golang.org/grpc@v1.53.0/server.go:963 +0x28a

Error: The terraform-provider-proxmox_v2.9.14 plugin crashed!

This is always indicative of a bug within the plugin. It would be immensely
helpful if you could report the crash with the plugin's maintainers so that it
can be fixed. The output above should help diagnose the issue.

I've not changed any of the .tf files so either I have a miss-configuration or as you mentioned somewhere, there is potential for errors.
thanks again for your efforts.

Okay Ignore the above, I made a couple of mistakes, I'll post here incase others do the same thing.
I forgot to update my providers file
 proxmox = {
      source = "registry.example.com/telmate/proxmox"
      version = ">=1.0.0"
    }

then follow instructions to clean the lock file

I also needed to update my terraform file, so I changed
#  disk {
#    storage = "toaster-vm"
#    type = "scsi"
#    size = "12G"
#  }

disks {
    virtio{
      virtio0 {
        disk {
        size = 12
        storage = "toaster-vm"
        }
      }
    }
  }

I can confirm working now. I have a LCX container, Rocky8 and 9 and Ubuntu VM's all working within the same plan
For completeness I did the following
I had to run the compile as root, I kept getting ansible/golang errors (built using a LCX container so might have something to do with it)
I copied the complied plug-in from /tmp/{compile directory} to my terraform directory (not my home dir)
Change the provider file and then follow instructions to fix the lock
then modify the .tf file(s) for the disk declaration.
However when I changed the plan (made a modification to the description)
It made some modifications
~ disks {
          - ide {
            }
          ~ virtio {
              ~ virtio0 {
                  ~ disk {
                        id                   = 0
                      - replicate            = true -> null
                        # (18 unchanged attributes hidden)
                    }
                }
            }
        }

The disk is not duplicated but has a replication flag ?

Hey!
I followed the issue as I'm also impacted since I upgraded Proxmox to v8.1.3.
Following instructions to build the latest version of the provider, I can now start a VM without error. However, I can see the configuration is not the same as previously and expected. It seems the "cloud init" disk is not mounted.
Before:

After:

What is wrong here:

Disk size is 10G, which is the size of the template. It should have been overridden (it worked before)
There is no cloud init drive
Hard disk has additional parameters which did not have before

@Tchoupinax I've ran a few tests on my end could you try the version in #892 as this has the latest patches.

Hey @Tinyblargon,
I tested your branch and it fixes my previous three issues. I wrote a comment here.
Thank you a lot for your work!

@TheGameProfi do you plan to publish a new version in your repository including this fix?

thanks @TheGameProfi for publishing a release to terraform registry including this fix. Much appreciated!

thanks @TheGameProfi for publishing a release to terraform registry including this fix. Much appreciated!

But there is no new version on the hashicorp registry? Or is it published under some other name than Telmate?

thanks @TheGameProfi for publishing a release to terraform registry including this fix. Much appreciated!

But there is no new version on the hashicorp registry? Or is it published under some other name than Telmate?

It is published as a fork under my own name, thegameprofi/proxmox
There are multiple version with unreleased changes from this repo.
But also, at least the newest version, has problems mounting a cloud-init drive
#901

Hi!
Check work RC v3.0.1-rc1 on Terraform 1.6.6 / 1.7.1 with ProxMox 8.0.4 / 8.1.3.
The error is gone. Everything works well.
Thanks to all!

I've also verified that v3.0.1-rc1 is able to deploy the small example without any problems.
Thank you all for the testing, fixing, and releasing. :slightly_smiling_face:

i still have this problem with 3.0.1-rc1 and pve 8.1.3, on clone from a template i still get 2 disks and the vm won't boot
what can i do to avoid that 2 disks being created ?

thank you. i have tried further and by chance i found, that when setting the disk size in terraform file to exactly match the size of the disk in vm template, then it won't happen and the disk isn't getting duplicated.
weird.

Having the same problem but with TheGameProfi/proxmox. It seems defining file and volume fixes it but you need to know the id beforehand....
  disk {
    size    = "16G"
    type    = "scsi"
    storage = "vg_nvme"
    ssd     = 1
    file    = "vm-108-disk-0"
    volume  = "vg_nvme:vm-108-disk-0"
  }

Not sure how to go around this.

@ihatethecloud   I wanted to  try this workound but its failing at parameter verification. I'm using zfs though, not sure is it related or not.
latest version of TheGameProfi/proxmox
proxmox version 8.1.4
file    = "vm-137-disk-0"
volume  = "local-zfs:vm-137-disk-0
am i doing something wrong ?

Having the same problem but with TheGameProfi/proxmox. It seems defining file and volume fixes it but you need to know the id beforehand....
  disk {
    size    = "16G"
    type    = "scsi"
    storage = "vg_nvme"
    ssd     = 1
    file    = "vm-108-disk-0"
    volume  = "vg_nvme:vm-108-disk-0"
  }

Not sure how to go around this.

@ihatethecloud I wanted to try this workound but its failing at parameter verification. I'm using zfs though, not sure is it related or not.
latest version of TheGameProfi/proxmox proxmox version 8.1.4
file = "vm-137-disk-0" volume = "local-zfs:vm-137-disk-0
am i doing something wrong ?

Don’t use TheGameProfi/proxmox. Build this repo if it has not been pushed to the registry yet.

Having the same problem but with TheGameProfi/proxmox. It seems defining file and volume fixes it but you need to know the id beforehand....
  disk {
    size    = "16G"
    type    = "scsi"
    storage = "vg_nvme"
    ssd     = 1
    file    = "vm-108-disk-0"
    volume  = "vg_nvme:vm-108-disk-0"
  }

Not sure how to go around this.

@ihatethecloud I wanted to try this workound but its failing at parameter verification. I'm using zfs though, not sure is it related or not.
latest version of TheGameProfi/proxmox proxmox version 8.1.4
file = "vm-137-disk-0" volume = "local-zfs:vm-137-disk-0
am i doing something wrong ?

Don’t use TheGameProfi/proxmox. Build this repo if it has not been pushed to the registry yet.

If you mean :
source = "Telmate/proxmox"
version = "3.0.1-rc1"
With this version its still creting empty disks and causing unbootable vm's with or without previous workaround.  Am i using wrong branch ? If so which branch/version i should create  ?  Again thank you for your help.

Having the same problem but with TheGameProfi/proxmox. It seems defining file and volume fixes it but you need to know the id beforehand....
  disk {
    size    = "16G"
    type    = "scsi"
    storage = "vg_nvme"
    ssd     = 1
    file    = "vm-108-disk-0"
    volume  = "vg_nvme:vm-108-disk-0"
  }

Not sure how to go around this.

@ihatethecloud I wanted to try this workound but its failing at parameter verification. I'm using zfs though, not sure is it related or not.
latest version of TheGameProfi/proxmox proxmox version 8.1.4
file = "vm-137-disk-0" volume = "local-zfs:vm-137-disk-0
am i doing something wrong ?

Don’t use TheGameProfi/proxmox. Build this repo if it has not been pushed to the registry yet.

version = "3.0.1-rc1" is out from telmate provider.
new version comes with different disk schema, I had to update my disk schema in tf file, now it works. its still has some glitches regarding disk type/controller though. anway thx to everyone !
ps:if someone needs a running example with clone_ _from_template+cloudinit+lvm/zfs can ping me.

Could you give me working example? I can't get mine to work as I get an unbootable disk error and the hardware settings are incorrect.

Having the same problem but with TheGameProfi/proxmox. It seems defining file and volume fixes it but you need to know the id beforehand....
  disk {
    size    = "16G"
    type    = "scsi"
    storage = "vg_nvme"
    ssd     = 1
    file    = "vm-108-disk-0"
    volume  = "vg_nvme:vm-108-disk-0"
  }

Not sure how to go around this.

@ihatethecloud I wanted to try this workound but its failing at parameter verification. I'm using zfs though, not sure is it related or not.
latest version of TheGameProfi/proxmox proxmox version 8.1.4
file = "vm-137-disk-0" volume = "local-zfs:vm-137-disk-0
am i doing something wrong ?

Don’t use TheGameProfi/proxmox. Build this repo if it has not been pushed to the registry yet.

version = "3.0.1-rc1" is out from telmate provider.
new version comes with different disk schema, I had to update my disk schema in tf file, now it works. its still has some glitches regarding disk type/controller though. anway thx to everyone !
ps:if someone needs a running example with clone_ _from_template+cloudinit+lvm/zfs can ping me.

Could you give me working example? I can't get mine to work as I get an unbootable disk error and the hardware settings are incorrect.

`# Source the Cloud Init Config file
data "template_file" "cloud_init_jammy_test-converter01" {
template  = "${file("${path.module}/files/cloud_init_jammy-lite.cloud_config")}"
vars = {
ssh_key = file("files/terraform-pve.pub")
hostname = "test-converter01"
domain = "test-domain.fqdn"
}
}
##########################################################################################################################################################################################################
Create a local copy of the file, to transfer to Proxmox
resource "local_file" "cloud_init_jammy_test-converter01" {
content   = data.template_file.cloud_init_jammy_test-converter01.rendered
filename  = "${path.module}/files/user_data_cloud_init_jammy_test-converter01.cfg"
}
##########################################################################################################################################################################################################
Transfer the file to the Proxmox Host
resource "null_resource" "cloud_init_jammy_test-converter01" {
connection {
type    = "ssh"
user    = "root"
private_key = file("files/terraform-pve")
host    = "pve01"
}
##########################################################################################################################################################################################################
provisioner "file" {
source       = local_file.cloud_init_jammy_test-converter01.filename
destination  = "/var/lib/vz/snippets/cloud_init_jammy_test-converter01.yml"
}
}
##########################################################################################################################################################################################################
#Define virtual machine's specs as variables
variable "test-converter01" {
type = map(string)
description = "Vm variables must be declared here"
default = {
"proxmox_node" = "pve01"
"vm_id" = "151"
"name" = "test-converter01"
"domain" = "dev fqdn"
"desc" = "test-converter "
"clone_name" = "jammy-cloudinit"
"os_type" = "cloud-init"
"onboot_status" = "true"
"cpu_type" = "host"
"sockets" = "2"
"cores" = "2"
"mem" = "2048"
"network0_model" = "virtio"
"network0_bridge" = "vmbr2"
"network0_mac" = ""
"network0_IP" = "ip=192.168.X.X/16,gw=192.168.X.X" # this sets for nat ip from proxmox
"network1_model" = "virtio"
"network1_mac" = "mac of your vm"
"network1_IP" = "ip=dhcp"
"network1_bridge" = "vmbr1"
"storage_class" = "local-zfs"
"storage_interface" = "virtio"
"disk0_size" = 30
#"disk1_size" = "50G"
}
}
##########################################################################################################################################################################################################
resource "proxmox_vm_qemu" "test-converter01" {
depends_on = [
null_resource.cloud_init_jammy_test-converter01

]
target_node = var.test-converter01.proxmox_node
vmid = var.test-converter01.vm_id
name = var.test-converter01.name
desc = var.test-converter01.desc
vcpus = 2 # it will calculated by proxmox socket*core
os_type = var.test-converter01.os_type
onboot = var.test-converter01.onboot_status
clone = var.test-converter01.clone_name
agent = 1
qemu_os = "l26"
scsihw = "virtio-scsi-single"
cloudinit_cdrom_storage = "local-zfs"
cores = var.test-converter01.cores
sockets = var.test-converter01.sockets
cpu = var.test-converter01.cpu_type
memory = var.test-converter01.mem
 network {

     model  = var.test-converter01.network0_model
     bridge = var.test-converter01.network0_bridge

 }
network {

    bridge = var.test-converter01.network1_bridge
    model  = var.test-converter01.network1_model
    macaddr = var.test-converter01.network1_mac
}
lifecycle {
  ignore_changes = [
    network
  ]

}
disks {
virtio {
virtio0 {
disk {
storage = var.test-converter01.storage_class
size = var.test-converter01.disk0_size
}
}
}
}
cicustom = "user=local:snippets/cloud_init_jammy_test-converter01.yml"
ipconfig0 = var.test-converter01.network0_IP
ipconfig1 = var.test-converter01.network1_IP
}`

not stale

/keep open


WEB-3560: Creating a rudimentary local preview [WIP]

Allows team members to get a rough idea of what their work will look like on the web.

@roelbondoc This is pretty much ready for review (there may be some additional styling on the index page)
The idea is that I'll add a script to each of the book repos that will start this server, and watch the book source directory for changes. It auto-reloads the currently viewed page whenever it changes.
Edith pulled the styles from carolus. The view isn't identical, but is hopefully enough to placate authors for now.


feat: added kedaAutoscaling for jobs in cronjob chart

Added keda authoscaling option for job/cronjob chart

Please add migration for this newer version


Module compiled with Swift 2.3 cannot be imported in Swift 3.0.1

Hi,
Getting an "Module compiled with Swift 2.3 cannot be imported in Swift 3.0.1" error when importing Alamofire.
I have 4.2 installed via Carthage and working in xcode 8.1, swift 3, brand new project.
What am I missing?
Thanks

You can't use frameworks using Swift 2.3 and 3.0 in the same project. Make sure your project is set to use Swift 3.
Otherwise, we use our GitHub project for bug reports and feature requests. In the future, you should open questions like this on Stack Overflow and tag alamofire.
Cheers. 🍻

From our Contribution Guidelines
Asking Questions
We don't use GitHub as a support forum. For any usage questions that are not specific to the project itself, please ask on Stack Overflow instead. By doing so, you'll be more likely to quickly solve your problem, and you'll allow anyone else with the same question to find the answer. This also allows maintainers to focus on improving the project for others.


Added initial DialogWindow template.

This is a simple intro for a DialogWindow item template.  It could be improved later with additional common features and possibly MVVM support, but wanted to keep simple for now.

This is fantastic. Thank you!!


Possible to add Alexa skill as a trigger for a lambda?

In normal Serverless it's one line of YAML to add an Alexa trigger: https://www.serverless.com/framework/docs/providers/aws/events/alexa-skill
Is it possible to do this with sst?

Hey @mostthingsweb, I shared a snippet in Slack. Let me repost it here:
I found this helper construct from AWS. Save it to ur local and use it like this:
import { Skill } from "./Skill";

const fn = new sst.Function(this, 'SkillFn', { ... });

const skill = new Skill(this, 'Skill', {
  endpointLambdaFunction: fn,
  skillPackagePath: 'src/skill-package',
  alexaVendorId,
  lwaClientId,
  lwaClientSecret,
  lwaRefreshToken,
});

Here’s the full example from AWS blog. It’s similar to the above code. Instead of the PythonFunction, we are using sst.Function to use Live Lambda Dev.

As @fwang and I discussed on Slack, what I was really looking for was just the ability to add an Alexa skill as the trigger for a lambda, not actually create the skill itself with SST. This snippet you gave me works:
import * as iam from "aws-cdk-lib/aws-iam";

const fn = new sst.Function(stack, "SkillFn", { ... });

fn.addPermission('Skill Invocation', {
  principal: new iam.ServicePrincipal('alexa-appkit.amazon.com'),
  eventSourceToken: "amzn1.ask.skill.xx-xx-xx-xx-xx",
});

Would also be useful to support / document Alexa smart home integration as well. Here's how Serverless Framework does it: https://github.com/serverless/serverless/blob/main/lib/plugins/aws/package/compile/events/alexa-smart-home.js. Basically the same as above, just with different principal and eventSourceToken.

@mostthingsweb thanks for updating it here.
Btw, the above code allows the skill to invoke the Lambda, but how are you telling the skill which Lambda to invoke? I'm not too familiar with skill, are you setting that manually in the AWS Console?


Expose resource requests and limits for DIND container

This exposes the resource limit and requests for the Docker in Docker
container in the helm chart.
Don't deploy this to mybinder.org without first discussing what sensible default for these limits and requests should be. Then adjusting/reviewing jupyterhub/mybinder.org-deploy#491 and then merging and deploying this.

ping on this - I was chatting with @yuvipanda today and we thought DIND was causing problems, so I opened https://github.com/jupyterhub/mybinder.org-deploy/issues/549 . However I just realized we already have this PR open and it seems close to ready! What's the blocker here?

The blocker was that we/I couldn't work out how much memory DIND was really using. We discussed several different metrics but my feeling was we never concluded how much DIND really uses, which metrics are misleading (because containers) and whether we should set the limit to what we think DIND really uses or some inflated number because that is what k8s uses to check.

I think it's ok to pick a number and go from there :)
I've several orthogonal hypothesis! Kubernetes only knows about memory that
you've explicitly requested and limited - so you need to give it some
limit / request. Otherwise a process can go out of control, and cause OOMs
in other unrelated processes (which is happening)
On Fri, Apr 6, 2018 at 11:34 PM, Tim Head<EMAIL_ADDRESS>wrote:

The blocker was that we/I couldn't work out how much memory DIND was
really using. We discussed several different metrics but my feeling was we
never concluded how much DIND really uses, which metrics are misleading
(because containers) and whether we should set the limit to what we think
DIND really uses or some inflated number because that is what k8s uses to
check.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jupyterhub/binderhub/pull/472#issuecomment-379436520,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB23lDhTnTzzqd2LAw5W7Mjx7gT7onHks5tmF4PgaJpZM4SUC-Z
.

--
Yuvi Panda T
http://yuvi.in/blog

Changed the default to no limit.


Feature/pwa

@mrzhdev , sorry for my 2 PRs (this and https://github.com/mrzhdev/BlazorViz/pull/1), they were targeted at my personal repo.I think you should revert at they completely change yours


sqlite3.IntegrityError: UNIQUE constraint failed

Hey everybody,
When trying to run the following script:
import sys
sys.path.append('C:/Github/opengrid')

from opengrid.library.houseprint import houseprint
import pandas as pd
from datetime import datetime

start = pd.Timestamp(datetime(2017, 1, 1, 00, 00))
end = pd.Timestamp(datetime(2018, 2, 15, 00, 00))

hp = houseprint.Houseprint()
hp.sync_tmpos()

I get the following error:

Connected to pydev debugger (build 172.3968.37)
Opening connection to Houseprint sheet
Opening spreadsheets
Parsing spreadsheets
35 Sites created
36 Devices created
102 sensors created
Houseprint parsing complete
Backend TkAgg is interactive backend. Turning interactive mode on.
Using tmpo database from /data\tmpo\tmpo.sqlite3
1%|          | 1/102 [00:00<00:12,  8.20it/s]
Traceback (most recent call last):
File "C:\Program Files\JetBrains\PyCharm Community Edition 2017.2.3\helpers\pydev\pydevd.py", line 1599, in
globals = debugger.run(setup['file'], None, None, is_module)
File "C:\Program Files\JetBrains\PyCharm Community Edition 2017.2.3\helpers\pydev\pydevd.py", line 1026, in run
pydev_imports.execfile(file, globals, locals)  # execute the script
File "C:/Github/opengrid/opengrid/michel_script/test.py", line 14, in
hp.sync_tmpos()
File "C:\Github\opengrid\opengrid\library\houseprint\houseprint.py", line 489, in sync_tmpos
tmpos.sync(sensor.key)
File "C:\Users\mfr.virtualenvs\opengrid\lib\site-packages\tmpo_init_.py", line 154, in wrapper
raise e
sqlite3.IntegrityError: UNIQUE constraint failed: tmpo.sid, tmpo.rid, tmpo.lvl, tmpo.bid

Process finished with exit code 1
Any idea what I did wrong? :)

Probably related to issue : https://github.com/flukso/tmpo-py/issues/20

First off: Seems like you are running some old code, because the Houseprint module has been moved to opengrid-dev a few months ago.
But that shouldn't be an issue.
TMPO has a quirk where sometimes data is corrupted and you get this error when syncing. The only solution I've found is to delete data and try to sync again:
hp.tmpos.reset()
hp.sync()

or if that doesn't work
hp.tmpos.remove()
hp.init_tmpo()
hp.sync()

If you get an error that tmpo doesn't have a method called reset or remove, don't forget to update tmpo to the latest version.

Hey Jan, Thanks for the quick reply.
I switched to opengrid-dev. Thanks for the info.
Here is what I get when I execute each of the line:

My version of tmpo is 0.2.10
By the way, I run the script on python 2.7.13

Ah rats, you need to supply the sensorid for it to be reset...
Let's do the sync manually, try this:
from opengrid_dev.library.houseprint import houseprint
import tmpo
from sqlite3 import IntegrityError

hp = houseprint.Houseprint()
tmpos = tmpo.Session()

for sensor in hp.get_fluksosensors():
    tmpos.add(sensor.key, sensor.token)
    try:
        tmpos.sync(sensor.key)
    except IntegrityError:
        tmpos.reset(sensor.key)
        tmpos.sync(sensor.key)

hp.init_tmpo(tmpos=tmpos)

Great, my tmpo has been updated now!

You could also just delete the tmpo.sqlite3-file and run the sync again. That way you start from scratch.
You can find out where it is saved in hp.tmpos.db

For information, I tried to delete all files coming from hp.tmpos.db but didn't help. I still get the same issue.

Ok, I'm a bit out of ideas... Maybe you could go find @saroele and troubleshoot with him?


Titlebar color doesn't match system theme (macOS)

Unlike in the C version of raylib which does this automatically, the c#/dotnet version of raylib does not automatically set the window titlebar color to fit the system theme. Instead, it's stuck on the light theme

The bindings call into raylib to create the window so I don't see why there would be a C# issue as it should be created the same way. I do not have access to macOS so I cannot test this myself. At a guess maybe there is a difference in the raylib versions.

@ChrisDill Well then I am guessing that it may be a .NET Core related thing


product vs activity_id vs source_type

We have 3 elements with very similar information at the moment, that we would need to clarify, as they affect the discussion in #19 and on how to split the tables across activity_ids. I open a new thread just to rethink about them. In the current archiving specs, there are these examples (I added other potential values in parenthesis if we plan to encompass approaches beyond dynamical downscaling):
product = model-output, esd-output (, adjust-output, emul-output)
activity_id = RCM, ESD, FPS, Adjust
source_type = RCM, AGCM, RESM (, ESD, BA, RCM-emul, )

The product element, which used to be just "output", has been dropped from the DRS directory hierarchy for CORDEX-CMIP6, and it appears only as a global attribute. As such, it is currently harmless, although one might argue that ESD models are also models and would be covered by the model-output.
The activity_id is apparently very similar to the source_type but, as an activity, RCM refers to the "main" CORDEX-CMIP6 activity, focused on continental-scale domains and, in this case, approached by means of dynamical downscaling, typically using RCMs. ESD refers to the CORDEX-ESD activity (no final protocol, yet, but see the white paper). FPS refers to the CORDEX Flagship Pilot Studies, which are different initiatives (activities), which might require different CVs and tables. In this case, the values of the activity_id should list specific FPSs (FPS-URB-RCC, FPS-ELVIC, ...). This would have the benefit of fixing the different depth of the directory tree for FPSs as currently proposed:
/cordex/cmip6/rcm/AFR-25/ …
/cordex/cmip6/esd/AFR-25/ …
/cordex/cmip6/fps/fps-urb-rcc/PAR-3/ ...

Just for completeness, Adjust refers to the CORDEX-Adjust initiative, which applied bias adjustment techniques to some variables of the "RCM" activity in CORDEX-CMIP5. The naming RCM and ESD can be confusing as values for this element, since RCMs and ESD are also commonly used in FPSs. For ESD, it could be renamed "CORDEX-ESD" but, unfortunately, the main CORDEX activity so far on continental-scale domains using dynamical downscaling has never been assigned an acronym. Would it make sense to make one up now (CORDEX-DD, CORDEX-CDD, ...)? Or it would never be adopted at this stage?
Finally, source_type is the clearest of the three, but we might enter into problems when defining an RESM and all the coupling possibilities. For instance, it currently defines:
https://github.com/WCRP-CORDEX/cordex-cv/blob/e45a9ff5e569d9e610f9b44536735c6c22dd6072/CORDEX_source_type.json#L3
but, without coupling to the ocean, there are now a few components typically coupled, such as river routing or 3D subsurface water transports. I guess we could just wait for the registration of the models and let the modelling groups discuss whether the existing types are OK or whether they should be redefined to accommodate for their models. For reference, CMIP6 defines
https://github.com/WCRP-CMIP/CMIP6_CVs/blob/0fdb15e6/CMIP6_source_type.json#L3-L12
Most of them are individual components and, interestingly, they avoid to define an ESM type.

The activity_idelement should separate different CORDEX products with different DRS and search facets at an upper level, easier to manage under the same  /cordex/cmip6 instead of creating many new projects on ESGF. Suggested values  activity_id = RCM, ESD, FPS, Adjust were provided as examples. Indeed both RCM and ESD can be used in FPS, although I don't know about a FPS that includes both. DD can be used instead of RCM as  general definition for dynamical downscaling and ESD for statical one ? RCM is simply well known acronym and for example used as a search facet for CORDEX-CMIP5 - "RCM Model" :-).
How to deal with a FPS that potentially may include both DD and ESD is another question.
As we know there is no clear definition of RESM so here we may still use simply RCM and then the components provide more details.

Actually, regarding FPS, activity_id can be also defined for different products in the same FPS.
/cordex/cmip6/fps/fps-urb-rcc/dd/PAR-3/ ...
/cordex/cmip6/fps/fps-urb-rcc/esd/PAR-3/ ...

OK, if different activities can have different DRS, including different folder depth, this is OK. But what element would be the fps-urb-rcc in your example? If we leave just "FPS" as activity_id, we'll need another element for the FPS names themselves (fps_id?). If we restrict the scope of this DRS to the activity_id, we could simply keep adding new values as new FPSs are endorsed, and each new activity should care to define the corresponding DRS beyond the activity_id part (e.g. promoting the product element back to the DRS, as in your example with dd and esd as next folder).
Regarding the different products in the same FPS, FPS-SESA for instance has RCM and ESD models, but this output is not likely going to ESGF. I can imagine though that soon several FPSs will have e.g. RCM and RCM-emulated output.

fps_id as part of DRS sounds like good idea and should be complemented by fps_name as a global attribute

Yes, here we have activity_id=fps as an upper level and then we need again activity_id=dd or rcm and activity_id=esd to separate products with different DRS ...

Actually, regarding FPS, activity_id can be also defined for different products in the same FPS.
/cordex/cmip6/fps/fps-urb-rcc/dd/PAR-3/ ...
/cordex/cmip6/fps/fps-urb-rcc/esd/PAR-3/ ...

I think we need first to focus on RCM/DD (the highest priority), then ESD (input from the CORDEX-ESD community is necessary) and then on all other "activities" (FPS, Adjust, Index, etc.).

Regarding source_type for activity_id = DD, just for example something like this:
ARCM (atmospheric regional climate model, including a land model)
OGCM (ocean regional climate model, including a sea-ice model)
AORCM (atmosphere-ocean regional climate model)
VRGCM (variable resolution global climate model)
DVM (dynamic vegetation model)
LM (lake model)
RM (river model)
...

Similar to CMIP6 source_type can be a combination of the above values, e.g
product = model-output
activity_id = DD
source_type = ARCM LM DVM

Defining all acronyms can be a challenge but this CV can be extended when necessary.

Back to this Pandora's box, I provide some examples of future potential activities / experiments:

FPS-LUCAS might need experiments considering e.g. changing land-use scenarios
FPSs such as SESA or URB-RCC consider different evaluation experiments for short periods (a few years, a few months)
A potential CORDEX-CORE-12 might consist of a subset of the existing CORDEX-CMIP6 continental-scale downscaling for a set of RCMs downscaling all domains for a common set of GCMs
With the proliferation of RCMs coupled to different components, even if not under any official coordinated activity, if might be useful to consider the set of simulations providing coupled and uncoupled counterparts.
Within EURO-CORDEX, there is a "balanced-matrix" experiment with statistically-designed GCM-RCM-scenario combinations

Some of these cases can be handled by a mix of different source_ids (e.g. when considering a changing land use, change the name of the model) and activity_participation (e.g. have the default land use in "DD" and "FPS-LUCAS", and the changing land-use only in "FPS-LUCAS"). This would need to promote each FPS to the level of activities, instead of having them under a general "FPS" activity. Also, activity_participation is part of the registration process, but is not a required global attribute (activity_id could become a list, though). Even if a source_id is registered to participate in e.g. DD and CORDEX-CORE-12, it does not mean that all simulations from that source_id will be part of CORDEX-CORE-12 (it could additionally be used to run some coarser domain or downscale some GCM/scenario not in the CORDEX-CORE-12 design).
Another approach would be defining experiments within the activities. These are special subsets of simulations with some design so that they can be analysed together. These could be nested, with a grand-experiment encompassing the whole activity, or even overlapping across activities. What we call a domain in CORDEX-DD is already a kind of experiment within the activity. In CMIP6, there is a scenarioMIP activity, and the experiments are "let's use the forcing from SSP1-2.6 or that from SSP3-7.0". In CORDEX, there is the DD activity on continental-scale domains and the experiments are "let's focus the domain on the African continent, or on central America".
A differential thing with respect to the experiments in CMIP6 in some of the examples above is that they should not be promoted to the filename. Otherwise, there should be copies of the same files with different names to account for the different experiments they contribute to. They could be enumerated in their (say) experiment_id as a global attribute, and it could be used as a search facet. I'm thinking specifically in the existing problem to locate currently the CORDEX-CORE simulations on ESGF. One must know in advance which simulations compose this balanced ensemble. Other subsets of simulations to come (e.g. the balanced ensemble from EURO-CORDEX-CMIP6) will suffer the same problem.
This is just some thinking for the future...

It's very dangerous to open Pandora's box again :-). It's clear that CORDEX can have many products of different kind and would be good not mixing them. Potential CORDEX-CORE activity at 12.5km basically follows the DD activity, the same protocol. It's only a predefined subset of the driving CMIP6 models (nothing against in the protocol) and smaller subset of the variables. I would still consider CORDEX-CORE under the DD activity. If a group has already downscaled at 12.5km some GCMs that will be later defined as CORDEX-CORE ones and published downscaled output on ESGF under the DD activity re-publishing these simulations under another activity as CORDEX-CORE is  redundant.

Regarding source_type,  there is a couple of  comments on the SOD
i) "Will AOGCM be supported for coupled stretched grid models?"
ii) "starting a list with ARCM and AORCM is dangerous to me as there is no clear definition of the different family of RCMs. This opens the doors to long debates for definition and is a source of missunderstanding for the users. See my talk at the CORDEX conference for the definition of RESM. My vision would be to define here only HRGCM (if allowed in CORDEX), VRGCM and LAM and to have another  free format attribute to detail the list of components represented explicitely in the model. For example at CNRM, we will use a model with a representatio of the surface hydrology and of the aerosols for EURO-CORDEX but without ocean coupling. So it does not enter either in ARCM or AORCM and I would prefer to avoid the use of RESM as explained in my CORDEX talk as human is not really represented in such model."
ARCM and AORCM and AGCM in CORDEX-CMIP6_source_type.json were our first classification that is not enough to cover all regional and global models.

I don't think "source_type" should define the grid resolution or structure. (Hence HRGCM, VRGCM and LAM would not be appropriate source_type)
i) AOGCM does not specify any grid structure, so I don't see any problem with it including coupled stretched grid models.
ii) ARCM does not preclude hydrology or aerosols, it does not specify the existence or complexity of any submodels of processes on the land or in the atmosphere. I guess some statement to this effect could be added to the definition.  AORCM differs through the inclusion of a coupled regional ocean model. I think these two are broad but still useful source_types

Basically yes, in CMIP6 the global attribute grid provides description about grids, resolution and remapping issue25 while  source_type provides a general classification CMIP6_source_type.json that can be also a combination of several source_type values. For the simplicity we can go with 4 source types now (ARCM, AORCM, AGCM and AOGCM) and explanations that a RCM with additional components (e.g. aerosol, lakes, rivers etc.) but without an ocean model is still ARCM. Currently, we have source (full model name/version),  source_id (model identifier),  source_type(model configuration) and grid (grids, resolution, remapping). These 4 attributes should be enough to provide basic information about a model and all other details should be in documentation. We may add a new attribute (e.g. source_components) listing all model components similar to source in CMIP6. I think it was already discussed,  although, may be not always relevant for ESD.

We can add "AOGCM": "atmosphere-ocean global climate model including variable resolution" to CORDEX-CMIP6_source_type.json. These 4 source types (ARCM, AORCM, AGCM and AOGCM) are enough to start.

I added "AOGCM ... "


Uninstalling GPGTools fails

General troubleshooting steps

[x] I have checked the instructions for reporting bugs (or making requests) before opening the issue.

[x] None of the templates was appropriate for my issue, or I’m not sure.

[x] I ran brew update-reset && brew update and retried my command.
[x] I ran brew doctor, fixed as many issues as possible and retried my command.
[x] I understand that if I ignore these instructions, my issue may be closed without review.

Description of issue
Running brew cask uninstall gpgtools results in an error and fails
Output of your command with --verbose --debug
brew cask uninstall gpgtools --verbose --debug
==> Uninstalling Cask gpgtools
==> Uninstalling Cask gpgtools
==> Un-installing artifacts
==> Determining which artifacts are present in Cask gpgtools
==> 4 artifact/s defined
#<Hbc::Artifact::Uninstall:0x007fbca89dc828>
#<Hbc::Artifact::Pkg:0x007fbca89dc738>
#<Hbc::Artifact::PostflightBlock:0x007fbca89dc6c0>
#<Hbc::Artifact::Zap:0x007fbca89dc670>
==> Un-installing artifact of class Hbc::Artifact::Uninstall
==> Running uninstall process for gpgtools; your password may be necessary
==> Removing launchctl service org.gpgtools.macgpg2.shutdown-gpg-agent
==> Executing: ["/bin/launchctl", "list", "org.gpgtools.macgpg2.shutdown-gpg-agent"]
==> Executing: ["/usr/bin/sudo", "-E", "--", "/bin/launchctl", "list", "org.gpgtools.macgpg2.shutdown-gpg-agent"]
Password:
==> Removing launchctl service org.gpgtools.Libmacgpg.xpc
==> Executing: ["/bin/launchctl", "list", "org.gpgtools.Libmacgpg.xpc"]
==> Executing: ["/usr/bin/sudo", "-E", "--", "/bin/launchctl", "list", "org.gpgtools.Libmacgpg.xpc"]
==> Removing launchctl service org.gpgtools.gpgmail.enable-bundles
==> Executing: ["/bin/launchctl", "list", "org.gpgtools.gpgmail.enable-bundles"]
==> Executing: ["/usr/bin/sudo", "-E", "--", "/bin/launchctl", "list", "org.gpgtools.gpgmail.enable-bundles"]
==> Removing launchctl service org.gpgtools.gpgmail.user-uuid-patcher
==> Executing: ["/bin/launchctl", "list", "org.gpgtools.gpgmail.user-uuid-patcher"]
==> Executing: ["/usr/bin/sudo", "-E", "--", "/bin/launchctl", "list", "org.gpgtools.gpgmail.user-uuid-patcher"]
==> Removing launchctl service org.gpgtools.gpgmail.uuid-patcher
==> Executing: ["/bin/launchctl", "list", "org.gpgtools.gpgmail.uuid-patcher"]
==> Executing: ["/usr/bin/sudo", "-E", "--", "/bin/launchctl", "list", "org.gpgtools.gpgmail.uuid-patcher"]
==> Removing launchctl service org.gpgtools.macgpg2.fix
==> Executing: ["/bin/launchctl", "list", "org.gpgtools.macgpg2.fix"]
==> Executing: ["/usr/bin/sudo", "-E", "--", "/bin/launchctl", "list", "org.gpgtools.macgpg2.fix"]
==> Removing launchctl service org.gpgtools.macgpg2.updater
==> Executing: ["/bin/launchctl", "list", "org.gpgtools.macgpg2.updater"]
==> Executing: ["/usr/bin/sudo", "-E", "--", "/bin/launchctl", "list", "org.gpgtools.macgpg2.updater"]
==> Quitting application ID com.apple.mail
==> Executing: ["/bin/launchctl", "list"]
==> Quitting application ID org.gpgtools.gpgkeychainaccess
==> Executing: ["/bin/launchctl", "list"]
==> Quitting application ID org.gpgtools.gpgservices
==> Executing: ["/bin/launchctl", "list"]
==> Uninstalling packages:
==> Executing: ["/usr/sbin/pkgutil", "--pkgs=org.gpgtools.*"]
==> Removing files:
/Applications/GPG Keychain Access.app
==> Executing: ["/usr/bin/sudo", "-E", "--", "/usr/bin/xargs", "-0", "--", "/bin/rm", "-r", "-f", "--"]
/Applications/GPG Keychain.app
==> Executing: ["/usr/bin/sudo", "-E", "--", "/usr/bin/xargs", "-0", "--", "/bin/rm", "-r", "-f", "--"]
/usr/local/MacGPG2
==> Executing: ["/usr/bin/sudo", "-E", "--", "/usr/bin/xargs", "-0", "--", "/bin/rm", "-r", "-f", "--"]
/Library/Services/GPGServices.service
==> Executing: ["/usr/bin/sudo", "-E", "--", "/usr/bin/xargs", "-0", "--", "/bin/rm", "-r", "-f", "--"]
/Library/Mail/Bundles/GPGMail.mailbundle
==> Executing: ["/usr/bin/sudo", "-E", "--", "/usr/bin/xargs", "-0", "--", "/bin/rm", "-r", "-f", "--"]
/Library/PreferencePanes/GPGPreferences.prefPane
==> Executing: ["/usr/bin/sudo", "-E", "--", "/usr/bin/xargs", "-0", "--", "/bin/rm", "-r", "-f", "--"]
==> Un-installing artifact of class Hbc::Artifact::PostflightBlock
==> Executing: ["/bin/bash", "-c", "[[ \"$(/usr/bin/readlink /usr/local/bin/gpg2)\"      =~ MacGPG2 ]] && /bin/rm -- /usr/local/bin/gpg2"]
Error: Command failed to execute!

==> Failed command:
/bin/bash -c [[ "$(/usr/bin/readlink /usr/local/bin/gpg2)"      =~ MacGPG2 ]] && /bin/rm -- /usr/local/bin/gpg2

==> Standard Output of failed command:

==> Standard Error of failed command:

==> Exit status of failed command:
#<Process::Status: pid 96206 exit 1>
Error: Uninstall incomplete.
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli/uninstall.rb:12:in `run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli/abstract_command.rb:35:in `run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:97:in `run_command'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:167:in `run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:131:in `run'
/usr/local/Homebrew/Library/Homebrew/cmd/cask.rb:8:in `cask'
/usr/local/Homebrew/Library/Homebrew/brew.rb:95:in `<main>'
Error: Kernel.exit
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:172:in `exit'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:172:in `rescue in run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:155:in `run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:131:in `run'
/usr/local/Homebrew/Library/Homebrew/cmd/cask.rb:8:in `cask'
/usr/local/Homebrew/Library/Homebrew/brew.rb:95:in `<main>'

Output of brew cask doctor
brew cask doctor
==> Homebrew-Cask Version
Homebrew-Cask 1.3.2
caskroom/homebrew-cask (git revision 02ee3; last commit 2017-09-09)
==> Homebrew-Cask Install Location
<NONE>
==> Homebrew-Cask Staging Location
/usr/local/Caskroom
==> Homebrew-Cask Cached Downloads
~/Library/Caches/Homebrew/Cask (1 files, 21.6MB)
==> Homebrew-Cask Taps:
/usr/local/Homebrew/Library/Taps/caskroom/homebrew-cask (3724 casks)
/usr/local/Homebrew/Library/Taps/caskroom/homebrew-drivers (116 casks)
/usr/local/Homebrew/Library/Taps/caskroom/homebrew-eid (7 casks)
/usr/local/Homebrew/Library/Taps/caskroom/homebrew-fonts (1113 casks)
/usr/local/Homebrew/Library/Taps/caskroom/homebrew-versions (166 casks)
==> Contents of $LOAD_PATH
/usr/local/Homebrew/Library/Homebrew/cask/lib
/usr/local/Homebrew/Library/Homebrew
/Library/Ruby/Gems/2.0.0/gems/json-1.8.2/lib
/Library/Ruby/Site/2.0.0
/Library/Ruby/Site/2.0.0/x86_64-darwin16
/Library/Ruby/Site/2.0.0/universal-darwin16
/Library/Ruby/Site
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/vendor_ruby/2.0.0
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/vendor_ruby/2.0.0/x86_64-darwin16
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/vendor_ruby/2.0.0/universal-darwin16
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/vendor_ruby
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/x86_64-darwin16
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/universal-darwin16
==> Environment Variables
LANG="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
PATH="~/.rvm/gems/ruby-2.4.1/bin:~/.rvm/gems/ruby-2.4.1@global/bin:~/.rvm/rubies/ruby-2.4.1/bin:/usr/local/opt/node@6/bin:~/.nvm/versions/node/v6.11.2/bin:/usr/local/sbin:~/.fastlane/bin:~/.npm-packages/bin:~/google-cloud-sdk/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/git/bin:/usr/local/opt/ruby/bin:~/Library/Android/sdk:~/Library/Android/sdk/tools:~/Library/Android/sdk/platform-tools:~/.composer/vendor/bin:/Applications/Wireshark.app/Contents/MacOS:~/.rvm/bin:/usr/local/Homebrew/Library/Taps/homebrew/homebrew-services/cmd:/usr/local/Homebrew/Library/Homebrew/shims/scm"
SHELL="/bin/zsh"

This is an old issue that has already been fixed. https://github.com/caskroom/homebrew-cask/issues/28911
Simplest solution would be brew cask install --force gpgtools and then try brew cask uninstall gpgtools again.

That worked! Thanks


Make tbmk work with Warp

Is it possible to make tbmk work with Warp?
The ^SPACE invocation of tbmk doesn't work, see https://github.com/warpdotdev/Warp/issues/5149
And even if I run
/Users/andy/bin/tbmk-v1.0.0-beta.4.mac-arm64/tbmk search

explicitly, hitting up and down arrow does nothing, for example. Its like Warp is intercepting keystrokes.
Obviously this request is a big ask, to work with a strange but increasingly popular shell - but I thought I'd just put it out there, as both Warp and tbmk have a similar ideaology of making previously used commands easy to access (see Warp workflows).

hi, I have never used Warp. But I saw that the workflows feature works just the same as tbmk.
Is it worth to make tbmk works on Warp? I just don't think many people will use it when there is the workflows.


feat: add support for self-hosted git provider

@dnldsht Why did you rename the project? Seems like there should be a separate branch from your master for this feature.

My bad, I will make another pull request only with the relevant commits.
I forgot that the branch was connected with the  pull request.


@media print (or @media not print) in Css ignored

When using @media print and @media not print in the CSS in order to get rid of color, images ... the generated pdf will ignore these.
On https://jsfiddle.net/wb2tgm6f/l the generated pdf still includes the  as visible text

Have you found a solution or a workaround for using @media print ?

No, I'm experimenting with this library to see what is possible to automate some manual actions. Right now not usable as is does not give me the same PDFs as if I would print them.

This isn't printing, so the print media query won't get triggered. The workaround I've used is through the css preprocessor I'm using, I duplicate the print styles on both @media print and body.print.
Then I add the print class to the body right before triggering html2pdf, and then removing it right after.

Native Support would be great, but good workaround cwallen! Thanks!

Is there any plans to add support for this?

I appreciate @cwallen's workaround. That's probably a good option in most cases.
In my case I have code that's meant to work with whatever CSS others have written (specifically, I have a WordPress plugin for making a printing a page, and I'd like to also have the option to easily create a PDF from the page).

This isn't printing, so the print media query won't get triggered.

This is technically correct, but IMO creating a PDF from the web page is effectively printing... you're just printing to PDF. (Which is what some browsers, like Chrome, call it.) We're using the page-break CSS styles when creating the PDFs, which, to my knowledge, only apply to printing. IMO it would be great if we could use the rest of the print media styles too.

@cwallen the work around is fine, however I am using display:none for several elements which is causing UI to distortion when I add the class before generating pdf.
Could you please give some advice guys?

This isn't printing, so the print media query won't get triggered. The workaround I've used is through the css preprocessor I'm using, I duplicate the print styles on both @media print and body.print.
Then I add the print class to the body right before triggering html2pdf, and then removing it right after.

Don't know why, but this does not work for me... 😭
var source = document.getElementById('body'); source.classList.add('print'); html2pdf(source, {      filename: 'Test.pdf',      image: { type: 'jpeg', quality: 1 },      html2canvas: { scale: 2 },      jsPDF: { unit: 'mm', format: 'A4', orientation: 'landscape', putOnlyUsedFonts: true } }); source.classList.remove('print');
Do anybody found other workarounds?

Okay, forgot it... I had to run the removal of class after html2pdf function had completely run.
var source = document.getElementById('body');
source.classList.add('print');
html2pdf(source, {
     filename: 'Test.pdf',
     image: { type: 'jpeg', quality: 1 },
     html2canvas: { scale: 2 },
     jsPDF: { unit: 'mm', format: 'A4', orientation: 'landscape', putOnlyUsedFonts: true }
}).then(function(){
     source.classList.remove('print');
});

It's not perfect (there's a little subtle change in layout, of course) but whatever... 😉

@eKoopmans has there been any updates or plans to implement the work you described?

This isn't printing, so the print media query won't get triggered. The workaround I've used is through the css preprocessor I'm using, I duplicate the print styles on both @media print and body.print.
Then I add the print class to the body right before triggering html2pdf, and then removing it right after.

@cwallen can you elaborate a bit more on what you did for this?

Here trying the same, sad that there seems no way to trigger a media query manually.
Can someone include an example of @cwallen's workaround? I'm not that good at CSS and i can't seem to understand it 😅 Ideally i want to be able to toggle the CSS for all children of a node, so they can adapt to the printing style.
Only idea for now is iterating through all of these is programmatically doing this modification for each, and then rollback.

Well i'm not sure if this is the correct interpretation of what you guys were saying but i solved it with a child selector, made prettier in Tailwind (which i'm using) by a plugin to add as a new pdf: variant. Pretty happy with how simple it turned out.
Code (Next.js with TailwindCSS):
// tailwind.config.js
...
  plugins: [
    plugin(function ({ addVariant }) {
      // Add a `pdf` variant, ie. `pdf:bg-white`, that applies when
      // element is element or is child of element with class "pdf"
      addVariant("pdf", ['&[class~="pdf"]', ".pdf &"]);
    }),
  ],

// MyComponent.tsx
        <Col id="pdf-canvas" xl="8" className="pdf:max-w-none pdf:flex-1">
          <Row> {/* ... */} </Row>

          <Row className="pdf:hidden"> {/* ... */}  </Row>
        </Col>

// pdf.ts
export const generatePDF = async (
  filename: string = "Player report.pdf"
) => {
  // deferred import of html2pdf.js
  const html2pdf = (await import("html2pdf.js")).default;

  const canvas = document.querySelector("#pdf-canvas");
  if (!canvas) {
    console.warn("Did not found #pdf-canvas, nothing to do");
    return;
  }

  const activateCSSForPDF = () => document.body.classList.add("pdf");
  const deactivateCSSForPDF = () => document.body.classList.remove("pdf");

  activateCSSForPDF();

  const opts = {
    filename,
    margin: 7,
    image: { type: "jpeg", quality: 0.95 },
    html2canvas: {
      scale: 2, // higher quality
      windowWidth: 1024, // simulate a browser size with this width
    },
    jsPDF: { orientation: "portrait" },
  };
  html2pdf()
    .set(opts)
    .from(canvas)
    .save()
    .finally(() => {
      deactivateCSSForPDF();
    });
};

I've used this script and it's working fine! it's just to make a promise out of the html2pdf() method and then do whatever I want after it.
document.querySelector('.download').addEventListener('click', function () {
var element = document.getElementById('receipt');
element.style.display = "block";
// Call html2pdf() and save the Promise object that it returns
var pdfPromise = html2pdf().from(element).save();

// Wait for the PDF generation to complete before hiding the element
pdfPromise.then(function () {
    element.style.display = "none";
});

});


[Removal]: Magnificent Fiery Hedgehog from Deny list. It was added mistakenly by KXI1 in #4467

Hotspot Name
Magnificent Fiery Hedgehog
Hotspot b58 Address
11raUdUSuERTLSk1Zj7gWGmmurxCKrN5iNfjQbXy3ZceadsNQrc
Discord Handle
Kriss#8272
Hotspot Manufacturer
Pisces Miner
Removal Reason
Addition to Deny list was made in error by KXI1 in #4467
Modifications
No
Extra forwarders
No
Extra antennas
No
Additional Information
Request to remove hotspot from deny list asap as my miner was added by mistake.
@6CornerDefender has seem to rectified some but not all mistakes at this time.
Hotspot was added admittedly in error by KXI1 in #4467. See here : https://github.com/helium/denylist/issues/4467#issuecomment-1136952783
"But set D - the 'trigger' miner is a pisces, but the 15 HS listed here fo that set are neither pisces nor self-witnessesing. These 15 are:
11raUdUSuERTLSk1Zj7gWGmmurxCKrN5iNfjQbXy3ZceadsNQrc
112nQJUnYyHE5CVJFofgtXzNDUAsuAx5TpqsH29nzebE4W4bPdR9
112NCgFaiVLTpJ2QjWtHwyFX154cqnhsxUQa6Kqz9Y6MzBXuhKuF
11zGWiH5i9LDk2vm9sfaYHfqALZ8vDECiTvUF2AQom6dgWKccQT
11D7coU6HRYhzDyw8grUB8Z8TfNL9AVPy15utevmcohjyeG6ZWL
112r6gFLYghw3Cg4yFBy2CzzSmSRKwpimzXznGDqzCUTPaWReUYy
11232oGEzpBnrNfdujQthS6h3xrwXf7mk2EYss4BBojiXJdJBJPD
11P1pspZketnZ9KCEEJHRuXHc56YFNuHBCCrxRkFx4usHwGvqpn
118pwaDBwF3XtCyh1ShVAyWhCp696AuuWAz8ZCnV5orNNVWmyc9
11YVUS1uE5gtGHLKKymXertSE5scYZLTYZk3irNMLrrMgebkDya
11MA4t82UugARgVisEE1WhdG8vrL3mYgP163MASgYxinKnsLtY5
112s86P6rqHMEXjdB3hfNANBshXRG8nALH3no8siCPFub7nQpqqV
11228SsCdU29gAivd1H4CvA7C1h7qaBQEUjPomkQQVNLyDCycVXm
112pNjZkuTqFasXkWCwhzGVNoLr2UP62sMxf8kmZ5irYtw2NnUVG
112raz9TNLcBRVzj3KdiY3QeeX4qoqZEpvhdRpnBum9xdU1Vnecd
These 15 above should NOT have been listed in my submission, and I'm sorry for the error.
They should be removed from denylist ASAP.
@6CornerDefender there are a few in addition to those you have already PR'd
I'm not clear how that could have happened since they were the witnesses returned from 5 iterations on the cluster tool, but on ETL it's clearly different. I think there is still another self-witnessing cluster in San Diego in this area, but somehow I missed it. Using the ETL query means this kind of error is much, much less likely from now on."
Upon request through discord:
I also have photographs is my phone displaying GPS location physically held next to my miner with Serial Number shown.
I have local receipt to prove I am physically located where the hotspot GPS point to.
I have order confirmation of brand new miner also displaying shipping location to current location of miner.
The above images should be used to support that the miner is not spoofing the gps location.

Already removed on the last PR


[RFC appveyor] Error handling in BaseService

This is some work in progress for error handling in BaseService. It works, though it's not tested yet. I'm not even sure I like all of it.
The part I really like is a clear distinction between programmer errors ("internal errors") and runtime errors, and the ability to configure the program to let the programmer errors bubble up in development and unit testing. This saves a huge amount of time because it generates ordinary stack traces when things go wrong. And, if these errors occur in production, we'll catch them, and display shields | internal error which is the equivalent of a 500 error.
@chris48s You and I are both eagerly awaiting this feature. Curious to get your thoughts and input on this. Would you like to to take a stab at reworking the helper methods? Feel free to push some commits to this branch.

Warnings

:warning:

This PR modified package.json, but not package-lock.json - Perhaps you need to run npm install?

:warning:

This PR modified the server but none of the service tests. That's okay so long as it's refactoring existing code.

:warning:

This PR modified helper functions in lib/ but not accompanying tests. That's okay so long as it's refactoring existing code.

Messages

:book:

:sparkles: Thanks for your contribution to Shields, @paulmelnikow!

  Generated by :no_entry_sign: dangerJS

Pulled down the latest changes and the inaccessible handling code is looking good :+1: , but if I edit the service code to
module.exports = class AppVeyor extends BaseService {
  async handle({repo, branch}) {
    throw new Error('foo');
    ...
  }
};

I am still getting the Unhandled promise rejection error. Is it the intention to try and handle that, or is it intended for those not defined in services/errors to be unhandled in this way? I can see reasons for both..

That snippet is a great example of code I‘d advocate treating as a bug. In other words, it’s a programmer error.
Our error handling strategy should differentiate the two kinds of errors: programmer errors, and runtime errors. Probably you’re familiar with this distinction, but I’ll explain what I mean for others reading.
A runtime error is when something goes wrong that can be expected, like a service returning bad data, a network connection failing, or a disk having filled up. Of course the disk example isn’t relevant to Shields, but the others are.
A programmer error occurs when the code fails under certain inputs, and the programmer hasn’t correctly guarded themselves. Examples are the built in exceptions like TypeError, ReferenceError, ParseError, which manifest when something has gone wrong that the programmer hasn’t checked for. Of course malformed service data or a bad value for a query parameter can cause a TypeError. However it’s the programmer’s job to adequately validate the data before making assumptions about the types, thus preventing the TypeError from occurring.
Declarative validation using something like Joi probably is best, because validators written this way are terse, easy to read, write, and change, and delegate the hard work and edge cases to a well tested library.
The disadvantage of automatically handling all exceptions is that the programmer errors and legitimate runtime errors are indiscernible. The bugs are masked as runtime errors.
Guarding against error conditions is significantly more work but the payoff in developer velocity far outweighs it. No more editing a catch block to print err.stack: the programmer errors will just manifest when a mistake has been made, whether in a test failure or when running the server locally.
At runtime we want to show the user a message rather than just leave them hanging – hence shields | internal error. It also motivates us to find and fix these bugs so we can display more helpful error messages. And hopefully it motivates contributors to do the same! It’s a way of saying, “you can fix this!”
That’s a long-winded argument on error-handling strategy. I hope it’s convincing.
I’d much rather the programmer error be reported directly, rather than wrapped in an UnhandledPromiseRejection. I’ll work a bit more at that to see if it’s possible.
What do you think?

What do you think?

Yep - nice. Totally on board with this. In the case of an unexpected error, we want it to bubble to Sentry, not the user :+1: I'd suggest one refinement to this: In order to make this a bit more extendable in future, I'd suggest we modify services/errors.js to define a base class, like:
class ShieldsRuntimeError extends Error {
}

class NotFound extends ShieldsRuntimeError {
...
}

class InvalidResponse extends ShieldsRuntimeError {
...
}

class Inaccessible extends ShieldsRuntimeError {
...
}

and catch any error of class ShieldsRuntimeError. That way if we do encouter a situation other than 'not found', 'invalid' and 'inaccessible' that we want to handle rather than throw the handler is more flexible. There is also a point to bear in mind here to document how to throw errors correctly once we update the docs to reflect the new service architecture.
There is one edge case which occurs to me here in terms of how we handle errors: The dynamic json/xml badges. If you think about an issue like #1493 for example, when a user is "developing" (for want of a better word) a badge using those features there is value in the user being able to see errors in that case so they can check their inputs/refine their query/whatever. In that case, maybe we do want to feed back 'internal' errors to the user instead of bubbling them to sentry. I don't particularly want notifications every time a user is trying to feed HTML into their dynamic JSON badge, but it might help them work out what they are doing wrong if they can see a parseError. If you think about my suggestion above, that might be a case where we want to define
class DynamicBadgeError extends ShieldsRuntimeError {
...
}

and just wrap anything that gets thrown in a DynamicBadgeError, but also interested in your thoughts on that situation.

I’d much rather the programmer error be reported directly, rather than wrapped in an UnhandledPromiseRejection. I’ll work a bit more at that to see if it’s possible.

Yes - it would be nicer developer experience if we could do this. Simultaneously the original error is available in the stacktrace so I don't think this point should hold up merging this feature if it is really hard to do and it is the last outstanding issue.

There is one edge case which occurs to me here in terms of how we handle errors: The dynamic json/xml badges...

There is possibly some overlap here with @platan 's comment in https://github.com/badges/shields/pull/1623#issuecomment-377568183

I don't particularly want notifications every time a user is trying to feed HTML into their dynamic JSON badge, but it might help them work out what they are doing wrong if they can see a parseError. If you think about my suggestion above, that might be a case where we want to define …

Yea! I just posted in that other thread you linked, and think e.g. invalid json is a good message to return in the case of a dynamic badge's data source being bad. We should also keep in mind that, since data sources go down sometimes, invalid json could also be a runtime error from the developer's perspective too – meaning I'd probably color it gray rather than red.
The other case is where the query fails. I think that could be because the query expression is itself invalid. That's a permanent problem with the request, a 400 error, and should be red.
Another possibility is that the query is valid but matches / returns nothing in the data. That's ambiguous. In other word, it could be a permanent problem with the query, though it could also be a transient problem with the data. In that case we should assume the less severe, and return a gray error. Heh, come to think of it, it might not be an error at all. Aren't we displaying something now, like no data, in that case? Seems like that's the right thing to do.
For debugging purposes we could also make a JSON or version of the badge which returns the full error message. Or, even better… a front-end dev tool for dynamic badges! It could fetch the page and run the query right in the browser! It's not so hard to ship these libraries to the front end.

Or, even better… a front-end dev tool for dynamic badges! It could fetch the page and run the query right in the browser! It's not so hard to ship these libraries to the front end.

Glad you brought this up. I have also thought before that a 'sandbox' environment for making dynamic badges would be pretty cool. Then you could provide detailed error reporting in the 'sandbox' environment and less descriptive errors in the SVG. Rendering exceptions to SVG is not great UX for either the user attempting to extract meaningful debug info from it, or the end-user who is seeing it in someone's README when something goes wrong.
That said, lets not try and boil the ocean all in one pull request :) I think the key things this identifies are:

There are things other than 'not found', 'invalid' and 'inaccessible' which we may want to class as a runtime error (at least in some sitautions).
We may want to provide different levels of error reporting in different output formats. e.g: the SVG render may have a different level of error reporting from a JSON endpoint backing a sandbox environment for 'developing' dynamic badges.

Our mechanism for throwing/handling errors should be flexible enought to accommodate that.

Great summary!

I don't think this point should hold up merging this feature if it is really hard to do and it is the last outstanding issue.

I may not have a moment in the next couple days to try to tackle this so I think I will merge without it. Once this is merged we can return to that, and also easily tweak the class hierarchy to support more kinds of runtime errors.


Installing cheatsheets

Is it possible to install cheatsheets using dasht-docsets-install or it must be done manually?

If cheatsheets are available in Dash's feeds repository then yes.
Otherwise, please provide an example of a URL where such a cheatsheet can be downloaded from.


Makefile: Simplify with a %.o: %.cpp pattern rule.

This cleans up the Makefile a bit.  Tested with make --dry-run to ensure that there are no material changes.

Another patch to implement DNS lookups for one (or two) hosts.


\extensions kills

I have a question
env:
code :1.19.0
816be6780ca8bd0ab80314e11478c48c70d09383
x64
os: Windows_NT 10.0.16299
I try reinstall code and nodejs ,but i also meet the question ,i find only debug node type can meet the question ,the other can't not find the question,i also try delete extends file or git file floder ,not ok,so ,i geuss the node evnoke the question.thanks ,i am now one.

@Ants-double Can you please follow the steps in this guide: https://github.com/Microsoft/vscode/wiki/Native-Crash-Issues

This issue has been closed because it needs more information and has not had recent activity. Please refer to our guidelines for filing issues. Thank you for your contributions.

Thanks ,i fix the question when i rebuild the OS. but i guess the node.js extends have some question at my reconfigure the info ,i fix the node config some setting ,then the vscode vill give me the tips.so i now keep the nodejs setting is default ,i can't meet the question .Sorry  my OS rebuild  can't give you back as soon as .my error . next . I will give more information .but this time i don't have enough time to get other information of the issues .
At 2017-12-20 18:51:33, "Andre Weinand"<EMAIL_ADDRESS>wrote:
This issue has been closed because it needs more information and has not had recent activity. Please refer to our guidelines for filing issues. Thank you for your contributions.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.


Service Degradation

Additional context
All RM User Group services are expected to have some performance degradation over the next week. This is due to an issue out of our control.

RMUG Files and RMUG Installations (Internal) are back online on a temporary host. It is expected that performance will be lower due to this.
We expect to restore normal service by the middle of next week.


fix followRedirects return type (Response instead of TestResponse)

followRedirects returns a wrong object (TestResponse) instead of Response stated in phpDoc.
this pull request make it returns a Response as expected

It should return a TestResponse.

The phpDoc says it is a Response instead of TestResponse
https://github.com/laravel/framework/blob/cc1b312a25210c6051813a2dc950d33c38d9ff24/src/Illuminate/Foundation/Testing/Concerns/MakesHttpRequests.php#L437

@miklcct Resent as https://github.com/laravel/framework/pull/26722


Dependency issue when trying to install through pip

Recently I tried to install the new package and got this issue though pip
ERROR: Could not find a version that satisfies the requirement rusty-rlp<0.2,>=0.1.15 (from rlp<=2.0.0.alpha-1,>=1.0.0->eth-account<0.6.0,>=0.5.3->web3<6.0.0,>=5.12.0->uniswap-python) (from versions: none) ERROR: No matching distribution found for rusty-rlp<0.2,>=0.1.15 (from rlp<=2.0.0.alpha-1,>=1.0.0->eth-account<0.6.0,>=0.5.3->web3<6.0.0,>=5.12.0->uniswap-python)

I have tried two versions of the Python interpreter and ran into the same issue, 3.7 and 3.8 (I don't see a reason why this should happen tho

Platform? Works fine when installing with pip on my machine, and in CI.

Sorry, it's a Windows 10 64 bit. Also tried on a Windows Server 2012 R2 as well

Can you install web3 without issue? From the error it looks like it isn't an issue with uniswap-python but rather a downstream dependency of web3.

Closing since it's not an issue with uniswap-python itself.


Where does "savedInstanceState" come from in the Android init line

The standard android project init line is:
global::Xamarin.Forms.Forms.Init(this, bundle);
with bundle as the second param.
Your example reads:
global::Xamarin.Forms.Forms.Init(this, savedInstanceState);
FormsMaterial.Init(this, savedInstanceState);
with savedInstanceState as the second param.  Where is this coming from? Do we need to add a using statement to the MainActivity.cs so this becomes available?  Or has the template for android projects changed for VS2019 making projects created in VS2017 incompatible or at least in need of migration instructions?

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

ID: fbfbc90e-2eb6-a305-f7da-bded6e31a2b4
Version Independent ID: 66cad08c-2158-c081-a668-e4dad525e664
Content: Xamarin.Forms Material Visual - Xamarin
Content Source: docs/xamarin-forms/user-interface/visual/material-visual.md
Product: xamarin
Technology: xamarin-forms
GitHub Login: @davidbritch
Microsoft Alias: dabritch

The templates may have changed the name of the parameter for the OnCreate method, but the name of this item is whatever appears in the method signature. See the code sample:
https://github.com/xamarin/xamarin-forms-samples/blob/master/UserInterface/VisualDemos/VisualDemos.Android/MainActivity.cs#L11
In your case, use bundle if that is what's already set up as the parameter name.


[VS Code] The relay listener went offline, unsharing workspace. Re-share to generate a new session.

Error:
The relay listener went offline, unsharing workspace. Re-share to generate a new session.
Steps to Reproduce:

Version Data

extensionName
VSLS

extensionVersion
0.3.788

protocolVersion
2.2

applicationName
VSCode

applicationVersion
1.21.1

platformName
MacOS

platformVersion
18.0.0

Thanks for reporting the issue. Can you please run the command "Live Share: Export Logs" and drag-and-drop the zip here or send it to<EMAIL_ADDRESS>

This is not an error, creating a new session should resolve this error.


Better typing for payload

Is your feature request related to a problem? Please describe.
It's not a pleasant experience having to work with Map for the WebSocket payload, especially if the user already know what to expect.
Describe the solution you'd like
2 approach:

Allow user to specify what type they are expecting which might require a breaking change
Extends Map with functionalities to be parsed to other types

A draft on how I could do the second approach:
import enum GraphQL.Map
import class JSONEncoder
import class JSONDecoder

extension Map {
    public func into<T: Decodable>(_ dataType: T.Type) throws -> T {
        let data = try JSONEncoder().encode(self)
        return try JSONDecoder().decode(dataType, from: data)
    }
}

// ...

server.vaporMiddleware(
    websocketContext: { req, payload, gql in
        let myPayload = payload.into(MyPayload.self)
        // do something with it
    }
)

With this I can have somewhat implement the first with
public typealias VaporCustomWebSocketContext<P: Decodable> = @Sendable (Request, P, GraphQLRequest) async throws -> Context

public typealias VaporCustomWebSocketGuard<P: Decodable> = @Sendable (Request, P) async throws -> Void

public func vaporMiddleware<CustomPayload: Decodable>(
    ...,
    websocketContext: VaporCustomWebSocketContext<CustomPayload>,
    websocketGuard: VaporCustomWebSocketGuard<CustomPayload>
) -> VaporGraphQLMiddleware {
    vaporMiddleware(
        ...,
        websocketContext: { req, payload, gql in
            let custom = payload.into(CustomPayload.self)
            return try await websocketContext(req, custom, gql)
        },
        websocketGuard: { req, payload in
            let custom = payload.into(CustomPayload.self)
            return try await websocketGuard(req, custom)
        }
    )
}


LifeLeech Bugs

Minecraft version & Mod Version:
1.12.2
1.17.0
Single player or Server:
Both
Describe problem (what you were doing / what happened):
Adding LifeLeech to a sword stops mobs from droping any loot. Playing Enigmatica 2 expert mode. https://gyazo.com/4b63455aaac70983b3f96e1fa8c96ad6

That is a lot of enchantments.  Are you sure it is lifeleech?
I did a quick test while i was damaged, similar enchantments to you but without some of the modded ones.  I am healing on the killing blow at the same time as getting drops 👍
https://i.imgur.com/zbwfvNA.gifv

For modpacks you can often just report to the pack issue tracker, sometimes it is a conflict between several mods, or sometimes it might be something done on purpose    .
If you report there you will probably get more help.  Also feel free to link this issue as well, and if theres anything I can do on my end we can just reopen the issue
https://github.com/NillerMedDild/Enigmatica2/issues

The issue did not occure when lifeleach was removed. Probably should have tested with just lifeleach..


Ability to disable Crop inside square corner dragging

I have a case where not need outside corners, like instagram images cropping
Need ability to Crop box corners dragging

yes, but for now you can comment on lines 565 to 576 in crop.dart file

Check this https://www.youtube.com/watch?v=1aRwxnX5nms


Remove related version implements and document

related #3891
I think these can already be removed

We won't remove the version configuration option, otherwise, users cannot switch between the latest and the stable format style.


Adding Pretty Print Support For Fixed Size List

Which issue does this PR close?
Closes #925
Rationale for this change
See #925

Not sure if there is a way to automatically accept the linting changes but I went ahead and incorporated the lint changes

Codecov Report

Merging #958 (00f66e0) into master (02f3ec8) will increase coverage by 0.00%.
The diff coverage is 0.00%.

@@           Coverage Diff           @@
##           master     #958   +/-   ##
=======================================
  Coverage   82.31%   82.31%
=======================================
  Files         168      168
  Lines       48719    48719
=======================================
+ Hits        40104    40105    +1
+ Misses       8615     8614    -1

Impacted Files
Coverage Δ

arrow/src/util/display.rs
20.00% <0.00%> (-0.39%)
:arrow_down:

parquet_derive/src/parquet_field.rs
65.98% <0.00%> (ø)

arrow/src/datatypes/datatype.rs
66.38% <0.00%> (+0.42%)
:arrow_up:

arrow/src/compute/kernels/temporal.rs
97.35% <0.00%> (+1.27%)
:arrow_up:

Continue to review full report at Codecov.

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


[Feature]: A "pure" python kernel

What's missing?
The poetry2nix Python kernel is a bit problematic.
For example, see at least https://github.com/tweag/jupyenv/issues/482, but furthermore, note that sometimes poetry2nix makes certain things quite hard; c.f. tensorflow. It seems hard to get it to work; but nix-shell -p python310Packages.tensorflow works fine.
Possible solution
It'd be great if there was a "pure" python kernel, that just uses the python3.withPackages ... style, or something, to just specify the packages in scope.
Alternatives
No response
Additional context
No response

Yeah this would be great. The old juypterWith interface was so simple and worked so well. Poetry is a pain to deal with nix leading to infinite recursion errors and hard to debug issues.

The change to poetry2nix that causes #482 is fairly easy to fix; I just removed the passed poetry parameter for now. But even after using the new poetry2nix version, I get tons of errors like this trying to build the same jupyenv environment (actually it's @collinarnett  stable-diffusion-nix project) which works with the old jupiterWith interface just fine.
 Could not find a version that satisfies the requirement setuptools>=41.0.0 (from tensorboard) (from versions: none)

Same here, the current state of the project is unusable.

See #524


serialize_bytes is not unreachable now

serialize_bytes can push to output JSON raw bytes now. I now it can produce JSON with invalid data so it should be used with caution. I added this because I need a way to serialize f32 with fixed precision.
Example:

pub struct SimpleDecimal(f32);

impl Serialize for SimpleDecimal {
    fn serialize<S>(&self, serializer: S) -> Result<S::Ok, S::Error>
    where
        S: Serializer,
    {
        let mut aux: String<U48> = String::new();
        write!(aux, "{:.2}", self.0).unwrap();
        serializer.serialize_bytes(&aux.as_bytes())
    }
}

@eldruin Changelog updated.


Feature/burn unusable tokens

closes https://github.com/trustlines-protocol/merkle-drop/issues/23

Need to fix a problem arising when attempting to burn tokens later than the decayduration

Ok, I should burn some tokens on withdraw but I did not find an easy calculation for this, and the calculation I had initially was wrong since the amount to burn there is not value - valueToSend because some of it has potentially been burnt already in burnUnusableTokens.
I can make a new calculation or call burnUnusableTokens() at the beginning of withdraw. Do you have a recommendation?

My recommendation is to have real accounting of the tokens burnt and withdrawn.  At any point in time you could compute the tokens which decayed from the sum of entitlements at the start minus the entitlements withdrawn. You could compare that to the number of tokens burnt via the burn function and burn the difference. (I haven't thought this through completely)

I thought a bit more about this. I would try to account the following things:

entitlement_not_withdrawn: The sum of all initial entitlements for all users who have not withdrawn their entitlement. If a user withdraws we reduce this value by the initial entitlement of the user.
burned_entitlement_not_withdrawn: Sum of all burned values from the entitlement_not_withdrawn. When we burn value, we add the burned value here. When a user withdraws, we reduce this by the burned part of his initial entitlement. If we want to burn value, we can compute the difference between this value and the to be burned part of the entitlement_not_withdrawn computed from the beginning of the decay period and burn this difference. This way we keep rounding errors to a minimum.

Also, when a user withdraws, we always burn from the complete entitlement_not_withdrawn. This makes sure the users entitlement to be burned is already burned. There is no need to have the burning logic for a single user (though we do have to keep track of the accounting)

entitlement_withdrawn: The sum of all initial entitlements of all user who have withdrawn
burned_entitlement_withdrawn: The burned part of all initial entitlements of all users who have withdrawn
transferred_entitlement_withdrawn: The sum of all transferred values to users who have withdrawn

The burn function can still be simplified.
I've opened a PR for this branch here: https://github.com/trustlines-protocol/merkle-drop/pull/30


Cherry-pick changes from PR148

Cherry-pick of https://github.com/apple/swift-system/pull/148, improving support for recent Android NDKs.

@swift-ci please test


Azure pytest parallel

Breaking Change:

Description:
Related issue (if applicable): fixes #
Pull request with documentation for home-assistant.io (if applicable): home-assistant/home-assistant.io#<home-assistant.io PR number goes here>
Example entry for configuration.yaml (if applicable):

Checklist:

[ ] The code change is tested and works locally.
[ ] Local tests pass with tox. Your PR cannot be merged unless tests pass
[ ] There is no commented out code in this PR.
[ ] I have followed the development checklist

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[ ] The manifest file has all fields filled out correctly. Update and include derived files by running python3 -m script.hassfest.
[ ] New or updated dependencies have been added to requirements_all.txt by running python3 -m script.gen_requirements_all.
[ ] Untested files have been added to .coveragerc.

If the code does not interact with devices:

[ ] Tests have been added to verify that the new code works.

This will probably end up finding a bunch of flaky tests that were flying under the radar before because they relied on the order the tests were run. Like the ps4 one that I just fixed. It's good.


Test if constant values need to be transferred from grid to column and back

Noah-OWP-Modular has some constant variables that go through the same transfer process as the time-/space-varying variables. Test if this still needs to be done. If not, remove variables from the transfer routines that occur each timestep.
Example: https://github.com/NOAA-OWP/noah-owp-modular/blob/a39c372f3c61f05e574943e245839d683aa35e4f/src/ParametersGridType.f90#L81
Related to #5

@SnowHydrology, I believe this issue was mostly addressed by PR #82 though I think we could further reduce unnecessary transfers by implementing the ConstantsModule (i.e., Issue #5). Would you recommend closing this issue or do you see value in keeping it alive?


Added stkd-scrt and some UI changes

I created a UX divider between native tokens and SNIP20s (the UI is still bad but at least gives some sense)
Addded stkd-scrt.
Still need to:

[x] Update from_denoms for stkd-scrt as i cant find then anywhere.

I would ignore this PR if the UX changes are irrelevant https://github.com/scrtlabs/wrap.scrt.network/pull/17

@scrt-tovi