Commant request: Unsupported

What command(s) would you like to add?
Unsupported
When a language-to-GLS compiler finds syntax it doesn't know how to parse, it should be able to represent this complaint forward to the GLS compiler in some way. That way GLS can intelligently complain about it.
Parameters

reason: Text explaining why the syntax is unsupported

Sample usage
unsupported: (GLS does not support switch statements)

Why
The GLS compiler needs a good way to read from CS-GLS or TS-GLS that something wasn't able to be converted. Right now it just coincidentally complains that improper complaint strings generated by those compilers is invalid.
Instead, whenever it sees an unsupported command, it should consider that to be an error, and give better debug info in the error complaint.
Compiled language equivalents
C#
/* (unsupported syntax: GLS does not support switch statements) */

Java
/* (unsupported syntax: GLS does not support switch statements) */

JavaScript
/* (unsupported GLS syntax: GLS does not support switch statements) */

Python
''' (unsupported GLS syntax: GLS does not support switch statements) '''

Ruby
=begin
(unsupported GLS syntax: GLS does not support switch statements)
=end

TypeScript
/* (unsupported GLS syntax: GLS does not support switch statements) */

Hmm, I wonder what the response within GLS to an unsupported line should be. Should the overall results from transforming a file contain an Unsupported[] array of some sort, so we know whether it was successful?
For now, I think I'll have the command just throw an error (ugh), pending a better understanding of the right thing to do.

After #458 goes in, I think #275 would be a good way to do this.


Version bump to <IP_ADDRESS>

Signed-off-by: Dave Lago<EMAIL_ADDRESS>opensearch-security pull request intake form
Version bump to <IP_ADDRESS>

Category: (Enhancement, New feature, Bug fix, Test fix, Refactoring, Maintenance, Documentation)
Maintenance

Codecov Report

Merging #1536 (bdbbae6) into main (3e01690) will increase coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##               main    #1536   +/-   ##
=========================================
  Coverage     64.88%   64.88%
- Complexity     3228     3230    +2
=========================================
  Files           247      247
  Lines         17335    17335
  Branches       3072     3072
=========================================
+ Hits          11247    11248    +1
+ Misses         4532     4531    -1
  Partials       1556     1556

Impacted Files
Coverage Δ

...security/configuration/DlsFlsFilterLeafReader.java
59.76% <0.00%> (-0.71%)
:arrow_down:

...ecurity/configuration/ConfigurationRepository.java
75.27% <0.00%> (+2.19%)
: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 3e01690...bdbbae6. Read the comment docs.


Can I choose the windows install path instead of %appdata%

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

I don't want to install it in the %appdata%

could you explain me why this is a problem and why we might parametrize it?

It may be a small problem. When my windows server restart, the path of %appdata% will be clean. Then the storage data will be empty. Can’t I install it to another path like “npm install -g verdaccio —path=...”. This just a small suggestion.

If I understand your problem, the issue is with npm client, not with Verdaccio itself.


Exception in root generation for empty tree

Describe the bug
When attempting to retrieve the root for an empty MerkleTree, a RecursionError is encountered.
To Reproduce
>>> from merkly.mtree import MerkleTree
>>> mtree = MerkleTree([])
>>> mtree.root

Expected behavior
I understand that the root for an empty tree isn't really defined, but it would be better to either return None or raise a more deliberate Exception rather than entering into an infinite recursion loop.
Desktop (please complete the following information):

OS: MacOS
Version 0.8.1

No problem I added a PR 👍
Actually it seems like the issue is mostly avoided by your recent commit to add the validate_leafs() function (https://github.com/olivmath/merkly/commit/a0fbd4e18031563bba3f8add006c0ab1add365d7) however just in case the leaves attribute is modified directly I added a check into the make_root() method.


Traffic mirroring to an external service in another cluster does not work

Bug description
I'm currently trying to mirror traffic from A cluster(service) to B cluster(service), yet, when I make a request to the httpbin Service in A cluster via a curl Pod I created, I can see the requests in the A service, but can't see any kind of requests in the B service. Both services are injected with sidecar.
I also cannot execute tcpdump on sidecars because tcpdump doesn’t work in the sidecar pod - the container doesn’t run as root.
These are the debugging outputs in A Cluster:
$ istioctl-1.4 pc routes httpbin-v2-5b7749cd64-zw8sf -ojson
...
             {
                "name": "httpbin.default.stage.foo.bar:80",
                "domains": [
                    "httpbin.default.stage.foo.bar",
                    "httpbin.default.stage.foo.bar:80"
                ],
                "routes": [
                    {
                        "name": "default",
                        "match": {
                            "prefix": "/"
                        },
                        "route": {
                            "cluster": "outbound|80||httpbin.default.stage.foo.bar",
                            "timeout": "0s",
                            "retryPolicy": {
                                "retryOn": "connect-failure,refused-stream,unavailable,cancelled,resource-exhausted,retriable-status-codes",
                                "numRetries": 2,
                                "retryHostPredicate": [
                                    {
                                        "name": "envoy.retry_host_predicates.previous_hosts"
                                    }
                                ],
                                "hostSelectionRetryMaxAttempts": "5",
                                "retriableStatusCodes": [
                                    503
                                ]
                            },
                            "maxGrpcTimeout": "0s"
                        },
                        "decorator": {
                            "operation": "httpbin.default.stage.foo.bar:80/*"
                        },
                        "typedPerFilterConfig": {
                            "mixer": {
                                "@type": "type.googleapis.com/istio.mixer.v1.config.client.ServiceConfig",
                                "disableCheckCalls": true,
                                "mixerAttributes": {
                                    "attributes": {
                                        "destination.service.host": {
                                            "stringValue": "httpbin.default.stage.foo.bar"
                                        },
                                        "destination.service.name": {
                                            "stringValue": "httpbin.default.stage.foo.bar"
                                        },
                                        "destination.service.namespace": {
                                            "stringValue": "default"
                                        }
                                    }
                                },
                                "forwardAttributes": {
                                    "attributes": {
                                        "destination.service.host": {
                                            "stringValue": "httpbin.default.stage.foo.bar"
                                        },
                                        "destination.service.name": {
                                            "stringValue": "httpbin.default.stage.foo.bar"
                                        },
                                        "destination.service.namespace": {
                                            "stringValue": "default"
                                        }
                                    }
                                }
                            }
                        }
                    }
                ]
            },
            {
                "name": "httpbin.default.svc.cluster.local:80",
                "domains": [
                    "httpbin.default.svc.cluster.local",
                    "httpbin.default.svc.cluster.local:80"
                ],
                "routes": [
                    {
                        "match": {
                            "prefix": "/"
                        },
                        "route": {
                            "cluster": "outbound|8080||httpbin.default.svc.cluster.local",
                            "timeout": "0s",
                            "retryPolicy": {
                                "retryOn": "connect-failure,refused-stream,unavailable,cancelled,resource-exhausted,retriable-status-codes",
                                "numRetries": 2,
                                "retryHostPredicate": [
                                    {
                                        "name": "envoy.retry_host_predicates.previous_hosts"
                                    }
                                ],
                                "hostSelectionRetryMaxAttempts": "5",
                                "retriableStatusCodes": [
                                    503
                                ]
                            },
                            "requestMirrorPolicy": {
                                "cluster": "outbound|80||httpbin.default.stage.foo.bar",
                                "runtimeFraction": {
                                    "defaultValue": {
                                        "numerator": 100
                                    }
                                }
                            },
                            "maxGrpcTimeout": "0s"
                        },
                        "metadata": {
                            "filterMetadata": {
                                "istio": {
                                    "config": "/apis/networking/v1alpha3/namespaces/default/virtual-service/httpbin"
                                }
                            }
                        },
                        "decorator": {
                            "operation": "httpbin.default.svc.cluster.local:8080/*"
                        },
                        "typedPerFilterConfig": {
                            "mixer": {
                                "@type": "type.googleapis.com/istio.mixer.v1.config.client.ServiceConfig",
                                "disableCheckCalls": true,
                                "mixerAttributes": {
                                    "attributes": {
                                        "destination.service.host": {
                                            "stringValue": "httpbin.default.svc.cluster.local"
                                        },
                                        "destination.service.name": {
                                            "stringValue": "httpbin"
                                        },
                                        "destination.service.namespace": {
                                            "stringValue": "default"
                                        },
                                        "destination.service.uid": {
                                            "stringValue": "istio://default/services/httpbin"
                                        }
                                    }
                                },
                                "forwardAttributes": {
                                    "attributes": {
                                        "destination.service.host": {
                                            "stringValue": "httpbin.default.svc.cluster.local"
                                        },
                                        "destination.service.name": {
                                            "stringValue": "httpbin"
                                        },
                                        "destination.service.namespace": {
                                            "stringValue": "default"
                                        },
                                        "destination.service.uid": {
                                            "stringValue": "istio://default/services/httpbin"
                                        }
                                    }
                                }
                            }
                        }
                    }
                ]
            },
...

$ istioctl-1.4 pc cluster httpbin-v2-5b7749cd64-zw8sf
    {
        "name": "outbound|80||httpbin.default.stage.foo.bar",
        "type": "STRICT_DNS",
        "connectTimeout": "10s",
        "loadAssignment": {
            "clusterName": "outbound|80||httpbin.default.stage.foo.bar",
            "endpoints": [
                {
                    "lbEndpoints": [
                        {
                            "endpoint": {
                                "address": {
                                    "socketAddress": {
                                        "address": "httpbin.default.stage.foo.bar",
                                        "portValue": 80
                                    }
                                }
                            },
                            "loadBalancingWeight": 1
                        }
                    ],
                    "loadBalancingWeight": 1
                }
            ]
        },
        "circuitBreakers": {
            "thresholds": [
                {
                    "maxConnections":<PHONE_NUMBER>,
                    "maxPendingRequests":<PHONE_NUMBER>,
                    "maxRequests":<PHONE_NUMBER>,
                    "maxRetries":<PHONE_NUMBER>
                }
            ]
        },
        "dnsRefreshRate": "300s",
        "respectDnsTtl": true,
        "dnsLookupFamily": "V4_ONLY"
    },
    {
        "name": "outbound|8000||httpbin.default.svc.cluster.local",
        "type": "EDS",
        "edsClusterConfig": {
            "edsConfig": {
                "ads": {}
            },
            "serviceName": "outbound|8000||httpbin.default.svc.cluster.local"
        },
        "connectTimeout": "10s",
        "circuitBreakers": {
            "thresholds": [
                {
                    "maxConnections":<PHONE_NUMBER>,
                    "maxPendingRequests":<PHONE_NUMBER>,
                    "maxRequests":<PHONE_NUMBER>,
                    "maxRetries":<PHONE_NUMBER>
                }
            ]
        }
    },
    {
        "name": "inbound|8000|http|httpbin.default.svc.cluster.local",
        "type": "STATIC",
        "connectTimeout": "10s",
        "loadAssignment": {
            "clusterName": "inbound|8000|http|httpbin.default.svc.cluster.local",
            "endpoints": [
                {
                    "lbEndpoints": [
                        {
                            "endpoint": {
                                "address": {
                                    "socketAddress": {
                                        "address": "<IP_ADDRESS>",
                                        "portValue": 80
                                    }
                                }
                            }
                        }
                    ]
                }
            ]
        },
        "circuitBreakers": {
            "thresholds": [
                {
                    "maxConnections":<PHONE_NUMBER>,
                    "maxPendingRequests":<PHONE_NUMBER>,
                    "maxRequests":<PHONE_NUMBER>,
                    "maxRetries":<PHONE_NUMBER>
                }
            ]
        }
    }

Expected behavior
When I make a request to httpbin Service in the A cluster with
kubectl exec -it sleep-67957cdd96-hlcds -c sleep -- sh -c 'curl http://httpbin:8000/headers', I expect the request to be mirrored to the httpbin Service in the B cluster.
Interestingly, with this Virtual Service in A Cluster, the traffic gets mirrored but this is not usable in my case:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: httpbin
  namespace: default
spec:
  hosts:
    - httpbin.default.stage.foo.bar
  http:
  - route:
    - destination:
        host: httpbin.default.stage.foo.bar
        port:
          number: 80
      weight: 100
    mirror:
      host: httpbin
      port:
        number: 8000
    mirror_percent: 100

Steps to reproduce the bug
In A Cluster:

Create a httpbin Service and Deployment.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpbin
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpbin
  template:
    metadata:
      labels:
        app: httpbin
    spec:
      containers:
      - image: docker.io/kennethreitz/httpbin
        imagePullPolicy: IfNotPresent
        name: httpbin
        command: ["gunicorn", "--access-logfile", "-", "-b", "<IP_ADDRESS>:80", "httpbin:app"]
        ports:
        - containerPort: 80

---

apiVersion: v1
kind: Service
metadata:
  name: httpbin
  namespace: default
  labels:
    app: httpbin
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 80
  selector:
    app: httpbin

Create a Virtual Service for mirroring.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: httpbin
  namespace: default
spec:
  hosts:
    - httpbin
  http:
  - route:
    - destination:
        host: httpbin
        port:
          number: 8000
      weight: 100
    mirror:
      host: httpbin.default.stage.foo.bar
      port:
        number: 80
    mirror_percent: 100

Create a Service Entry for the external service.

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: set
  namespace: default
spec:
  hosts:
  - httpbin.default.stage.foo.bar
  exportTo:
  - "."
  ports:
  - number: 80
    name: http
    protocol: HTTP
  location: MESH_EXTERNAL
  resolution: DNS

In B Cluster:

Create the same httpbin Service and Deployment.

Create a Gateway for the ingress traffic.

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: istio-ingress
  namespace: shared
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - '*.stage.foo.bar'
    port:
      name: http2-dev
      number: 80
      protocol: http2

Create a Virtual Service to route ingress traffic to the httpbin Service.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: 'http2-default'
  namespace: 'shared'
spec:
  gateways: ["istio-ingress"]
  hosts:
  - "*.stage.foo.bar"
  - match:
      - port: 80
        authority:
          prefix: "httpbin.default"
    route:
      - destination:
          host: "httpbin.default.svc.cluster.local"
          port:
            number: 8000

Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)

A Cluster:

$ istioctl version --remote
client version: 1.5.1
control plane version: 1.4.5
data plane version: 1.4.5 (121 proxies)
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.1", GitCommit:"7879fc12a63337efff607952a323df90cdc7a335", GitTreeState:"clean", BuildDate:"2020-04-10T21:53:51Z", GoVersion:"go1.14.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"15+", GitVersion:"v1.15.11-gke.3", GitCommit:"71631703d37fb1b4b333abd427deae839aeb2032", GitTreeState:"clean", BuildDate:"2020-03-24T18:54:48Z", GoVersion:"go1.12.17b4", Compiler:"gc", Platform:"linux/amd64"}

B Cluster:

$ istioctl version --remote
client version: 1.5.1
control plane version: 1.5.2
data plane version: 1.5.2 (11 proxies)
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.1", GitCommit:"7879fc12a63337efff607952a323df90cdc7a335", GitTreeState:"clean", BuildDate:"2020-04-10T21:53:51Z", GoVersion:"go1.14.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"15+", GitVersion:"v1.15.11-gke.9", GitCommit:"e1af17fd873e15a48769e2c7b9851405f89e3d0d", GitTreeState:"clean", BuildDate:"2020-04-06T20:56:54Z", GoVersion:"go1.12.17b4", Compiler:"gc", Platform:"linux/amd64"}

How was Istio installed?
Istio was installed using Helm.
Environment where bug was observed (cloud vendor, OS, etc)
GKE

Hey, I am with @Hmerac on this one. It popped back into my head, that we can tcpdump anyway since the network interface in the pod is shared by all containers, hence we can see all packets.
Anyhow, here is what I found when curling the httpbin from the above mentioned curl pod.
GET /status/200 HTTP/1.1
host: httpbin-shadow:8000
user-agent: curl/7.52.1
accept: */*
x-forwarded-proto: http
x-request-id: df05de93-5778-91df-a4ae-bd657b86e148
x-envoy-decorator-operation: httpbin.default.svc.cluster.local:8000/*
x-istio-attributes: CiUKGGRlc3RpbmF0aW9uLnNlcnZpY2UubmFtZRIJEgdodHRwYmluCisKHWRlc3RpbmF0aW9uLnNlcnZpY2UubmFtZXNwYWNlEgoSCGhvdGVsYWRzCjEKCnNvdXJjZS51aWQSIxIha3ViZXJuZXRlczovL2R1bW15LTMwMTQyLmhvdGVsYWRzCkAKGGRlc3RpbmF0aW9uLnNlcnZpY2UuaG9zdBIkEiJodHRwYmluLmhvdGVsYWRzLnN2Yy5jbHVzdGVyLmxvY2FsCj4KF2Rlc3RpbmF0aW9uLnNlcnZpY2UudWlkEiMSIWlzdGlvOi8vaG90ZWxhZHMvc2VydmljZXMvaHR0cGJpbg==
x-b3-traceid: 0f30c8ed91a0587664df136fae19aa22
x-b3-spanid: 64df136fae19aa22
x-b3-sampled: 1
x-envoy-internal: true
x-forwarded-for: <IP_ADDRESS>
content-length: 0

HTTP/1.1 404 Not Found
date: Thu, 14 May 2020 06:55:34 GMT
server: istio-envoy
content-length: 0

The host header for the mirrored request was set to httpbin-shadow:8000. I would have expected to see httpbin.default.stage.foo.bar-shadow or httpbin.default.stage.foo.bar-shadow:80.
What are we missing?

As far as I can see from the config dump, the mirroring sends requests directly to the cluster (see requestMirrorPolicy), i.e. the request is neither modified nor goes through any kind of routing (like one would expect when setting up a virtual service for the mirror target in the source cluster).
I.e. the host of the curl request should be httpbin.default.svc.cluster.local or any kind of abbreviation of the service host. I don't see though where the httpbin-shadow come from. Did you curl that host?
Given that finding, the gateway on the target cluster needs to react on the original host (which is not in *.stage.foo.bar`), otherwise the request will be dropped.

The httpbin-shadow comes from Envoy; its mirroring module suffixes the host/authority header with -shadow and the port is added at the very end as well.
We curled http://httpbin:8000/status/200 in cluster A.

We got this figured out.
Envoy textually appends "-shadow" to the host header, i.e. you can end up with one the following values, depending on how you target the service in the source cluster (the one you want to mirror):
<service>-shadow, <service>.<namespace>-shadow and <service>.<namespace>.svc.cluster.local-shadow.
On the target cluster, the only chance you currently have is to react on "*" in the servers/host section of the ingress' gateway resource, otherwise you would need to add all possible combinations there. This is IMO a good reason for a feature request in envoy to make this configurable (e.g. to change it to ".shadow").
apiVersion: networking.istio.io/v1beta1
kind: Gateway
# [...]
spec:
  servers:
  - hosts:
    - '*' # < --- allow all hosts

On the target cluster, you have to also add a "*-shadow" to the host section of the virtual services attached to the ingress gateway. If you match for hosts in the http section, you should use "prefix", which will cover names ending with "-shadow".
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
# [...]
spec:
  hosts:
  # [...]
  - "*-shadow"  # <--- allow shadowed hosts
  http:
  - match:
      - authority:
          prefix: "<service>" # <--- use prefix for host matching

Closing because the issue is resolved.

Would you mind sharing your fully working example @arnecls? I did follow the steps above but somehow mine doesn't work. Not sure I'm missing something.

This was 3y ago ...
From what I remember the main issue is that envoy simply string-appends -shadow to whatever was set in the HTTP authority / host header instead of using a domain, which would have made things a lot easier.
AFAIR we just went with allowing all hosts on the target virtual service as soon as request mirroring is used.
But careful - if you go past an ingress gateway, this one must also accept all host, otherwise your request does not go past the ingress.


Exclude action .yml from pull requests

Hello!
Disclaimer: your action itself works great and this might be a layer 8 issue.
I'm contributing from time to time to a project on GitHub. So I forked it and set up your action to keep it updated. But when I create I pull request it will always include the configuration .yml which isn't needed in the original project. I've tried to add it to a branch but that prevents it from showing up in the GitHub actions.
Is there any other way besides removing the file each time before committing?

You could add the action in master and sync master2 and use this branch for your pull requests.

Sounds like a good idea. While trying to get this to work (Git isn't my strong suit) I found a "task failed successfully" error:
https://github.com/tryallthethings/pikvm/runs/1117472427?check_suite_focus=true#step:2:10

(node:2664) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'startsWith' of undefined
    at /home/runner/work/_actions/TG908/fork-sync/v1.2.0/lib/main.js:52:59
    at Generator.throw (<anonymous>)
    at rejected (/home/runner/work/_actions/TG908/fork-sync/v1.2.0/lib/main.js:25:65)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
(node:2664) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:2664) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Could you please let me know how to change my action to get your suggestion working?

Version 1.2.0 has some issues try using 1.2.1 or fall back to v1.1.

Thanks, changed it.
And in case anyone else wants to achieve the same, here's how I did it:

Forked the original repository
Created a new branch "sync"
Created a new action on the master branch with the following .yml

name: Fork Sync

on:
  schedule:
    - cron: '*/30 * * * *' # every 30 minutes
  workflow_dispatch: # on button click

jobs:
  sync:
    runs-on: ubuntu-latest

    steps:
      - uses<EMAIL_ADDRESS>        with:
          owner: source-repo-owner
          github_token: ${{ secrets.GITHUB_TOKEN }}
          head: master
          base: sync
          merge_method: merge
          pr_title: Fork Sync

Now all changes from the original repo should be automatically merged to my sync repo and I can raise PR without the configuration .yml


sickbeard_mp4_automater not sorting converted mp4's

Hello,
I got the script to work and convert mkv files to mp4 however the script doesn't seem to sort the mp4 files into the correct folders. I'm using the script with sonarr and radarr, when I have download handling disabled or enabled neither options sort the mp4 converted files into the right folder. What am I missing?

The script doesn't do any sorting that's a feature handled by sonarr/radarr
My guess is you haven't configured something correctly and the script isn't handing the files back to sonarr/radarr when its finished. Each downloader (NZBGet/SAB/Deluge etc) has its own script and needs to be configured to hand the file back to sonarr/radarr which will then move and rename it.
You can also just use completed download handling and not use the post download program scripts (NZBGet/SAB/Deluge etc) and just let sonarr/radarr handle everything but that does mean you need to set up postSonarr and postRadarr
Which configurations did you set up?

I am using SABnzbd as a downloader, and I used the configuration mentioned in the documentation for radarr setup and sonarr setup. Which of those scripts should I use if I'm using postRadarr.py and postSonarr.py now?

The simplest setup would be to use only those 2, postRadarr, postSonarr, no post script for SAB, and to leave completed download handling turned on


refactor: Support Capacitor 6

CapacitorJS v6.0 was released.

https://capacitorjs.com/docs/updating/plugins/6-0

Upgrade dfu library

有人么？


modelica_bridge: 0.1.1-0 in 'kinetic/distribution.yaml' [bloom]

Increasing version of package(s) in repository modelica_bridge to 0.1.1-0:

upstream repository: https://github.com/ModROS/modelica_bridge.git
release repository: https://github.com/ModROS/modelica_bridge-release.git
distro file: kinetic/distribution.yaml
bloom version: 0.6.6
previous version for package: 0.1.0-0

modelica_bridge
* Edited package description
* Updated documentation
* Edited README.md
* Edited documentation for modelica_bridge
* Edited <depend> tags in package.xml
* Added install target for modbridge node
* Edited documentation for modelica_bridge

Attempt to fix error found when checking the previous version in the shadow-fixed repository (didn't install executable)


[GHSA-8pfj-w89w-m24x] Add affected product org.apache.zeppelin:zeppel…

…in-shell 0.10.1 < 0.11.1
This information was in the CVE metadata at https://www.cve.org/CVERecord?id=CVE-2024-31861

Similar to the other PR I'm not sure I follow on package choice. Looking at the linked PR it seems like something in their build system is being changed.
https://github.com/apache/zeppelin/pull/4708/files
Could you explain how that change implicated the org.apache.zeppelin:zeppelin-shell artifact?

Similar to the other PR I'm not sure I follow on package choice. Looking at the linked PR it seems like something in their build system is being changed. https://github.com/apache/zeppelin/pull/4708/files Could you explain how that change implicated the org.apache.zeppelin:zeppelin-shell artifact?

Indeed the zeppelin-shell component itself was not changed, but it was disabled by default. Like with https://github.com/github/advisory-database/pull/4463, marking 'zeppelin as a whole' as affected would perhaps have been preferable, but failing a way to refer to that, 'any installation containing zeppelin-shell' seems like a reasonable proxy.

What does it mean that the shell component was disabled by default though? Forgive my ignorance with the project but would my thinking is that if I add org.apache.zeppelin:zeppelin-shell to my pom I still need to import and to use the code from the artifact in my particular project. That is to say opt-in behavior. Am I missing something there?

zeppelin-shell is an 'Interpreter' component for Zeppelin: you would typically not use it in your own project/pom, only with Zeppelin. Zeppelin detects available interpreters by scanning the 'interpreter' directory of the installation. 'disabled by default' here means zeppelin-shell no longer placed in the 'interpreter' directory during the default installation, so operators that want to use it (and have considered the risk of doing so) need to place it there explicitly.

Gotcha. Thanks for the clarification 👍


Engine GTK4 version is a pre-release

The GTK4 version in the Flutter build directory build/linux/debian_sid_arm64-sysroot/usr/lib/aarch64-linux-gnu/libgtk-4.so.0.9600.0 is a pre-release version. The soversion was changed from 0 to 1 when it was released. Building Flutter with GTK4 means it will fail to link against the system version of GTK4 (libgtk-4.so.1).

After some digging in the build system, the sysroot is downloaded on build and is built from debian stable as part of the Chromium project. Debian sid does contain a more recent version of libgtk-4-1, so it should be able to be included as part of the sysroot.

Looks like the current Chromium image uses a suitable version of GTK - so we can probably just update to a newer image.

I've updated the buildroot to use the same version as Chromium master in https://github.com/flutter/buildroot/pull/793, still working on how to test it.

Hmm, the Chromium master sysroot doesn't have a sufficiently new version of pango:
$ pkg-config --variable=prefix gtk4 --validate
Package dependency requirement 'pango >= 1.47.0' could not be satisfied.
Package 'pango' has version '1.46.2', required version is '>= 1.47.0'
Package dependency requirement 'pangocairo >= 1.47.0' could not be satisfied.
Package 'pangocairo' has version '1.46.2', required version is '>= 1.47.0'

as already reporting in https://bugs.chromium.org/p/chromium/issues/detail?id=1275173

I don't know how the sysroot installs packages, as debian/libpango-1.0-0/DEBIAN/control clearly depends on libpango-1.0-0 (>= 1.47.0) but debian/libpango-1.0-0/DEBIAN/control states the version is 1.46.2-3.

Hmm, and the version of pango is not from sid, which is would be 1.51.0+ds-3, but actually the version from bullseye.

cc: @cbracken

Summary of the current state of things. We'll need to file an infra ticket for this. It looks like the process to update the image involves sending patches to chromium and that we'd need to make sure we don't break the chromium build. First though I'd see if we're on the latest chromium sysroot, and if not upgrade.
If that proves to be problematic, we could consider forking their repo and using their tooling to build our own images; that may make more sense long term either way.


feat: add custom Angular variants

Based on the feedback of #18330 I created this Angular variant
Angular CLI & Analog.js

Having a single variant is a bit strange at first, but I think it is a good idea to keep the option even if there is a single choice. We would be sending the wrong message if we directly forward to Analog. It would be great if we could add an Angular option soon though.

I'll add it now

Nice! Recommendation would be to change Analog.js to just Analog.

Nice! Recommendation would be to change Analog.js to just Analog.

I'll do it right now


Close file if file type has changed after initial stat

What is the purpose of this change? What does it change?
Fix the archiver to close a file even when its file type changes between the lstat and stat call.
Was the change discussed in an issue or in the forum before?
The issue was discovered while taking a look at #2566
Checklist

[x] I have read the Contribution Guidelines
[x] I have added tests for all changes in this PR
[x] I have added documentation for the changes (in the manual)
[ ] There's a new file in changelog/unreleased/ that describes the changes for our users (template here)
[x] I have run gofmt on the code in all commits
[x] All commit messages are formatted in the same style as the other commits in the repo
[x] I'm done, this Pull Request is ready for review

I didn't add a changelog entry for now as I'm not sure whether that change really warrants a changelog entry. I couldn't find any bug complaining about that specific issue.

The test failure in this PR is fixed in https://github.com/restic/restic/pull/2575 and has landed on master.

The test failure in this PR is fixed in #2575 and has landed on master.

Thanks for fixing the test failure.


Uncaught Package not found fusebox-hot-reload

Importing a json file without JSONPlugin() produces this error message, which is hard to correlate to the actual problem. Would be great if error message were more descriptive so it is easier to introduce FuseBox to existing webpack-driven codebases.

Yep, that happens in you get a syntax error

So are you working to improve error handling or something? I tried running some of my webpack-driven codebases with fusebox and always got stuck with error and didn't have a clue how to fix it.

@dziamid as a temporary solution, u can disable HMR and test your app to see if there is any syntax error and then enable it. usually HMR works with errors as it would be reported to you in the browser, but sometimes, there are those severe errors that would prevent it from working, we should improve that :)

The solution is to clear the cache. (remove .fuse-box folder)

Feel free to re-open, if it didn't helpl

So the approved solution is for users to go nuts trying to figure out the nonsensical error, arrive at this issue, then realize the issue has nothing to do with fusebox-hot-reload.

@masaeedu are you still experiencing it?

@nchanged Yes. I fixed the missing import in my code that was causing the error, but I was still seeing the irrelevant fusebox-hot-reload error message yesterday.

@masaeedu but there should be 2 stack traces, one about the missing imports and the other one whenever fuse has failed to update.

Just wondering if has been improved since 2017?
In our project we were adding some code. At some point a '-' character was simply accidentally misplaced in code, effectively causing a syntax error. About an hour later the new code was being tried out for the first time, and we got this "Uncaught Package not found fusebox-hot-reload". Luckily it didn't take us too long to figure it out and fix the typo. But still, this is very annoying.

there is a new version 4.0.1 that doesn't have this issue


Test Python 3.7

Codecov Report

Merging #62 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master     #62   +/-   ##
======================================
  Coverage    92.1%   92.1%
======================================
  Files           3       3
  Lines         190     190
======================================
  Hits          175     175
  Misses         15      15

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 11a6d17...78b8ee7. Read the comment docs.

@eburgoswisc Any comments here? Otherwise I'll merge in. I followed guidance from here to get the testing working Python 3.7. I don't know much about Ubuntu Xenial but I confirmed on the Travis logs that the correct versions of Python were tested.

I think its good. Ubuntu Xenial (16.04) is the latest version with updated packaging modules. So I guess its the best to use for building on python 3.7 since this python version recently got released. Hopefully, all libraries and dependencies for pyinseq work with python 3.7 but Travis will let you know.

It passed 👍


Broken links (IPFS variant only)

Visit http://<IP_ADDRESS>:8080/ipns/ipfs.io/docs/examples/

Click on “IPFS for websites” in the list of examples
ipfs resolve -r /ipns/ipfs.io/ipfs/QmNZiPk974vDsPmQii3YbrMKfi12KTSNM7XMiYyiea4VYZ/example: no link named "ipfs" under QmPCawMTd7csXKf7QVr2B1QRDZxdPeWxtE4EpkDRYtJWty

Go back and click on “Blog” (in the top bar)
ipfs resolve -r /ipns/ipfs.io/blog: no link named "blog" under QmPCawMTd7csXKf7QVr2B1QRDZxdPeWxtE4EpkDRYtJWty

There two bugs at play here.
2) does not happen anymore, but looks like a clash between gateway and dnslink redirect. I fixed similar edge cases in https://github.com/ipfs-shipyard/ipfs-companion/pull/518, fix will land in next release.
3) the problem is that blog is is a separate static website and current URL structure does not translate to dnslinks used.
If user is visiting https://ipfs.io/blog/ and has dnslink lookup enabled in companion extension they get redirected to http://<IP_ADDRESS>:8080/ipns/ipfs.io/blog/ which at the moment is a directory with this gem: http://<IP_ADDRESS>:8080/ipns/ipfs.io/blog/index.json
A fix is to either:

change links on the website from https://ipfs.io/blog/ to  http://blog.ipfs.io
add latest blog tree to website's DAG when publishing to IPFS


fix: wills table de duplicate

This proposal is a companion fix to aedes to allow sending wills on startup.  Also, this addresses issue #102 with duplicate WILLKEY items.

Could you add a test that covers this?

My implementation was wrong for streaming wills, so I removed it, and only added the de-duplication tests.  I think this needs to be managed in aedes mostly, although its possible the persistence layer may need to be tweaked to allow a broker to pull only its own wills.

Changed to streamWill

lrem is the only decent way to test for item counts matching the key. I
don't think the API exposes that in any other way at present.
On Mon, Jul 25, 2022, 3:13 AM Daniel Lando @.***> wrote:

@.**** requested changes on this pull request.
In test.js
https://github.com/moscajs/aedes-persistence-redis/pull/104#discussion_r928539816
:

const packet = {
cmd: 'publish',
topic: 'hello',
payload: 'willsTest',
qos: 1,
retain: false,
brokerId: instance.broker.id,
brokerCounter: 42,
messageId: 123
}

instance.putWill(client, packet, err => {
instance.putWill(client, packet, err => {

 const key = `will:${instance.broker.id}:${encodeURIComponent(client.id)}`

 instance._db.lrem('will', 0, key, function (err, value) {

why are you manually calling lrem here on db? shouldn't that be done in
putWill ?
—
Reply to this email directly, view it on GitHub
https://github.com/moscajs/aedes-persistence-redis/pull/104#pullrequestreview-1048964130,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABKBETQ5RAL5KNLASHP3GJ3VVY5CXANCNFSM53YPQTIA
.
You are receiving this because you authored the thread.Message ID:
@.***>


[SMALLFIX]Use static imports for standard test

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/19313/
Test PASSed.


Imperial county, California

Part of "finish California" sprint.

Via (src):
Looks like good data, just need to get it.

Map viewer: https://www.geoviewer8.com/?username=icpublic&password=icpublic
County "GIS" page: http://www.co.imperial.ca.us/Assessor/

For further assistance and for questions or concerns about your property
assessment, please call:<PHONE_NUMBER>, The Assessor’s property tax
assessment information line or send an email at<EMAIL_ADDRESS>.

Old contact?
Laura Cervantes, Cadastral Map/GIS Supervisor
County Assessor Office
940 W. Main Street, Suite 115
El Centro, CA 92243
760.482.4247
<EMAIL_ADDRESS>

I've sent them an email.

From Justin's comment in https://github.com/openaddresses/openaddresses/issues/2515#issue-206580096...
emailed Imperial County -<EMAIL_ADDRESS>http://www.co.imperial.ca.us/Assessor/FIRelease.html
data here: http://services.geoviewer8.com/arcgis/rest/login?redirect=http%3A//services.geoviewer8.com/arcgis/rest/services/ImperialCounty_Public/MapServer/

@justinelliotmeyers How do we get a login token for that Esri server?

no idea! I just e-mailed them<EMAIL_ADDRESS>) and asked for data/ token.

we can buy, and incorporate into the project - they accept check/ CC
Sure, my direct line is listed here below:
(442) 265-1311
LAURA J CERVANTES, GISP
Cadastral Mapping / GIS Supervisor
Imperial County Assessor's Office
(442) 265-1311

I'll followup with her...

Email sent.
On Mon, Mar 6, 2017 at 2:51 PM, Justin Meyers<EMAIL_ADDRESS>wrote:

we can buy, and incorporate into the project - they accept check/ CC
Sure, my direct line is listed here below:
(442) 265-1311
LAURA J CERVANTES, GISP
Cadastral Mapping / GIS Supervisor
Imperial County Assessor's Office
(442) 265-1311
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/openaddresses/openaddresses/issues/2207#issuecomment-284560796,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA0EOwoZ76hX-a1FMiL09pMprEm6Cpksks5rjI4LgaJpZM4LGM-_
.

That’s the same weird / custom GIS portal as before (view only) :\
On Mon, Mar 6, 2017 at 3:08 PM, Justin Meyers<EMAIL_ADDRESS>wrote:

[image: screenshot_20170306-170653]
https://cloud.githubusercontent.com/assets/5324316/23634360/d411db3e-0297-11e7-811e-19046bab899d.png
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/openaddresses/openaddresses/issues/2207#issuecomment-284564608,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA0EO5V26F5iDpKohM_nAQqErKmCkfO7ks5rjJHWgaJpZM4LGM-_
.

My sister lives in this county, will be nice to get her on the map!
On Mon, Mar 6, 2017 at 3:13 PM, Nathaniel Kelso<EMAIL_ADDRESS>wrote:

That’s the same weird / custom GIS portal as before (view only) :\
On Mon, Mar 6, 2017 at 3:08 PM, Justin Meyers<EMAIL_ADDRESS>wrote:

[image: screenshot_20170306-170653]
https://cloud.githubusercontent.com/assets/5324316/23634360/d411db3e-0297-11e7-811e-19046bab899d.png
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/openaddresses/openaddresses/issues/2207#issuecomment-284564608,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA0EO5V26F5iDpKohM_nAQqErKmCkfO7ks5rjJHWgaJpZM4LGM-_
.

@nvkelso you know a lot of people in a lot of places amigo!!!

I think this is one of the last three! @nvkelso same source from previous two tonight!
https://gis2.cdfa.ca.gov/server/rest/services/Parcel_DM/MapServer/12

100% at long last!

On Dec 10, 2018, at 20:12, Justin Meyers<EMAIL_ADDRESS>wrote:
I think this is one of the last three! @nvkelso same source from previous two tonight!
https://gis2.cdfa.ca.gov/server/rest/services/Parcel_DM/MapServer/12
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

💯


Improve stability: processes separation

Currently waybar is not very stable for me. I have issues with waybar not starting or disappearing because of a crash. I believe this is mostly because a module has an error. The MPD module seems to not be very stable. Instead of requiring every module to never crash I would suggest to use a separate process for every module. When a module crashes waybar should not crash, but instead restart the module.

I have a similar experience and I agree. Playing with waybar to reproduce my polybar setup, I was testing my script to detect if I was connected to my VPN. For some reason, my MPD server is only reachable via my VPN network. And as soon as I disconnected my machine from my VPN to test my script, all of my bars froze and waybar finally crashed completely after the timeout of 30s.
Never had such problems with polybar. At worst the info displayed by the MPD module would just freeze, but the rest of the module were not affected. And I think it should be the desired behavior.