Trouble creating cluster

Following this guide, I have been trying to set up a hyper-converged instance of GlusterFS running on top of Kubernetes using 3 nodes.
I first used losetup to create a 200GB file on each node. Then, I used a script at boot time to add the loopback devices
#/etc/systemd/system/loopback_gluster.service
[Unit]
Description=Create the loopback device for GlusterFS
DefaultDependencies=false
Before=local-fs.target
After=systemd-udev-settle.service
Requires=systemd-udev-settle.service
[Service]
Type=oneshot
ExecStart=/bin/bash -c "modprobe dm_thin_pool && [ -b /dev/loop200 ] || losetup /dev/loop200 /home/cloudy/glusterimage"
[Install]
WantedBy=local-fs.target

(Enabled via systemctl start loopback_gluster)
Next, ensuring that those devices were not added as a pv, vg, or lv, I started the gluster-kubernetes tool via the command cd ~/gluster-kubernetes/deploy; and ./gk-deploy -gy topology.json
my topology.json is as follows
{
  "clusters": [
    {
      "nodes": [
        {
          "node": {
            "hostnames": {
              "manage": [
                "kraken"
              ],
              "storage": [
                "<IP_ADDRESS>"
              ]
            },
            "zone": 1
          },
          "devices": [
            "/dev/loop200"
          ]
        },
        {
          "node": {
            "hostnames": {
              "manage": [
                "kraken01"
              ],
              "storage": [
                "<IP_ADDRESS>"
              ]
            },
            "zone": 1
          },
          "devices": [
            "/dev/loop200"
          ]
        },
        {
          "node": {
            "hostnames": {
              "manage": [
                "kraken02"
              ],
              "storage": [
                "<IP_ADDRESS>"
              ]
            },
            "zone": 1
          },
          "devices": [
            "/dev/loop200"
          ]
        }
      ]
    }
  ]
}

(To explain my specific set-up, the master is kraken at <IP_ADDRESS>, and kraken01 (<IP_ADDRESS>) and kraken02 (<IP_ADDRESS>) are both worker nodes receiving their addresses via the dhcp server running on the master)
Running this gives me the following errors:
......
Waiting for deploy-heketi pod to start ... OK
Creating cluster ... ID: f6b1394ed1845ae917e64b7680d434b1
Allowing file volumes on cluster.
Allowing block volumes on cluster.
Creating node kraken ... ID: 4cf5d9c7fcef25fe241dd5d562d88920
Adding device /dev/loop200 ... OK
Creating node kraken01 ... Unable to create node: Unable to execute command on glusterfs-lks95: peer probe: failed: <IP_ADDRESS> is either already part of another cluster or having volumes configured
Creating node kraken02 ... Unable to create node: Unable to execute command on glusterfs-lks95: peer probe: failed: <IP_ADDRESS> is either already part of another cluster or having volumes configured
Error loading the cluster topology.

Specifically probing the <IP_ADDRESS> node via kubectl exec -it [pod name of glusterfs running on <IP_ADDRESS>] -- /bin/bash
[root@kraken /]# gluster peer status
  Number of Peers: 0
[root@kraken /]# pvcreate --metadatasize=128M --dataalignment=256K /dev/loop200
  WARNING: Not using lvmetad because config setting use_lvmetad=0.
  WARNING: To avoid corruption, rescan devices to make changes visible (pvscan --cache).
  Can't initialize physical volume "/dev/loop200" of volume group "vg_9a89ec52d3c78c24c554fd155a19745c" without -ff
  /dev/loop200: physical volume not initialized.

Now the interesting thing here is a pv and a vg in the underlying OS were automatically created through running ./gk-deploy. Furthermore, manually deleting the volume group via the command vgremove -ff $(vgdisplay | grep -i "VG Name" | awk '{print $3}'), and then going back into the <IP_ADDRESS> pod via kubectl exec -it [pod name of glusterfs running on <IP_ADDRESS>] -- /bin/bash, and then running pvcreate --metadatasize=128M --dataalignment=256K /dev/loop200 succeeds.

Next I reset everything I was doing via the command cd ~/gluster-kubernetes/deploy && ./gk-deploy -gy --abort && sudo vgremove -ff $(sudo vgdisplay | grep -i "VG Name" | awk '{print $3}') && sudo rm -rf /var/lib/heketi /etc/glusterfs /var/lib/glusterd /var/log/glusterfs && sudo pvremove /dev/loop200
Next, I explicitly set a physical volume via pvcreate /dev/loop200 on the underlying layer.
However, running cd ~/gluster-kubernetes/deploy && ./gk-deploy -gy topology.json yeilds the exact same error as before when I never explicitly declared a physical volume
.......
Waiting for GlusterFS pods to start ... OK
secret "heketi-config-secret" created
secret "heketi-config-secret" labeled
service "deploy-heketi" created
deployment "deploy-heketi" created
Waiting for deploy-heketi pod to start ... OK
Creating cluster ... ID: d7243d19408eb66c5b1b2cdd2c51600c
Allowing file volumes on cluster.
Allowing block volumes on cluster.
Creating node kraken ... ID: 22ae881e7b63341d279285e76cd6113c
Adding device /dev/loop200 ... OK
Creating node kraken01 ... Unable to create node: Unable to execute command on glusterfs-j85pj: peer probe: failed: <IP_ADDRESS> is either already part of another cluster or having volumes configured
Creating node kraken02 ... Unable to create node: Unable to execute command on glusterfs-j85pj: peer probe: failed: <IP_ADDRESS> is either already part of another cluster or having volumes configured
Error loading the cluster topology.
Please check the failed node or device and rerun this script.

Running bash on the <IP_ADDRESS> pod...
[root@kraken /]# gluster peer status
Number of Peers: 0
[root@kraken /]# pvcreate --metadatasize=128M --dataalignment=256K /dev/loop200
  WARNING: Not using lvmetad because config setting use_lvmetad=0.
  WARNING: To avoid corruption, rescan devices to make changes visible (pvscan --cache).
  Can't initialize physical volume "/dev/loop200" of volume group "vg_5891d86b344f380bb45992411cf6fa68" without -ff
  /dev/loop200: physical volume not initialized.

Similar to the first installation attempt, when I manually delete the vgroup from the base OS that Kubernetes is running on top of via vgremove -ff $(vgdisplay | grep -i "VG Name" | awk '{print $3}'), and then try pvcreate in the gluster pod running in <IP_ADDRESS>, it succeeds.
[root@kraken /]# pvcreate --metadatasize=128M --dataalignment=256K /dev/loop200
  WARNING: Not using lvmetad because config setting use_lvmetad=0.
  WARNING: To avoid corruption, rescan devices to make changes visible (pvscan --cache).
  Physical volume "/dev/loop200" successfully created.
[root@kraken /]#

Next, I reset everything and initialize a physical volume -force -force via the command pvcreate -ff /dev/loop200 on all three nodes.
.......
node "kraken" labeled
node "kraken01" labeled
node "kraken02" labeled
daemonset "glusterfs" created
Waiting for GlusterFS pods to start ... OK
secret "heketi-config-secret" created
secret "heketi-config-secret" labeled
service "deploy-heketi" created
deployment "deploy-heketi" created
Waiting for deploy-heketi pod to start ... OK
Creating cluster ... ID:<PHONE_NUMBER>a3192498e4e32b048f55ed
Allowing file volumes on cluster.
Allowing block volumes on cluster.
Creating node kraken ... ID: 785c70c97dab32f205449ea9cf892fc9
Adding device /dev/loop200 ... OK
Creating node kraken01 ... Unable to create node: Unable to execute command on glusterfs-cnfdk: peer probe: failed: <IP_ADDRESS> is either already part of another cluster or having volumes configured
Creating node kraken02 ... Unable to create node: Unable to execute command on glusterfs-cnfdk: peer probe: failed: <IP_ADDRESS> is either already part of another cluster or having volumes configured
Error loading the cluster topology.
Please check the failed node or device and rerun this script.

The behavior for doing vgremove is same as before.
My hunch is that my setup is not supplying one raw block device. My question is using a loopback device, how can I supply a raw block device? Or, if that is not my problem, how can I successfully set up my system using a loopback device?
Thank you!
Other Notes:
My head node (<IP_ADDRESS> is running KDE Neon [basically Ubuntu 16.04LTS with KDE skin on top) and my other two worker nodes are running Ubuntu Server 16.04 LTS.
Using heketi-cli version 5.0.0, glusterfs 3.12.2

Next, I explicitly set a physical volume via pvcreate /dev/loop200 on the underlying layer.

You should not explicitly set a physical volume. This will be taken care by gk-deploy script.
In fact, you should provide only raw block devices.

My hunch is that my setup is not supplying one raw block device. My question is using a loopback device, how can I supply a raw block device? Or, if that is not my problem, how can I successfully set up my system using a loopback device?

After carrying out lvremove, vgremove and pvremove
could you try wiping of the block device. for example:
wipefs -a -f /dev/sdb
Then try out gk-deploy script.

I will try this and let you know how it goes

wipefs -a -f /dev/loop200 on the underlying OS yeilded same results

@gilgameshskytrooper Can you find logs from the deploy-heketi pod corresponding to when it failed to add the other nodes?

The command that is failing is gluster peer probe, which is what is used to add nodes to the cluster. Are you sure there are no instances of glusterd on the host where you are trying to run the GlusterFS pods? When you run the following:
cd ~/gluster-kubernetes/deploy && ./gk-deploy -gy --abort && sudo vgremove -ff $(sudo vgdisplay | grep -i "VG Name" | awk '{print $3}') && sudo rm -rf /var/lib/heketi /etc/glusterfs /var/lib/glusterd /var/log/glusterfs && sudo pvremove /dev/loop200
Are you running everything after the --abort on all the nodes that'll have GlusterFS pods running? Are you also now running wipefs -a -f /dev/loop200 on all nodes?

I did have glusterfs-client installed on all the nodes. Hence, I deleted them via sudo apt remove gluster. Then I confirmed that no instance of glusterd was running via sudo systemctl status glusterd which results in
● glusterd.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

before reseting the previous gluster installation via the command cd ~/gluster-kubernetes/deploy && ./gk-deploy -gy --abort && sudo vgremove -ff $(sudo vgdisplay | grep -i "VG Name" | awk '{print $3}') && sudo rm -rf /var/lib/heketi /etc/glusterfs /var/lib/glusterd /var/log/glusterfs && sudo pvremove /dev/loop200
Here is the error log for the deploy pod after uninstalling the system installed glusterfs-client package
Heketi v5.0.0-80-g1f1c823
[kubeexec] WARNING 2017/11/06 18:14:44 Rebalance on volume expansion has been enabled.  This is an EXPERIMENTAL feature
[heketi] INFO 2017/11/06 18:14:44 Loaded kubernetes executor
[heketi] INFO 2017/11/06 18:14:44 Loaded simple allocator
[heketi] INFO 2017/11/06 18:14:44 GlusterFS Application Loaded
Listening on port 8080
[negroni] Started GET /clusters
[negroni] Completed 200 OK in 118.799µs
[negroni] Started POST /clusters
[negroni] Completed 201 Created in 51.790194ms
[negroni] Started POST /nodes
[sshexec] INFO 2017/11/06 18:14:59 Check Glusterd service status in node kraken
[kubeexec] DEBUG 2017/11/06 18:14:59 /src/github.com/heketi/heketi/executors/kubeexec/kubeexec.go:250: Host: kraken Pod: glusterfs-bv8sw Command: systemctl status glusterd
Result: ● glusterd.service - GlusterFS, a clustered file-system server
   Loaded: loaded (/usr/lib/systemd/system/glusterd.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2017-11-06 18:13:47 UTC; 1min 12s ago
  Process: 226 ExecStart=/usr/sbin/glusterd -p /var/run/glusterd.pid --log-level $LOG_LEVEL $GLUSTERD_OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 228 (glusterd)
   CGroup: /kubepods/burstable/pod3835911e-c31e-11e7-9309-201a06c9f06d/57353429ccd867c81ae58222bac424903cfaf13001d8a693967a0e7d47591c16/system.slice/glusterd.service
           └─228 /usr/sbin/glusterd -p /var/run/glusterd.pid --log-level INFO

Nov 06 18:13:44 kraken systemd[1]: Starting GlusterFS, a clustered file-system server...
Nov 06 18:13:47 kraken systemd[1]: Started GlusterFS, a clustered file-system server.
[heketi] INFO 2017/11/06 18:14:59 Adding node kraken
[negroni] Completed 202 Accepted in 131.431189ms
[asynchttp] INFO 2017/11/06 18:14:59 asynchttp.go:125: Started job def088a34030b4526b638a4317599c76
[negroni] Started GET /queue/def088a34030b4526b638a4317599c76
[negroni] Completed 200 OK in 31.498µs
[heketi] INFO 2017/11/06 18:14:59 Added node bd370c51ccb95119c7b71f29101dab69
[asynchttp] INFO 2017/11/06 18:14:59 asynchttp.go:129: Completed job def088a34030b4526b638a4317599c76 in 9.591038ms
[negroni] Started GET /queue/def088a34030b4526b638a4317599c76
[negroni] Completed 303 See Other in 45.047µs
[negroni] Started GET /nodes/bd370c51ccb95119c7b71f29101dab69
[negroni] Completed 200 OK in 355.836µs
[negroni] Started POST /devices
[heketi] INFO 2017/11/06 18:14:59 Adding device /dev/loop200 to node bd370c51ccb95119c7b71f29101dab69
[negroni] Completed 202 Accepted in 15.549189ms
[asynchttp] INFO 2017/11/06 18:14:59 asynchttp.go:125: Started job 0b475af2c2da99f54347995e1a523524
[negroni] Started GET /queue/0b475af2c2da99f54347995e1a523524
[negroni] Completed 200 OK in 29.752µs
[kubeexec] DEBUG 2017/11/06 18:15:00 /src/github.com/heketi/heketi/executors/kubeexec/kubeexec.go:250: Host: kraken Pod: glusterfs-bv8sw Command: pvcreate --metadatasize=128M --dataalignment=256K /dev/loop200
Result:   Physical volume "/dev/loop200" successfully created.
[negroni] Started GET /queue/0b475af2c2da99f54347995e1a523524
[negroni] Completed 200 OK in 47.352µs
[kubeexec] DEBUG 2017/11/06 18:15:00 /src/github.com/heketi/heketi/executors/kubeexec/kubeexec.go:250: Host: kraken Pod: glusterfs-bv8sw Command: vgcreate vg_238727c2f4edf3152cf75bb91178df97 /dev/loop200
Result:   Volume group "vg_238727c2f4edf3152cf75bb91178df97" successfully created
[kubeexec] DEBUG 2017/11/06 18:15:01 /src/github.com/heketi/heketi/executors/kubeexec/kubeexec.go:250: Host: kraken Pod: glusterfs-bv8sw Command: vgdisplay -c vg_238727c2f4edf3152cf75bb91178df97
Result:   vg_238727c2f4edf3152cf75bb91178df97:r/w:772:-1:0:0:0:-1:0:1:1:209580032:4096:51167:0:51167:JYhZzf-A88A-rFr3-oSx0-O8Qf-b4ji-M1jePV
[sshexec] DEBUG 2017/11/06 18:15:01 /src/github.com/heketi/heketi/executors/sshexec/device.go:141: Size of /dev/loop200 in kraken is 209580032
[heketi] INFO 2017/11/06 18:15:01 Added device /dev/loop200
[asynchttp] INFO 2017/11/06 18:15:01 asynchttp.go:129: Completed job 0b475af2c2da99f54347995e1a523524 in 1.124753123s
[negroni] Started GET /queue/0b475af2c2da99f54347995e1a523524
[negroni] Completed 204 No Content in 42.602µs
[negroni] Started POST /nodes
[sshexec] INFO 2017/11/06 18:15:01 Check Glusterd service status in node kraken
[kubeexec] DEBUG 2017/11/06 18:15:02 /src/github.com/heketi/heketi/executors/kubeexec/kubeexec.go:250: Host: kraken Pod: glusterfs-bv8sw Command: systemctl status glusterd
Result: ● glusterd.service - GlusterFS, a clustered file-system server
   Loaded: loaded (/usr/lib/systemd/system/glusterd.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2017-11-06 18:13:47 UTC; 1min 14s ago
  Process: 226 ExecStart=/usr/sbin/glusterd -p /var/run/glusterd.pid --log-level $LOG_LEVEL $GLUSTERD_OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 228 (glusterd)
   CGroup: /kubepods/burstable/pod3835911e-c31e-11e7-9309-201a06c9f06d/57353429ccd867c81ae58222bac424903cfaf13001d8a693967a0e7d47591c16/system.slice/glusterd.service
           └─228 /usr/sbin/glusterd -p /var/run/glusterd.pid --log-level INFO

Nov 06 18:13:44 kraken systemd[1]: Starting GlusterFS, a clustered file-system server...
Nov 06 18:13:47 kraken systemd[1]: Started GlusterFS, a clustered file-system server.
[heketi] INFO 2017/11/06 18:15:02 Adding node kraken01
[negroni] Completed 202 Accepted in 120.222439ms
[asynchttp] INFO 2017/11/06 18:15:02 asynchttp.go:125: Started job d798da1b80bfe899ad17ad769f952d58
[sshexec] INFO 2017/11/06 18:15:02 Probing: kraken -> <IP_ADDRESS>
[negroni] Started GET /queue/d798da1b80bfe899ad17ad769f952d58
[negroni] Completed 200 OK in 27.308µs
[kubeexec] ERROR 2017/11/06 18:15:02 /src/github.com/heketi/heketi/executors/kubeexec/kubeexec.go:247: Failed to run command [gluster peer probe <IP_ADDRESS>] on glusterfs-bv8sw: Err[command terminated with exit code 1]: Stdout []: Stderr [peer probe: failed: <IP_ADDRESS> is either already part of another cluster or having volumes configured
]
[negroni] Started GET /queue/d798da1b80bfe899ad17ad769f952d58
[negroni] Completed 200 OK in 33.872µs
[asynchttp] INFO 2017/11/06 18:15:02 asynchttp.go:129: Completed job d798da1b80bfe899ad17ad769f952d58 in 260.68287ms
[negroni] Started GET /queue/d798da1b80bfe899ad17ad769f952d58
[negroni] Completed 500 Internal Server Error in 30.171µs
[negroni] Started POST /nodes
[sshexec] INFO 2017/11/06 18:15:02 Check Glusterd service status in node kraken
[kubeexec] DEBUG 2017/11/06 18:15:02 /src/github.com/heketi/heketi/executors/kubeexec/kubeexec.go:250: Host: kraken Pod: glusterfs-bv8sw Command: systemctl status glusterd
Result: ● glusterd.service - GlusterFS, a clustered file-system server
   Loaded: loaded (/usr/lib/systemd/system/glusterd.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2017-11-06 18:13:47 UTC; 1min 15s ago
  Process: 226 ExecStart=/usr/sbin/glusterd -p /var/run/glusterd.pid --log-level $LOG_LEVEL $GLUSTERD_OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 228 (glusterd)
   CGroup: /kubepods/burstable/pod3835911e-c31e-11e7-9309-201a06c9f06d/57353429ccd867c81ae58222bac424903cfaf13001d8a693967a0e7d47591c16/system.slice/glusterd.service
           └─228 /usr/sbin/glusterd -p /var/run/glusterd.pid --log-level INFO

Nov 06 18:13:44 kraken systemd[1]: Starting GlusterFS, a clustered file-system server...
Nov 06 18:13:47 kraken systemd[1]: Started GlusterFS, a clustered file-system server.
[heketi] INFO 2017/11/06 18:15:02 Adding node kraken02
[negroni] Completed 202 Accepted in 132.0916ms
[asynchttp] INFO 2017/11/06 18:15:02 asynchttp.go:125: Started job 8db39aa64f7b3b2c49eb10582c87ea68
[sshexec] INFO 2017/11/06 18:15:02 Probing: kraken -> <IP_ADDRESS>
[negroni] Started GET /queue/8db39aa64f7b3b2c49eb10582c87ea68
[negroni] Completed 200 OK in 30.73µs
[negroni] Started GET /queue/8db39aa64f7b3b2c49eb10582c87ea68
[negroni] Completed 200 OK in 35.688µs
[kubeexec] ERROR 2017/11/06 18:15:02 /src/github.com/heketi/heketi/executors/kubeexec/kubeexec.go:247: Failed to run command [gluster peer probe <IP_ADDRESS>] on glusterfs-bv8sw: Err[command terminated with exit code 1]: Stdout []: Stderr [peer probe: failed: <IP_ADDRESS> is either already part of another cluster or having volumes configured
]
[asynchttp] INFO 2017/11/06 18:15:02 asynchttp.go:129: Completed job 8db39aa64f7b3b2c49eb10582c87ea68 in 301.710035ms
[negroni] Started GET /queue/8db39aa64f7b3b2c49eb10582c87ea68
[negroni] Completed 500 Internal Server Error in 37.854µs
[negroni] Started GET /clusters/9e3538e92521c7d7879617383e51575e
[negroni] Completed 200 OK in 183.262µs

Or from what I understand, you are saying that the Gluster-Kubernetes installation will fail if there is an underlying instance of glusterd running on the host OS? Hence I deleted glusterfs-client. However, it seems I get the exact same problem as before. Did I need to have a running instance of glusterd.service?

Specifically, running:
wipefs -a -f /dev/loop0

then redeploying the daemonset worked for me


Bootstrapify Calendar, including bootstrap subnav

Implemented as part of issue #958 to standardize the subnav component used on the site.
Style is mostly the same as before with bootstrap grid classes used.
Resizes reasonably nicely now, and the year header and footer dropdown are always centered too.
Additionally moved the custom page CSS to a an scss file.
Note: As previously discussed, I made separate commits for the file renames to haml, but I believe history of the renamed files will not be "tracked" if these commits are squashed on merge.

On squashing vs history - I'm personally not too bothered either way...
Another option would be that I could reauthor the commits down to 2 commits - one for renames, and the rest with the changes on a new branch and PR... But that is a bit of a faff.


What factor make the metric of mIOU higher than paper write?

Thank for you excellent work
I notice that the mIOU can up to 82%, but the author of PSPNet only acheive 76% - 77% ues resnet50 as backbone, what make the difference ?  Can you descirbe it ? Thank you so much.

Do you modify some network structure to improve the performance？

Do you modify some network structure to improve the performance？

Hi  @zhijiejia
If you are talking about Pascal VOC 2012, I just checked the paper and the results seem to be similar as found in Table 6 of the paper (note that their results is the test set and not val set, so 82 might translate to ~ 80 / 81 in the test set evaluation done in the evaluation server)

Hi  @zhijiejia
If you are talking about Pascal VOC 2012, I just checked the paper and the results seem to be similar as found in Table 6 of the paper (note that their results is the test set and not val set, so 82 might translate to ~ 80 / 81 in the test set evaluation done in the evaluation server)

sorry, i see the result(76% - 77%) in author's pspnet project, you are right,

sorry, i see the result(76% - 77%) in author's pspnet project, you are right,

By the way,  do you use the default config in this project when you train the pascal voc2012 dataset get the 82% mIOU on val set, , I run the default config, get the result: epoch: 80, mIOU on val set: 0.7739

By the way,  do you use the default config in this project when you train the pascal voc2012 dataset get the 82% mIOU on val set, , I run the default config, get the result: epoch: 80, mIOU on val set: 0.7739

Hi @zhijiejia
It has been a while since I run a test, so I don't quite remember the exact value. If you have a better config I would love to update it, thank.

Hi @zhijiejia
It has been a while since I run a test, so I don't quite remember the exact value. If you have a better config I would love to update it, thank.

Ok, Thank you for your prompt reply

Ok, Thank you for your prompt reply

Oh, I read the paper just，I find the paper get mIOU: 82，author use the resnet101 as its backbone. So there is reasonable for mIOU: 78% for resnet50 as backbone if we don't find a better way to train PSPNet.

Oh, I read the paper just，I find the paper get mIOU: 82，author use the resnet101 as its backbone. So there is reasonable for mIOU: 78% for resnet50 as backbone if we don't find a better way to train PSPNet.


[MATLAB] Add utility to wrap existing arrow::Array objects within  proxy objects.

Describe the enhancement requested
Similar to the utility added in #36853, it would be helpful to have one that wraps existing arrow::Array objects within proxy objects. This will help us implement methods that extract arrays from compound objects, such as arrow::RecordBatch, arrow::StructArray, etc.
Component(s)
MATLAB

take


Keep files that were selected elsewhere

Hello,
I couldn't find any questions that matched this one so I've posted mine.
Is there a way to determine (Without tracking files in my own application, avoiding redundancy) if a file was selected for full download instead of the entire file just being streamed.
In some cases when streaming a file to clients, a client might elect to have the file saved so that it's available again in the future without re-downloading.
I intend to have a cache folder for all streamed files that is cleared oldest first to prevent my HDD filling up as content is streamed. Is there a way to easily determine if the file was selected (and should be moved to be kept) ?
I wish to listen for the download event and move the file to another location so that it is not aged-off my HDD at a later stage.

First off, this seems like a bad idea, since it contradicts the bittorrent protocol expectations: one a peer has downloaded a piece, it should be able to seed it. If you delete the downloaded file, you will be unable to do so, and will break the protocol. So unless you become a leech (never seed) or leave the swarm entirely (don't make or accept peer connections), you can't delete the stored files.

I wish to listen for the download event and move the file to another location so that it is not aged-off my HDD at a later stage.

I believe 'download' event is emitted for each downloaded piece, not file. So you'd first have to check if a file is downloaded completely.

Is there a way to easily determine if the file was selected (and should be moved to be kept) ?

Selected means that t-s will try to download all the pieces that comprise a file. You can check the selection property, here's an example. Whether it's complete is a different story entirely: #113. Once a file is complete, it's no longer selected.

Thank you very much for your response, I do not wish to damage the health
of torrents but I don't wish to stay seeding for long periods of time
because I don't have the HDD space to keep every item I watch. Perhaps I
could remove/move it after a seed ratio is achieved.
I'll play around with it more, thanks for the links.


Add change tracking to forms and rewrite validation

Change tracking will enable the forms to be more straightforward. For example, changing the poster will be a separate API call, and as such it should be done on an unchanged form, otherwise cancelling the changes will not lead to cancelling the poster change, which may confuse users.

Validation should be rewritten as I don't really like the current approach - it was simple in the beginning, but now it's grown to be too complex. I already have a new way of doing it in mind - it will also allow me to seamlessly add change tracking to forms.


Suggestion: Ability to remove/ignore unessecary channels perhaps --ignore "channel name"

There's particular a channel called "How to use Pluto TV"
would be cool if it would be possible to do something like --ignore "How to use Pluto TV"

I've added an --ignore-groups option that can be given a regular expression (see the README for details). All groups that match the regular expression will be excluded from the playlist.

I've added an --ignore-groups option that can be given a regular expression (see the README for details). All groups that match the regular expression will be excluded from the playlist.

Hey I just saw it before you posted, thanks but it does not really well for me?
If I read it right this will remove all groups that is called "Nyt på Pluto TV", which you don't want since there's many channels called that and its called for every new channel when its "new"
example from the xml
#EXTINF:-1 tvg-id="xxx" tvg-logo="xx.png" tvg-chno="10" group-title="Nyt på Pluto TV", How to use Pluto TV
group-title="Nyt på Pluto TV"
channel name = How to use Pluto TV

I've added another option --exclude-channels <regex>. It works the same as --exclude-groups but it checks the channel name and not the group name.

I've added another option --exclude-channels <regex>. It works the same as --exclude-groups but it checks the channel name and not the group name.

Thank you a lot, I really appreciate this!


New extension: dice roller

Description
The extensions lets you roll any combination of dice, specified by an expression in common RPG format: i.e. '2d6 + 8'. It contains a single command that accepts a dice expression as an argument and copies the roll result to the clipboard, additionally showing the result on screen.
Screencast

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

Seemingly, importing rpg-dice-roller alone takes nearly a second to run. I may look into how the module is initialized when I have free time.

Could also be cool to improve this extension by @TroAlexis instead 🙂

Yes, I'll better contribute to that extension. I'm closing this issue, then. Thanks for the feedback!


Fix redis db option

I hit the same issue with v1.5.3 and this PR fixed it for me.
The error I got when running my tests was:
Redis::CommandError:
  ERR unknown command 'to_str'

If you're assigning an instance of Redis, it's class will not be an instance of Redis, as the code originally checked for. This caused it to create a new Redis instance, passing the assigned instance as if it were a URL string.

@soylent Thanks for your contribution! 👍


Missing/Extra Character in Intelligent Code Completion

HI,
I've recently encountered a problem.
There's a missing character in the position suggested by Copilot.
When selecting the cmp suggestion, an extra character is added.
( If more than one character is entered, there's no problem. )
Please refer to the image for more details.

-- use lazyvim config
{
    "nvim-cmp",
    dependencies = {
      {
        "zbirenbaum/copilot-cmp",
        dependencies = "copilot.lua",
        opts = {},
        config = function(_, opts)
          local copilot_cmp = require("copilot_cmp")
          copilot_cmp.setup(opts)
          -- attach cmp source whenever copilot attaches
          -- fixes lazy-loading issues with the copilot cmp source
          require("lazyvim.util").on_attach(function(client)
            if client.name == "copilot" then
              copilot_cmp._on_insert_enter({})
            end
          end)
        end,
      },
    },
    ---@param opts cmp.ConfigSchema
    opts = function(_, opts)
      table.insert(opts.sources, 1, { name = "copilot", group_index = 2 })
      opts.sorting = opts.sorting or require("cmp.config.default")().sorting
      table.insert(opts.sorting.comparators, 1, require("copilot_cmp.comparators").prioritize)
    end,
  }

I can confirm this is happening for me as well! Looks like there were some recent commits to change the starting character. The commit 307e9aba4ad1f3133768e803e62ada995230e950 set the starting character to 0 and then 11eb015fbf9f07ad1c72dbdc9d830ebac610b5cd undid that change in lua/copilot_cmp/format.lua in the same commit there were also some changes made to lua/copilot_cmp/completion_functions.lua which could be the culprit. I am fairly new to neovim and doing plugin stuff, so I have no idea how I would start testing this out locally. This started happening after I updated neovim a couple hours ago and after checking out all my other plugins that could be messing with my autocomplete stuff this is what makes the most sense to me. If I manually move my cursor one character to the left and then accept the copilot completion this bug doesn't occur.

I see there are quite a few issues open so I can try to figure this out locally and submit a PR because it will probably start driving me a little crazy tomorrow haha.

I can't seem to reproduce this at all, I can't even get the pictured completion to appear when I copy that file. Could you try reverting the commit and see if it does anything?

I see there are quite a few issues open so I can try to figure this out locally and submit a PR because it will probably start driving me a little crazy tomorrow haha.

Yeah there are a good amount. The problem is that fixing one issue typically causes a slew of other ones when dealing with cmp. When I had an api for users creating their own format handlers no one seemed to use them.
cmp and the lsp spec in general isn't really designed to handle multiline completions, and attempts to fix it seems to make things worse in half the cases.

Yeah that makes sense, I never remember having an issue with multiline completions but I also tend to avoid the multi line completions because I end up having to fix more than is worth it half the time. Out of curiosity what was the trigger? I was only like halfway through figuring out how to use a local copy of a plugin instead of the one my plugin manager was wanting to use.

Test out #92

I've downloaded and tested the newly submitted PR.
The unexplained extra character issue has been resolved. Thanks.
However, the format alignment issue seems to still occur (although this doesn't really affect my usage).

For the indentation misalignment issue, please refer to the image below.
Intelligent suggestions that appear after a new line are missing a character.

Upon selecting the intelligent suggestion, the format becomes disordered (The results are as expected when pressing Tab or Enter at this time).

Thanks again for your bug fix. It's a great help to me.

I've downloaded and tested the newly submitted PR.
The unexplained extra character issue has been resolved. Thanks.
However, the format alignment issue seems to still occur (although this doesn't really affect my usage).

For the indentation misalignment issue, please refer to the image below.
Intelligent suggestions that appear after a new line are missing a character.

Upon selecting the intelligent suggestion, the format becomes disordered (The results are as expected when pressing Tab or Enter at this time).

Thanks again for your bug fix. It's a great help to me.

What alignment issue are you talking about here? It looks perfect to me in the video so I'm a bit confused

I'm going to merge the fix since this seems to work for most things and then address the alignment in a follow up, please make a new issue for it @xiaofenglee

Thank you @zbirenbaum!


All devices show as "Updating"

Describe the bug
all tuya devices show up as updating. they work through the homebridge ui, however not in the home.app
Plugin Version
@milo526/homebridge-tuya-web v1.1.2
Homebridge Config
{
"name": "TuyaWebPlatform",
"options": {
"username": "redacted",
"password": "redacted",
"countryCode": "357",
"platform": "tuya"
},
"defaults": [
{
"id": "Bedroom Shutter",
"device_type": "cover",
"cover_characteristics": [
"Stop"
]
},
{
"id": "Office Shutter",
"device_type": "cover",
"cover_characteristics": [
"Stop"
]
},
{
"id": "Boiler Switch",
"device_type": "switch"
},
{
"id": "Blue",
"device_type": "light"
},
{
"id": "White",
"device_type": "light"
},
{
"id": "Guest WC",
"device_type": "light"
},
{
"id": "Bedroom Light",
"device_type": "light"
},
{
"id": "Bathroom",
"device_type": "light"
},
{
"id": "Kitchen Lights",
"device_type": "light"
},
{
"id": "Veranda Lights",
"device_type": "light"
},
{
"id": "Cloud",
"device_type": "light"
}
],
"scenes": false,
"platform": "TuyaWebPlatform"
}

[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] [Red] - Unsetting debouncedDeviceStateRequestPromise
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] Sending HTTP GET request to /homeassistant/skill - Header: {"name":"QueryDevice","namespace":"query","payloadVersion":1}.
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] [Bedroom Light] - Unsetting debouncedDeviceStateRequestPromise
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] Sending HTTP GET request to /homeassistant/skill - Header: {"name":"QueryDevice","namespace":"query","payloadVersion":1}.
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] [Boiler Switch] - Unsetting debouncedDeviceStateRequestPromise
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] Sending HTTP GET request to /homeassistant/skill - Header: {"name":"QueryDevice","namespace":"query","payloadVersion":1}.
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] [Blue] - Unsetting debouncedDeviceStateRequestPromise
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] Sending HTTP GET request to /homeassistant/skill - Header: {"name":"QueryDevice","namespace":"query","payloadVersion":1}.
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] [Hallway Lights] - Unsetting debouncedDeviceStateRequestPromise
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] Sending HTTP GET request to /homeassistant/skill - Header: {"name":"QueryDevice","namespace":"query","payloadVersion":1}.
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] [Bedroom Shutter] - Unsetting debouncedDeviceStateRequestPromise
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] Sending HTTP GET request to /homeassistant/skill - Header: {"name":"QueryDevice","namespace":"query","payloadVersion":1}.
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] [White] - Unsetting debouncedDeviceStateRequestPromise
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] Sending HTTP GET request to /homeassistant/skill - Header: {"name":"QueryDevice","namespace":"query","payloadVersion":1}.
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] [Office Shutter] - Unsetting debouncedDeviceStateRequestPromise
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] Sending HTTP GET request to /homeassistant/skill - Header: {"name":"QueryDevice","namespace":"query","payloadVersion":1}.
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] [Light] - Unsetting debouncedDeviceStateRequestPromise
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] Sending HTTP GET request to /homeassistant/skill - Header: {"name":"QueryDevice","namespace":"query","payloadVersion":1}.
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] [Spots] - Unsetting debouncedDeviceStateRequestPromise
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] Sending HTTP GET request to /homeassistant/skill - Header: {"name":"QueryDevice","namespace":"query","payloadVersion":1}.
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] [Switch inching] - Unsetting debouncedDeviceStateRequestPromise
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] Sending HTTP GET request to /homeassistant/skill - Header: {"name":"QueryDevice","namespace":"query","payloadVersion":1}.
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] [WC Light] - Unsetting debouncedDeviceStateRequestPromise
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] Sending HTTP GET request to /homeassistant/skill - Header: {"name":"QueryDevice","namespace":"query","payloadVersion":1}.
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] [Fan] - Unsetting debouncedDeviceStateRequestPromise
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] Sending HTTP GET request to /homeassistant/skill - Header: {"name":"QueryDevice","namespace":"query","payloadVersion":1}.
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] [Switch inching] - Unsetting debouncedDeviceStateRequestPromise
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] Sending HTTP GET request to /homeassistant/skill - Header: {"name":"QueryDevice","namespace":"query","payloadVersion":1}.
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] [Bar] - Unsetting debouncedDeviceStateRequestPromise
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] Sending HTTP GET request to /homeassistant/skill - Header: {"name":"QueryDevice","namespace":"query","payloadVersion":1}.
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] [Kitchen] - Unsetting debouncedDeviceStateRequestPromise
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] Sending HTTP GET request to /homeassistant/skill - Header: {"name":"QueryDevice","namespace":"query","payloadVersion":1}.
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] [Switch inching] - Unsetting debouncedDeviceStateRequestPromise
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] Sending HTTP GET request to /homeassistant/skill - Header: {"name":"QueryDevice","namespace":"query","payloadVersion":1}.
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] [Bathroom Lights] - Unsetting debouncedDeviceStateRequestPromise
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] Sending HTTP GET request to /homeassistant/skill - Header: {"name":"QueryDevice","namespace":"query","payloadVersion":1}.
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] [Water Pressure] - Unsetting debouncedDeviceStateRequestPromise
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] Sending HTTP GET request to /homeassistant/skill - Header: {"name":"QueryDevice","namespace":"query","payloadVersion":1}.
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] [Switch inching] - Unsetting debouncedDeviceStateRequestPromise
[8/16/2022, 10:49:17 PM] [TuyaWebPlatform] Sending HTTP GET request to /homeassistant/skill - Header: {"name":"QueryDevice","namespace":"query","payloadVersion":1}.
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [WC Light] - Resolving resolveDeviceStateRequest from remote
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [WC Light] - Set device state request cache
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [WC Light] Characteristic.On - [GET] false
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Boiler Switch] - Renewing cache due to RateLimitError
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Boiler Switch] Characteristic.On - [GET] false
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Switch inching] - Renewing cache due to RateLimitError
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Switch inching] - Device Offline
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Water Pressure] - Renewing cache due to RateLimitError
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Water Pressure] Characteristic.On - [GET] true
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Bedroom Light] - Renewing cache due to RateLimitError
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Bedroom Light] Characteristic.On - [GET] false
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Hallway Lights] - Renewing cache due to RateLimitError
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Hallway Lights] Characteristic.On - [GET] true
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Bathroom Lights] - Resolving resolveDeviceStateRequest from remote
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Bathroom Lights] - Set device state request cache
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Bathroom Lights] Characteristic.On - [GET] false
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Switch inching] - Resolving resolveDeviceStateRequest from remote
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Switch inching] - Set device state request cache
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Switch inching] Characteristic.On - [GET] false
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Red] - Resolving resolveDeviceStateRequest from remote
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Red] - Set device state request cache
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Red] Characteristic.On - [GET] false
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Blue] - Renewing cache due to RateLimitError
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Blue] Characteristic.On - [GET] false
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Spots] - Renewing cache due to RateLimitError
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Spots] - Device Offline
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [White] - Renewing cache due to RateLimitError
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [White] Characteristic.On - [GET] false
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Bedroom Shutter] - Renewing cache due to RateLimitError
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Bedroom Shutter] Characteristic.CurrentPosition - [GET] 3
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Bedroom Shutter] Characteristic.CurrentPosition - Updating value { support_stop: true, online: true, state: 3 }
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Bedroom Shutter] Characteristic.TargetPosition - [GET] 3
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Kitchen] - Renewing cache due to RateLimitError
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Kitchen] Characteristic.On - [GET] false
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Bar] - Renewing cache due to RateLimitError
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Bar] Characteristic.On - [GET] false
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Switch inching] - Renewing cache due to RateLimitError
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Switch inching] Characteristic.On - [GET] false
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Switch inching] - Renewing cache due to RateLimitError
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Switch inching] Characteristic.On - [GET] false
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Fan] - Renewing cache due to RateLimitError
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Fan] Characteristic.On - [GET] false
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Light] - Renewing cache due to RateLimitError
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Light] - Device Offline
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Office Shutter] - Renewing cache due to RateLimitError
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Office Shutter] Characteristic.CurrentPosition - [GET] 3
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Office Shutter] Characteristic.CurrentPosition - Updating value { support_stop: true, online: true, state: 3 }
[8/16/2022, 10:49:18 PM] [TuyaWebPlatform] [Office Shutter] Characteristic.TargetPosition - [GET] 3

Is this still happening?
Is this constant or intermittent?
I see nothing wrong in the logs. Could it be that it was a problem between your iPhone/iPad/Mac and homebridge instead of this plugin?

Is this still happening?
Is this constant or intermittent?
I see nothing wrong in the logs. Could it be that it was a problem between your iPhone/iPad/Mac and homebridge instead of this plugin?

I rebuilt the whole homebridge from scratch since no one cared to reply to me in both discord and here.


Vue router scrollBehavior returns same path for both to and from

Version
^2.2.1
Steps to reproduce
I would like to check the to and from of the route path with scrollBehavior to manage the scroll behavior.
global.router = new VueRouter({
    routes,
    scrollBehavior(to, from, savedPosition) {
        console.log('>>> to', to);
        console.log('>>> from', from);
        switch (to.path) {
            case '/in-list':
                break;
            case '/your-list':
                break;
            default:
                return {x: 0, y: 0}
        }
    },
    mode: 'history',
});

Suppose, I navigate from About page to In-List or Your-list, I would like to return {x: 0, y: 0}. However, when navigating between In-List or Your-list I would like no such behaviour.
What am I missing here?
What is expected?
Navigating from one-page to different-page, the value of to and from should return the path of to and from respectively.
e.g: to should return path to /one-page and from should return path to /different-page
What is actually happening?
However, when navigating from one-page to different-page, the value of both to and from are the same. The value of to is correct, however, the value of from's path is of the to's path as well.
e.g: to returns the path /one-page and from also returns the same path /one-page

I was using version ^2.2.1 and I saw this closed issue #1207 and found that this was resolved in version 2.3.1.


Roll Engine from a0d89b1a543d to 36eb9a67a8ff (1 revision)

https://github.com/flutter/engine/compare/a0d89b1a543d...36eb9a67a8ff
2021-08-04<EMAIL_ADDRESS>Roll Skia from 40b82c6b5c2c to 9fdcc517b2be (4 revisions) (flutter/engine#27891)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


/var/lib/rancher/k3s/storage should not be world-readable.

/var/lib/rancher/k3s/storage should not be world-readable.

This will probably need to be resolved via an issue in https://github.com/rancher/local-path-provisioner

Validated on master branch commit a4c992ce521110ba90d077717b93dab926c7cae8
Only changes were made to items within the storage directory.

/var/lib/rancher/k3s/storage directory has 0755 permissions
Items within storage directory correctly have 0700 permissions

$ ls -la /var/lib/rancher/k3s/storage/
total 16
drwxr-xr-x 4 root root 4096 Jul  9 17:56 .
drwxr-xr-x 6 root root 4096 Jul  9 17:50 ..
drwx------ 2 root root 4096 Jul  9 17:56 pvc-435bf9d1-8dd8-45d6-aee7-17f17798a9d0_default_other-path-pvc
drwx------ 2 root root 4096 Jul  9 17:50 pvc-614bcf34-9f1c-4c17-8af5-7010134e5509_default_local-path-pvc

$ stat -c %a /var/lib/rancher/k3s/storage/
755

$ stat -c %a /var/lib/rancher/k3s/storage/pvc-435bf9d1-8dd8-45d6-aee7-17f17798a9d0_default_other-path-pvc/
700

$ stat -c %a /var/lib/rancher/k3s/storage/pvc-614bcf34-9f1c-4c17-8af5-7010134e5509_default_local-path-pvc/
700

@rancher-max this is not fixed, and in fact broke all volumes for containers running not as root. See https://github.com/k3s-io/k3s/issues/3704, which reported this as a k3s regression.
From https://github.com/rancher/local-path-provisioner/issues/182#issue-827747922, /var/lib/rancher/k3s/storage shouln't be world-readable (but restricted to root), and individual volumes should be chmod 777:

So volume itself is 0777, but the parent directory secured with 0700 and accessible by root only.

@flokli I see that you've found the linked issue that tracks fixing the regression, is there any reason in particular that you're adding comments to the original PR and this closed issue?

@brandond I guess I was mostly confused about where the chmods happen, and whether k3s did workaround a change done in local-path-provisioner, or if these changes (and regressions) all appeared in the k3s local-storage manifest.
Maybe it might make sense to update https://github.com/rancher/local-path-provisioner/issues/182#issuecomment-892594450 to set things clear.

As you can see from the PRs, we don't use the sample deployment yaml that is in the local-path-provisioner YAML, so we haven't changed anything on that side.

Validated on branch <branch_name> with commit <commit_id> / version
Environment Details

Infrastructure

[X] Cloud
[ ] Hosted

Node(s) CPU architecture, OS, and Version:

Linux ip-172-31-13-52 5.19.0-1025-aws #26~22.04.1-Ubuntu SMP Mon Apr 24 01:58:15 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
PRETTY_NAME="Ubuntu 22.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.2 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

Cluster Configuration:

1 server

Config.yaml:

cluster-init: true
write-kubeconfig-mode: 644
token: test

Additional files

pvc.yaml:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: local-path-pvc
  namespace: default
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: local-path
  resources:
    requests:
      storage: 2Gi

pod.yaml:
apiVersion: v1
kind: Pod
metadata:
  name: volume-test
  namespace: default
spec:
  containers:
  - name: volume-test
    image: nginx:stable-alpine
    imagePullPolicy: IfNotPresent
    volumeMounts:
    - name: volv
      mountPath: /data
    ports:
    - containerPort: 80
  volumes:
  - name: volv
    persistentVolumeClaim:
      claimName: local-path-pvc

Testing Steps

Copy config.yaml

$ sudo mkdir -p /etc/rancher/k3s && sudo cp config.yaml /etc/rancher/k3s

Install k3s
Run the following commands:

$ kubectl create -f pvc.yaml
$ kubectl create -f pod.yaml
$ kubectl get pv
$ kubectl get pic
$ kubectl get nodes, pods -A - o wide
$ stat -c %a /var/lib/rancher/k3s/storage/

Replication Results:

k3s version used for replication:

k3s -v
k3s version v1.24.13+k3s1 (3f79b289)
go version go1.19.8

k3s -v
k3s version v1.25.9+k3s1 (7502ce6a)
go version go1.19.8

k3s -v
k3s version v1.26.4+k3s1 (8d0255af)
go version go1.19.8

k3s -v
k3s version v1.27.1+k3s1 (bc5b42c2)
go version go1.20.3

stat -c %a /var/lib/rancher/k3s/storage/
701

Validation Results:

k3s version used for validation:

k3s -v
k3s version v1.24.14-rc2+k3s1 (313a3b99)
go version go1.19.9

k3s -v
k3s version v1.25.10-rc2+k3s1 (613a3bc8)
go version go1.19.9

k3s -v
k3s version v1.26.5-rc2+k3s1 (6cd54032)
go version go1.19.9

k3s -v
k3s version v1.27.2-rc2+k3s1 (91c5e0d7)
go version go1.20.4

stat -c %a /var/lib/rancher/k3s/storage/
700

Additional context / logs:
N/A


let aiderignore use info/exclude

Issue
aiderignore suggests to edit the project-wide gitignore to exlude .aider.* files;
however not every user must use aider as it is not a build requirement.
For personal setup, use .git/info/exclude instead
Version and model info
No response

Thank you for filing this issue.
If I understand your question/suggestion correctly, you do not want to have to put the .aider.* entry in every project .gitignore which you use aider for, correct?
You can create a global gitignore file (e.g. ~/.config/git/ignore and put
.aider.*

in it, then those files will get automatically ignored in every project, without the need to put this entry into every project.gitignore file, also aider will not bother you about this anymore.

It's just that it is bad practice to spam a common .gitignore files with your personal setup, like files produced by your IDE or command-line tools, and aider should rather facilitate best than bad practice. A global personal .gitignore is a work-around but I am still under the impression that .gitignore is rather for build artifacts.

Aider won't modify an existing .gitignore file without asking you first.

That's good, point is that even better would be asking about modifying info/exclude instead of .gitignore. Even if of all repo users agree on Aider being an indispensable build tool, it's still rather meant for build output artifacts.

Aider won't offer to modify .gitignore if you add .aider* to  .git/info/exclude or to .gitignore_global.

That's good for those who got it right from the start, though the help entry for --gitignore read as if those who did not add them there would be led astray (by proposing an entry to .gitignore first by default).

For example, I start in aider in a new repo and it says
$ aider
Add .aider* to .gitignore (recommended)? (Y)es/(N)o [Yes]:

The point I was trying to make that this is not to be recommended.
Instead, I'd gladly add them to .git/info/exclude instead, if for matter of fact, it hadn't already happened as I added them there in the git template folder.
So my advice is to document this and let the user decide instead of aider pushing for it.

¯_(ツ)_/¯

Aider won't offer to modify .gitignore if you add .aider* to .git/info/exclude or to .gitignore_global.

Hi @paul-gauthier
Looks like aider doesn't respect that.
Step1: When I run cat .git/info/exclude
The result is
# git ls-files --others --exclude-from=.git/info/exclude
# Lines that start with '#' are comments.
# For a project mostly in C, the following would be a good set of
# exclude patterns (uncomment them if you want to use them):
# *.[oa]
# *~
# *aider*
.aider*

When running aider, it still asks for .aider* and .env to gitignore...

Just
## Enable/disable adding .aider* to .gitignore (default: True)
gitignore: false

as a new default would work for now

Aider looks to be sure that .aider* and .env are excluded. It honors any way that git supports such exclusions:
(aider) macbook:...tmp/new$ git init
(aider) macbook:...tmp/new$ echo '.aider*' > .git/info/exclude
(aider) macbook:...tmp/new$ echo '.env' >> .git/info/exclude
(aider) macbook:...tmp/new$ aider
──────────────────────────────────────────────────────────────────────────────────────────────────────────────
Aider v0.62.2.dev
Main model: claude-3-5-sonnet-20241022 with diff edit format, infinite output
Weak model: claude-3-5-haiku-20241022
Git repo: .git with 0 files
Repo-map: using 1024 tokens, auto refresh
Use /help <question> for help, run "aider --help" to see cmd line args
──────────────────────────────────────────────────────────────────────────────────────────────────────────────
>

Aider looks to be sure that .aider* and .env are excluded. It honors any way that git supports such exclusions:
(aider) macbook:...tmp/new$ git init
(aider) macbook:...tmp/new$ echo '.aider*' > .git/info/exclude
(aider) macbook:...tmp/new$ echo '.env' >> .git/info/exclude
(aider) macbook:...tmp/new$ aider
──────────────────────────────────────────────────────────────────────────────────────────────────────────────
Aider v0.62.2.dev
Main model: claude-3-5-sonnet-20241022 with diff edit format, infinite output
Weak model: claude-3-5-haiku-20241022
Git repo: .git with 0 files
Repo-map: using 1024 tokens, auto refresh
Use /help <question> for help, run "aider --help" to see cmd line args
──────────────────────────────────────────────────────────────────────────────────────────────────────────────
>

Thanks for the work @paul-gauthier . I believe this is available in master branch build, in that case I will check it tomorrow (around 12 hours from now).

This should be working this way in the released version.


Qualify WSO2 Identity Server endpoints with tenant in path - (phase 01)

Description:
In WSO2 Identity Server, there is a requirement to make all the endpoints tenant qualified. The tenant qualified URL pattern for the endpoints should take the form '/t/{tenant.domain}'.
Eg:  localhost:9443/t/{tenant.domain}/scim2/users
Currently, apart from the rest APIs, almost all the other endpoints are having the same endpoint for all the tenants.
Eg: localhost:9443/commonauth
A few endpoints are tenant-qualified by appending the tenant domain as a query parameter to the URLs whereas some are tenant-qualified by appending the tenant domain as a path parameter to the URLs.
With this feature enabled, all the URLs would have the tenant domain as a path parameter as described above. If the inbound/outbound traffic in the identity server can be made tenant-qualified, it would pave the way for a bunch of new improvements and features.
Tasks:
The following are the main tasks that has been identified for the first phase of this feature.

[x] Add a utility to construct service urls of the server

[x] Tenant-qualify Core Inbound paths to the server

[x] Tenant-qualify Core Outbound paths

[x] Tenant-qualify URLs metadata documents

[x] Allow access to super tenant from server base context

[x] Restrict access to super tenant with carbon.super in path param

[x] Cover integration and unit tests for non tenant qualified url mode

[ ] Track migration impact for tenant qualified URL

Content Related to migration tracked and added to gdoc.


Badgeview for Xamarin Android

Badgeview for Xamarin Android , Unable to implement BadgeView in my project tried below link
https://www.nuget.org/packages/Xam.Plugin.Badge
http://nugetmusthaves.com/Package/Xam.Plugin.Badge
Please help me out with this if i am missing anything , else would appreciate if you could do a tutorial video for the BadgeView in Android/iOS/WindowsPhone

This worked for me:
https://github.com/danidomi/android-viewbadger-Xamarin


make pulsar executor pool size configurable

Motivation
The pulsar executor pool size number is hard code to 20 when pulsar service start, it should be configurable in broker.conf.
private final ScheduledExecutorService executor = Executors.newScheduledThreadPool(20,
            new DefaultThreadFactory("pulsar"));

Changes
make the executor pool size configurable in broker.conf

As a followup to these changes in thread pool sizes, it would be nice to reduce the size of these pools when running the unit tests

As a followup to these changes in thread pool sizes, it would be nice to reduce the size of these pools when running the unit tests

Yes, for the unit tests framework, i will reduce the pool size.

As a followup to these changes in thread pool sizes, it would be nice to reduce the size of these pools when running the unit tests

Yes, for the unit tests framework, i will reduce the pool size.

@merlimat @jiazhai  I have changed the default executor pool size to Runtime.getRuntime().availableProcessors() and update unit test executor pool size to 5, please take a look, thanks.

/pulsarbot run-failure-checks


:open_book: Docs: core-concepts Missing content

What should be changed?
Can I improve the missing content of the document core-concepts

Thank you for submitting an issue! 🙌 Could you please show more detail?
What is missing? English version or Chinese version?

Do you mean #862 ? But it seems that core-concepts is not on the list.

Chinese version Partial deletion

Any snapshots? Thank you!

Chinese version Partial deletion

Any snapshots? Thank you!

dependencies.zh.md
output.zh.md
stateconfig.zh.md
variables.zh.md

Hi @mfordjody, thanks for wanting to improve our project!
It seems you want to translate a bunch of documentation from English to Chinese, did I get that right?
To clarify, at the moment, we put English documentation as our top priority, because it's more international. Also, for Chinese documentation, we have internal translators who could help.
Please read our https://docs.devstream.io/en/release-0.7/contributing_guide/ and I'm sure you can find some other issues to contribute!

close the issue，thank you


File cannot be uploaded

Hi
I am having trouble uploading my reads.histo file online. Every time I do, it gives an error message that the file is not uploaded. Can you please me with this. Thanks
script:
jellyfish count -C -m 21 -s<PHONE_NUMBER> -t 16 oscaffolds.reduced_1.fq oscaffolds.reduced_2.fq -o reads.jf
jellyfish histo -t 16 reads.jf> reads.histo

Cleaning up now. Please try again!
Mike
On Mon, Oct 24, 2022 at 10:34 PM AkshitaJain2709 @.***>
wrote:

Hi
I am having trouble uploading my reads.histo file online. Every time I do,
it gives an error message that the file is not uploaded. Can you please me
with this. Thanks
—
Reply to this email directly, view it on GitHub
https://github.com/schatzlab/genomescope/issues/86, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABP344DK6UVQUVRBNN7SYDWE5BLZANCNFSM6AAAAAARNQ7RGA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Hello, I am having the same problem!

Please try again - we ran out of disk space on the server
Good luck!
Mike
On Thu, Dec 1, 2022 at 4:22 AM mdim @.***> wrote:

Hello, I am having the same problem!
—
Reply to this email directly, view it on GitHub
https://github.com/schatzlab/genomescope/issues/86#issuecomment-1333467390,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABP343QAE6LQ4DJS3OLTZ3WLBU6HANCNFSM6AAAAAARNQ7RGA
.
You are receiving this because you commented.Message ID:
@.***>

Looks like this issue is happening again

Please try again!
Mike
On Mon, Mar 20, 2023 at 11:54 AM sjclare @.***> wrote:

Looks like this issue is happening again
—
Reply to this email directly, view it on GitHub
https://github.com/schatzlab/genomescope/issues/86#issuecomment-1476495092,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABP3455OOPUWCHOCJR5D4TW5B4VFANCNFSM6AAAAAARNQ7RGA
.
You are receiving this because you commented.Message ID:
@.***>


standard confuses string with missing quotes and new class instance without brackets

If I have the code:
const onionoo = new Onionoo()

to create a new instance of the Onionoo class but leave off the brackets:
const onionoo = new Onionoo

standard says:
standard: Use JavaScript Standard Style (http://standardjs.com)
standard: Run `standard --fix` to automatically fix some problems.

/Users/lukechilds/Dev/oss/onionoo-node-client/test/unit.js
  18:19  error  Missing '

It seems like maybe it assumes Onionoo is a string without quotes. It would be better if it would warn that there are no parenthesis on the class (or not warn at all, not sure of the pros/cons of leaving off parenthesis). I would assume this would be fairly easy to fix by checking if the new keyword is directly before the string.

Just realised standard uses eslint under the hood, should I be reporting this there?

@lukechilds yup :+1:

@dcousens according to ESLint this appears to be an issue with standard. It gets reported correctly as Missing '()' invoking a constructor. (new-parens) with vanilla ESLint.
https://github.com/eslint/eslint/issues/7792

@lukechilds actually, it appears to be an issue with you :laughing:
var Onionoo
const onionoo = new Onionoo

console.log(onionoo)

standard: Use JavaScript Standard Style (http://standardjs.com)
standard: Run standard --fix to automatically fix some problems.
/home/daniel/test.js:2:17: Missing '()' invoking a constructor.

Ahhhh, found the culprit!
It's not doing it if I call standard directly but if I call snazzy it does with the exact same input.
$ standard
standard: Use JavaScript Standard Style (http://standardjs.com)
standard: Run `standard --fix` to automatically fix some problems.
  /Users/lukechilds/Dev/oss/onionoo-node-client/test/unit.js:14:19: Missing '()' invoking a constructor.

$ snazzy
standard: Use JavaScript Standard Style (http://standardjs.com)
standard: Run `standard --fix` to automatically fix some problems.

/Users/lukechilds/Dev/oss/onionoo-node-client/test/unit.js
  14:19  error  Missing '

✖ 1 problem

Should I open the issue on snazzy? 😆

@lukechilds I think so,  feel free to post back and we'll re-open if needed :+1:


add spec.suspend to Kustomization printer columns

This adds spec.suspend to the default columns of Kustomization.
It's currently hard to find Kustomizations that are suspended, and I think that's a pretty common use-case when leveraging that feature.
It's currently a default column as it's pretty slim anyway, but it could also be set to only show for -o wide.
The PR also moves the Status column to the end, after Age, since the messages are very long in error cases, which makes the columns behind it hard to find, and breaks up the table header as well.

flux get kustomization does have the suspended field and the Git SHAs are trimmed. Any reason for not using Flux CLI?

Oh, true, I forgot that flux get exists :grimacing:
But it's just habit to use kubectl as the primary method for interacting with resources, and I'd argue that it would be more convenient like this.

The suspend field is preset in almost all Flux APIs. Please open an issue in the flux2 with a proposal to change this in a consistent manner. If the maintainers of all Flux controllers are supportive of this change, then we need to open PRs everywhere and ship this as a whole in the next Flux minor release.

flux get kustomization does have the suspended field and the Git SHAs are trimmed. Any reason for not using Flux CLI?

would help with k9s integration


Next song not playing when current song finishes and app is in background

I think I fixed it with prev update, but not sure

This is fixed now


Obervers can hit ingame players

when a player that's about to die gets hit by an observer, the kill is counted for the observers.
for example, if someone falls from a skybridge, and an observer hits him in the air, when he falls to the ground the kill is for the obs, same if someone falls to the void

Fixed by c369d57faf4db5c7a6d3595528cd2442a50e1a37

Still a bug in lastest version, fixed it for 1.9

Fixed in 1.9


pluggable pakcages

closes: #5

Should we consider requiring signed commits for our reference "packages" as argo cd apps so that the idpbuilder can be built to trust only official reference packages? https://argo-cd.readthedocs.io/en/release-1.8/user-guide/gpg-verification/ we can also allow users to configure their own gpg keys to use for verification as flag to idpbuilder create? https://argo-cd.readthedocs.io/en/release-1.8/user-guide/gpg-verification/#configure-using-declarative-setup

Should we consider requiring signed commits for our reference "packages" as argo cd apps so that the idpbuilder can be built to trust only official reference packages?

Did not know about this. We should 100% do this for our reference packages.
My current thinking around git server stuff:

I think embedded FS is quite useful for providing the reference implementation and possibly for use in air gapped environments. Great way to tie manifests to a idpbuilder release with no external dependencies or secrets to worry about.

As discussed in #32, Gitea is a great idea. This allows us to pull stuff from a remote repository using user credentials, push it to the in-cluster git server. We will need to handle kustomize remote references and helm subcharts to ensure everything we need is pushed to the in-cluster git server.

Ok I've incorporated ideas posted above.
TLDR:

Use gittea.
Support syncing local files to git
Replace repo urls with local  repo urls in application spec.
No support for imperative pipelining spec until concrete use cases arise.

About Git server contents:
Is mirroring content from remotes to in-cluster git server the right way to go? This becomes a bit more complicated once you start dealing with nested remotes. Especially for helm. We pretty much need to:

Get the root chart tgz
Extract, check dependencies.
If there are subcharts, pull them.
Repeat 1-3
Replace urls in dependencies for all subcharts. Tarball.
Push all to cluster.

This breaks signing on charts as well, but not sure if it matters for local.
If we are to render them, things are a bit simpler.

Get values.
Render. e.g. helm template
Push manifests to the cluster.
Update Argo App to use directory instead.

This means we have to make sure we are using the same process to render manifests as ArgoCD does. So more libraries, dependencies, and potentially deal with rendering logic. This also pretty much won't allow you to take advantage of FluxCD source mechanisms IF we decide to support Flux in the future.

About Git server contents:
Is mirroring content from remotes to in-cluster git server the right way to go? This becomes a bit more complicated once you start dealing with nested remotes. Especially for helm. We pretty much need to:

Get the root chart tgz
Extract, check dependencies.
If there are subcharts, pull them.
Repeat 1-3
Replace urls in dependencies for all subcharts. Tarball.
Push all to cluster.

This breaks signing on charts as well, but not sure if it matters for local.
If we are to render them, things are a bit simpler.

Get values.
Render. e.g. helm template
Push manifests to the cluster.
Update Argo App to use directory instead.

This means we have to make sure we are using the same process to render manifests as ArgoCD does. So more libraries, dependencies, and potentially deal with rendering logic. This also pretty much won't allow you to take advantage of FluxCD source mechanisms IF we decide to support Flux in the future.
Also note that to support ArgoCD app of Apps, we need to render locally. Because app of apps could be inside a Helm Chart, Kustomize, or plain manfiests.
We can also pass local credentials to the cluster but I am not sure if that's a good practice. I can't be sure which credentials should be passed. Passing all would not be a good idea imo.

I don't see any drawback to rendering and then pushing to local gitserver. Am I missing something? Is it simply that we would have a dependency on helm as a lib in idpbuilder?

I don't see any drawback to rendering and then pushing to local gitserver. Am I missing something? Is it simply that we would have a dependency on helm as a lib in idpbuilder?

Yeah pretty much. Dependencies on Helm and Kustomize libraries. We'll probably have to get the rendering logic from ArgoCD so this will add more dependencies. I am leaning towards just rendering them instead. More dependencies but simpler.

@nabuskey Would it make sense only to mirror contents which are referenced by a local path? In the case of an argo app which already has a remote it might be ok to just use that remote directly. The main win for the gitserver IMO is removing the dependency on having to push packages to some external mirror, but if the package is already pushed this shouldnt be an issue.

I agree with this, I think the only issue is how much we can keep the code paths between local and remote as unified as possible. I would hate to have to handle two separate "pipelines" of artifact herding when there is a design choice that could result in only 1 being necessary. However, based on @nabuskey comment about needing to match the rendering to argo's means that the tradeoff complexity might be more of a burden. I will take a back seat on this decision as you guys know this plumbing better than me. My only concern is that we have a great local workflow for developers that doesn't require pushing to a remote just to test changes during quick iteration.

To extend the proposition of @nabuskey to use internally a git server (= gitea), I would like to mention these points too:

Make the git server accessible from admin users externally (UI or SSH)
Clone ALL the resources within the git server (core components: ingress, argocd & cert manager + pluggable). Why ? To let an admin user to change a resource when problem took place during deployment and to avoid to rebuild idpbuilder CLI, etc
Refactor the localbuilds.idpbuilder.cnoe.io CRD to better describe a package to be installed, source: URL, OCI image; type: core or pluggable (we should find a better name), packaging mode: helm, plain, kustomize, etc; config (= params)
Use a Package or Component CRD to deploy everything on the platform including core and pluggable
Convert the Package or Component CRD to their GitOps equivalent. Why: to be able to support different implementations: argocd, fluxcd, Crossplane, Terraform etc. So our CRD could be translated for ArgocD to an Application CRD, for FluxCD to a GitRepository, etc

* Make the git server accessible from admin users externally (UI or SSH)

100% agreed. Being able to visualize and interact with git is valuable.

* Clone ALL the resources within the git server (core components: ingress, argocd & cert manager + pluggable). Why ? To let an admin user to change a resource when problem took place during deployment and to avoid to rebuild `idpbuilder CLI`, etc

This was my intention as well. We will need to make ArgoCD manage itself but should be easy. I will clarify that in the doc.

* Refactor the `localbuilds.idpbuilder.cnoe.io` CRD to better describe a package to be installed.

* Component or Package CRD definition:

  * Name, labels
  * Source: URL, OCI image, bucket
  * Type: core or pluggable (we should find a better name)
  * Packaging type: helm, plain, kustomize
  * Config: = parameters

* Use a Package or Component CRD to deploy everything on the platform including core and pluggable

* Convert the Package or Component CRD to their GitOps equivalent. Why: to be able to support different implementations: argocd, fluxcd, Crossplane, Terraform etc. So our CRD could be translated for ArgocD to an Application CRD, for FluxCD to a GitRepository, etc

I think these make sense as this project matures. I have a few concerns at this stage where we want to focus on use cases in local settings.

We can provide abstraction for these implementations but there must be a well defined limit. These technologies vary widely between how they are used and how they work. We have to put a lot more thoughts on these alone.

I also think this is getting a bit close to application modeling. Application modeling is hard. There has been attempts at modeling applications like OAM with Kubevela. As far as I am aware, there are no solutions that the industry is converging to. We need to be careful abut introducing another.

Dependencies and overheads. We will have to import a lot of dependencies and match rendering logic versions.

These are great discussion points to follow up after this PR. I think we should keep it simple and nail the local experience first. I think it's a low hanging fruit that we can immediately see its values on.


Fixes #33 Added support for banner text

Pull Request Test Coverage Report for Build 91

0 of 0 (NaN%) changed or added relevant lines in 0 files are covered.
8 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.09%) to 94.154%

Files with Coverage Reduction
New Missed Lines
%

.tox/py2/lib/python2.7/site-packages/friendlyshell/base_shell.py
8
91.06%

Totals

Change from base Build 85:
0.09%

Covered Lines:
1244

Relevant Lines:
1305

💛  - Coveralls


AssetBundles should check if dependencies already registered

I have a case here where I have an AssetBundle (AB1) registered and another AssetBundle (AB2) has the AB1 as a dependency.
At runtime I now get the same AB1 showing up twice in the AssetManager.
Is that expected behaviour?
I would expect the function \yii\web\View::registerAssetBundle() to check if a dependency is already registered or am I misunderstanding the concept?

It's checking it so your case could be considered a bug. Can you help reproducing it using simple asset bundles and basic app?

Ok... found the problem.
Have debugged it a bit more and it's like this...
AB1 is registered as "something\somethingElse\SomeAsset"
But in AB2 the dependency is set as "\something\somethingElse\SomeAsset"
So it's because of the leading "".
Not sure if registerAssetBundle() should resolve this or not or has the author of AB2 set the dependency incorrectly?

I think it could be resolved by framework normalizing class names in AssetBundle::init(). @yiisoft/core-developers thoughts?

We have already disscussed this at #3143 and at #6007.
The conclusion has been already made and there is a corresponding warning in the docs.


Some URLs are not picked up by HellPot

I'm not sure if this is my fault or not, but I appreciate the feedback.
I've set up HellPot to respond to ALL requests. See the config below. Despite this config and the setup in nginx (also below) some URLs still return 404 Not Found. I am not sure why
Please note that the "error.crt" in my nginx config is a simple self-signed certificate that already blocks some malicious clients.

nginx config
server {
    listen      80 default_server;
    listen 443 ssl http2 default_server;
    listen [::]:443 ssl http2 default_server;
    server_name _;
    location / {
        limit_rate 5k;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://<IP_ADDRESS>:8081$request_uri;
    }
    ssl_certificate     /etc/openresty/tls/error.crt;
    ssl_certificate_key /etc/openresty/tls/error.key;
}

hellpot config
[deception]
server_name = 'nginx'

[http]
bind_addr = '<IP_ADDRESS>'
bind_port = '8081'
real_ip_header = 'X-Real-IP'
uagent_string_blacklist = ['Cloudflare-Traffic-Manager']
unix_socket_path = '/var/run/hellpot'
unix_socket_permissions = '0666'
use_unix_socket = false

[http.router]
catchall = true
makerobots = true
paths = ['wp-login.php', 'wp-login']

[logger]
debug = true
directory = '/home/sander/.local/share/HellPot/logs'
nocolor = false
trace = false
use_date_filename = true

[performance]
max_workers = 256
restrict_concurrency = false

Notable URLs that return a 404 instead of HellPot:

/_profiler/phpinfo
.git/config
/actuator/gateway/routes

The special character (_, .) is a hint but I'm not sure if this is something in HellPot or my nginx (config).

Interesting, I'll look into this


Additional Tools: Part 1

This PR adds some additional tools to the editor, and changes some existing ones:

Soft Hyphen ()

Node that draws as a semi-transparent dash.

Anchor Tag ()

Note that draws as an anchor in a box with its id shown when hovering.

Alignment (when not left aligned,
...
)

Alignment within tables or other blocks is also done this way.

Tables

Cells cannot be merged. The first row of the table will always be the table header. You should expect the same limitations as markdown tables, and set up your styles accordingly.

Links now show their previous title and url when you attempt to create a link in the same position, making them easier to edit.
Inline Styles can now be used in the JSON output mode.
A document has been included that demonstrates different kinds of tool, and what their output result looks like.

Implementation
The new tools have been implemented in the language-markdown project, as some of them piggyback on the same html_inline handling as inline styles (anchor, hard break in tables) which are now initialized as part of the json language as well. All other tools require custom markdown parsers and serializers, so have been added to the markdown language since most of the tool work is done getting them working in markdown anyways.
For the consuming side, markdown renderers used must allow inline html if they want to use:

Anchor (a[id])

 in tables
Inline Styles (span[class])
Alignment (p[align])
You could potentially extend your markdown parser to filter out just the tags we use if you don't want other tags being used.

I'm not sure I like the toolbar getting as long as it is. Maybe we should come up with another way to inject or remove toolbar items from the default, rather than making users redefine the whole thing.

A few additional changes have been made:

There is now a title parameter, which displays a title above the rich text editor when present.
Since raw HTML tags are used for a few features, replace any reserved HTML characters like < with escaped variants like <. This avoids some confusing errors.
Alignment is now done via a style attribute (with text-align), or a class attribute of predefined name.

The inline style method produces code like
...

The class method uses predefined classes. It is activated by passing useClasses as true in the initialisation parameters.

The classes are, by default, in the format amp-align-<alignment>, eg. amp-align-left. You can override these class names with a classOverride parameter: `"classOverride": {"amp-align-left": "custom-align-right"}

When creating an anchor, it now enforces a globally unique anchor ID, and informs you when the provided ID is not valid.
Changed some key behaviour with lists to better match Word, or other wysiwyg editors. It's not a perfect match, as our structure for lists is a bit different.

A few additional changes have been made:

There is now a title parameter, which displays a title above the rich text editor when present.
Since raw HTML tags are used for a few features, replace any reserved HTML characters like < with escaped variants like <. This avoids some confusing errors.
Alignment is now done via a style attribute (with text-align), or a class attribute of predefined name.

The inline style method produces code like
...

The class method uses predefined classes. It is activated by passing useClasses as true in the initialisation parameters.

The classes are, by default, in the format amp-align-<alignment>, eg. amp-align-left. You can override these class names with a classOverride parameter: `"classOverride": {"amp-align-left": "custom-align-right"}

When creating an anchor, it now enforces a globally unique anchor ID, and informs you when the provided ID is not valid.
Changed some key behaviour with lists to better match Word, or other wysiwyg editors. It's not a perfect match, as our structure for lists is a bit different.

Updated HOSTING.md to reflect the new hosting arrangements.

Can the PR be renamed to start with "feat: " and include a sensible feature name as this will be recorded in the CHANGELOG.md when merge down.

Is the new name alright?


fix: randomize role-names and bucket-name for auth and storage category

Description of changes:
Randomizing account-wide unique names like IAM role names, S3 bucket names (based on the Cloudformation Stack ID).
This prevents deployment issues for S3Buckets and Auth resources (when deploying same project in the same account).
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #2709 into master will increase coverage by 3.82%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #2709      +/-   ##
==========================================
+ Coverage   61.86%   65.69%   +3.82%
==========================================
  Files         211      198      -13
  Lines       10292     9692     -600
  Branches     1953     1962       +9
==========================================
  Hits         6367     6367
+ Misses       3651     3049     -602
- Partials      274      276       +2

Impacted Files
Coverage Δ

...lify-graphql-types-generator/src/compiler/index.ts
90.32% <0%> (ø)
:arrow_up:

...y-graphql-types-generator/src/compiler/legacyIR.ts
96.72% <0%> (ø)
:arrow_up:

...ages/amplify-appsync-simulator/src/server/index.ts
0% <0%> (ø)
:arrow_up:

...sync-simulator/src/schema/appsync-scalars/index.ts

...plify-appsync-simulator/src/velocity/util/index.ts

...mplify-appsync-simulator/src/mqtt-server/server.ts

...ync-simulator/src/velocity/util/transform/index.ts

...plify-appsync-simulator/src/server/subscription.ts

...-appsync-simulator/src/velocity/util/list-utils.ts

...simulator/src/data-loader/dynamo-db/utils/index.ts

... and 8 more

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 5467679...5d90fb5. Read the comment docs.


Cleanups

Electron with its browser engine doesnt need those prefixes

I see. Then it would be helpful to document the supported browsers somewhere and add more prefixes when needed. Is there a consensus on what browsers and version should be supported?

As @roramirez said, these prefixes are needed for other browsers. We officially only support Electron, but stuff like this makes it possible for others to use it as well. I don't think we should add more official supported browsers.


Add sdk versions to prometheus

Motivation
When the association scrapes fullnode /metrics endpoints, we would also like to get the sdk language being used for the jsonRPC requests
Have you read the Contributing Guidelines on pull requests?
yes
Test Plan
unit tests
If targeting a release branch, please fill the below out as well
Affects jsonRPC endpoints. No breaking changes- just prometheus metrics changes
We would like to have this in for the launch so that the ecosystem team can understand what SDKs people are using for development, and guide our resource allocation accordingly.

This PR may have modified JSON-RPC server code.
Breaking changes policy:

Chaning JSON-RPC method signatures or removing/modifying fields
in the response in /V1 will not be accepted.
Adding fields is ok.
Adding a new JSON-RPC method is ok.

Please ensure you have also done the following to update the docs:

Update json-rpc/API-CHANGELOG.md.
Add/update type/method documentation under json-rpc/docs.

@CapCap Looks like you're going to need to fix some formatting before this will be able to be landed.

:exclamation: Land has been canceled due to this PR being updated with new commits. Please issue another Land command if you want to requeue this PR.

/land


Weird result when checking if a point is inside a polygon

Thanks for the great project. I am using the contains function to check if a point is inside a polygon. It works great for most cases, but some result looks weird.
For the following example, it will report that the point is not inside the polygon, which is apparently inside from the plot.
>>> xv = [0.5,0.2,1.0,0,0.8,0.5]
>>> yv = [1.0,0.1,0.7,0.7,0.1,1]
>>> xq = 0.5
>>> yq = 0.6
>>> polygon = Polygon(list(zip(xv, yv)))
>>> polygon.contains(Point(xq, yq))
False

Operating system
Windows 10
Shapely version and provenance
Ver 2.0.4 installed from PyPI using pip

The polygon is not valid (several crossing edges), so it will not necessarily return valid predicate results:
>>> polygon.is_valid
False

In this case, using a zero-length buffer to extract the outer boundary will work for the predicate:
>>> polygon = polygon.buffer(0)
>>> polygon.contains(Point(xq, yq))
True

Unfortunately shapely.make_valid does not work here because of the degree of self-intersections; it drops the interior shape, and so the predicate remains false, but for different reasons:

Got it, it makes sense now. Thanks!


alt toggling by click doesn't work when module is in group

I have a following config (simplified):
...
    "modules-right": ["group/status"],
    "group/status": {
        "orientation":"inherit",
        "modules": [
            "sway/language",
            "power-profiles-daemon",
            "pulseaudio",
            "network",
            "battery",
            "clock"
        ],
    },
    "clock": {
        "tooltip-format": "<big>{:%Y %B}</big>\n<tt><small>{calendar}</small></tt>",
        "format-alt": "{:%Y-%m-%d}"
    },
...

modules added to the group don't switch to format-alt when clicking on them. on-click does work (for example for power-profiles-daemon, pulseaudio and sway/language).
weirdly, if I'll add a module twice, both in and out of the group, both modules format-alt start to work just fine.
waybar version 0.10.0-2

Already reported in #2685 and fixed in my pending PR waiting approval #3068

@vafu PR has been merged. You can give it a try but it should be fixed now.


Updating master with live

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

biztalk/core/domain-groups.md
:white_check_mark:Succeeded
View

biztalk/core/high-availability-using-sql-server-always-on-availability-groups.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Automatoc node when using push method

Dear mobizt,
I'm running on a project using nano and firebase, thankfully I found your helpful library.
But when I tried to push some value using push() method, seems Firebase generate an automatic ID using random character.
Can we eliminate that process so we can pass our json string as we want ?
Thanks and best regards,
Hery

That related to the Firebase API that we can't change.
You can use set instead of push.

Dear mobizt,
I see, thanks for your prompt reply.


feat: add variable admin_password

Allow configuration of a custom admin password.
Fixes equinor/terraform-baseline#122

@stiross79 This should fix your issue 🙂