text:
Definition of lifetime parameters without needing to call an internal function.

The current implementation of user-defined parameters for rs_ and rb_ timescales is functional, but requires pre-processing by calling make_rb_function_from_arrays and make_rs_function_from_arrays in pub_utils import.  It would be desirable for some applications (eg parameter optimization) to allow the direct specification of vectors without precalculating the decay function.

@benmsanderson This issue is sort of split in a sense, in terms of the calibration it self, I think it needs a bit of special treatment anyways, because we save so much time from precalculating the decay values, so it's being done when the cscm object is being generated, so I need a little more time to think about how to integrate that in there. For just the direct calling of an internal function, I can always make that happen under the hood (or at least optionally have it happening there...) I guess the first part of the problem (which is less easy to solve) is your main concern, however, I would like to know whether you think it is also important to solve the second problem, which is much easier to solve, but maybe more of a user friendliness issue...

authors: benmsanderson maritsandstad

repo: ciceroOslo/ciceroscm


text:
WLED

WLED als 'Supported adapter' wäre auch cool :)

I've added WLED to supported adapters. Please make a test if it's working for u.

It works great !I Thanks !!

source: gharchive/issue

license: MIT

license_type: permissive

license_source: github-api


text:
V2->V1 bemap downgrade patch in 1.10

We need to implement some logic to downgrade from V2 backend map (introduced in PR #17235) to legacy V1 backend map. This logic needs to go into 1.10.

Fixed with above PR merged.

repo: cilium/cilium


text:
mTLS enablement, SPIRE server and agent installation

This issue covers figuring out how to handle enabling mTLS, and then installing the SPIRE server and per-node agents.
We'll need to ensure that we support both Helm and cilium-cli, and also that we ensure that you can't turn this on in cases where it will conflict with other features.

Current thoughts on this:
The semi-official SPIRE Helm charts will need a lot of modification for our use case - I think it's better to maintain our own chart based on their principles, because of how we are using the DelegatedIdentity API, our install will necessarily be different to the standard ones.
We also need to ensure that we're not stopping ourselves from being able to work with bring-your-own-SPIRE in the future (although that is not in scope for the initial release.)
I think we should do a two-pronged approach:

Firstly, we provide a chart that sets up everything we need, in the way we need it, and allow config of lots of details.
Secondly, we explain what we're doing differently to a standard SPIRE installation, and how the Cilium install must be configured to work like we expect. (Including expected identities etc.) Probably the biggest difference is that we don't need the SPIRE controller-manager to automatically create Service Account identities - we're having Cilium handle that instead. I don't think it will hurt to have the controller-manager running though.

Things that we can be pretty sure we need to have be configurable:

trust-domain: the domain part of the SPIFFE URL. Default: spiffe.cilium - it shouldn't be an actual domain by default.
socket paths: There are the agent and agent admin sockets. They should be bound into a host directory that's also shared with the Cilium Agent.

agent-socket: Default /run/spire/sockets/agent/agent.sock
admin-socket: Default /run/spire/sockets/admin.sock (The Admin socket can't be in a subdirectory of the Agent one.)

Default identities (Open question: should we allow configuring the selectors for these? Also, we could specify these using either pieces of the URL (just the path) or with a template that includes the trustdomain or something.):

spiffe://spiffe.cilium.io/ns/spire/sa/spire-agent: Node identity for the Spire agent, so it can parent other identities.
spiffe://spiffe.cilium.io/cilium-agent: Cilium Agent identity. This is plumbed into the SPIRE agent so that the Cilium Agent will have access to the admin socket (required for the DelegatedIdentity API). (Configured in the authorized_delegates field in the agent field of the SPIRE agent config file.)
spiffe://spiffe.cilium.io/cilium-operator: Cilium Operator identity. This is configured in the SPIRE server config file, so that the cilium-operator can create SPIRE entries across the network.(Configured in the admin_ids section inside the server section of the SPIRE server config file.)

SPIRE infra installation namespace.
SPIRE Server Service name inside the infra namespace.

Things that we expect but probably don't need to have configurable:

k8s_psat node attestor, using the spire:spire-agent service account for registering new nodes.
k8s workload attestor.
spire-agent daemonset neeeds a projected service account token added  as a volume.
We don't run the SPIRE controller-manager, the Cilium operator will do that instead.

For the Helm chart, I think we should move from the existing config:
auth:
  mTLS:
    # -- Enable mtls-spiffe authentication method in CiliumNetworkPolicy
    enabled: false
    # -- SPIRE socket path where the SPIRE delegated api agent is listening
    spireAdminSocketPath: /run/spire/sockets/admin.sock
    # -- SPIFFE trust domain to use for fetching certificates
    spiffeTrustDomain: spiffe.cilium.io
    # -- port on the agent which is used to mTLS handshakes on
    port: 4250

To this one:
auth:
  mTLS:
    # -- Enable mtls authentication method in CiliumNetworkPolicy
    enabled: true
    # -- port on the agent which is used to mTLS handshakes on
    port: 4250
    # Settings for SPIRE
    spire:
      # Settings to control the SPIRE installation subchart
      install:
        # Note that this will only take effect if auth.mTLS.enabled is true _and_ authType is spire
        enabled: false
        namespace: cilium-spire
      # -- SPIFFE trust domain to use for fetching certificates
      spiffeTrustDomain: spiffe.cilium.io
      # -- SPIRE socket path where the SPIRE delegated api agent is listening
      adminSocketPath: /run/spire/sockets/admin.sock
      # -- SPIRE socket path where the SPIRE workload agent is listening
      # Applies to both the Cilium Agent and Operator
      agentSocketPath: /run/spire/sockets/agent/agent.sock
      # Identity paths for the SPIFFE URLs, without prependended /
      # SPIFFE URLs will look like:
      # spiffe://trustdomain/identity
      identities:
        cilium-agent: "cilium-agent"
        cilium-operator: "cilium-operator"

Notable things here:

mTLS authentication will default to "on", so the fields in network policy will do something. This will let devs or users test that the datapath is working with the "always allow" and "always deny" auth methods.
mtls-spiffe won't work without a SPIRE install; setting auth.mTLS.spire.install.enabled: true will have Cilium install the SPIRE server for you.

We need to speak to other folks to decide if a subchart or just a directory of templates is the better option for the Cilium SPIRE install; the upstream chart is not usable without a lot of editing, we would be effectively maintaining our own chart anyway. My preference is probably for a subchart that is just stored within the Cilium chart folder, that allows some segmentation of this (pretty substantial) install away from the bits that are Cilium proper. However, Cilium has previously had subcharts and moved away from them, so we should check why that was and if the reasons for that change apply here and now (Helm 3 has changed a bunch of things).


text:
GatewayAPI feature in helm chart doesn't include CRDs

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
When I enable GatewayAPI via helm, I do not get the GatewayAPI CRDs that cillium supports.
Cilium Version
1.14.0
Kernel Version
Linux testify.fnal.gov 5.14.0-284.18.1.el9_2.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jun 29 17:06:27 EDT 2023 x86_64 x86_64 x86_64 GNU/Linux
Kubernetes Version
Kuberenetes 1.27.3
Sysdump
No response
Relevant log output
No response
Anything else?
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

👋 have you checked the below docs? It's a prerequisite to have related CRDs installed.
https://docs.cilium.io/en/stable/network/servicemesh/gateway-api/gateway-api/#prerequisites

Interesting, I'd expected the CRDs in the chart.  I'd say this can be closed out then.

authors: jcpunk sayboras


text:
Helm issue when setting kubeProxyReplacement=true - incompatible types for comparison

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
I'm trying to follow the guide to use cilium as a kube-proxy replacement (https://docs.cilium.io/en/stable/network/kubernetes/kubeproxy-free/#kubeproxy-free)
Running the helm upgrade command produces an error.
helm upgrade -i cilium cilium/cilium --version 1.15.0 \
    --namespace kube-system \
    --reuse-values
    --set kubeProxyReplacement=true \
    --set k8sServiceHost=${API_SERVER_IP} \
    --set k8sServicePort=${API_SERVER_PORT}

Error: UPGRADE FAILED: template: cilium/templates/cilium-agent/daemonset.yaml:678:48: executing "cilium/templates/cilium-agent/daemonset.yaml" at <ne $kubeProxyReplacement "strict">: error calling ne: incompatible types for comparison

Cilium Version
cilium-cli: v0.15.22 compiled with go1.21.6 on linux/amd64
cilium image (default): v1.15.0
cilium image (stable): v1.14.6
cilium image (running): 1.15.0
Kernel Version
6.1.74
Kubernetes Version
Server Version: version.Info{Major:"1", Minor:"29", GitVersion:"v1.29.1", GitCommit:"bc401b91f2782410b3fb3f9acf43a995c4de90d2", GitTreeState:"clean", BuildDate:"2024-01-17T15:41:12Z", GoVersion:"go1.21.6", Compiler:"gc", Platform:"linux/amd64"}
Sysdump
No response
Relevant log output
No response
Anything else?
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Which helm version you are using ? Helm v3.13 is recommended for cilium.
Alternatively, you can try with --set-string instead of set, or --set kubeProxyReplacement='true'.

Thank you for your reply. Indeed, it was the helm version. I used 3.8 locally...
After upgrading, it was working.

authors: heckelmann sayboras


text:
eBPF + L2Announce + without-kube-proxy + destination pods on separate k8s node from in-bound traffic = eventual guaranteed breaking

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
When I have my destination pods on a k8s node separate from the L2Announce leader k8s node, after a seemingly random period of time, those pods will eventually be 100% unreachable and not self-heal.
Cilium Version
v1.15.1
Kernel Version
5.15.0-112-generic #122-Ubuntu SMP
Kubernetes Version
v1.26.15+rke2r1
Regression
I don't know yet
Sysdump
NA
Relevant log output
I can't tell what log output actually is relevant, despite checking logs that align time-wise. Nothing seems consistent after multiple break iterations!

Anything else?
I am using:

Rancher
RKE2 for nodes
ArgoCD for greatness
Proxmox VE for running the VMs that are k8s nodes
Ubuntu 22.04 for the VMs

In the relevant test cluster I have 3x RKE2 nodes, and I'm using the RKE2 documented method to disable kube-proxy. Then in-turn have cilium do Layer 2 ARP broadcasting and LoadBalancing for a single LAN IP outside the cluster. I do not want to use BGP that is not okay in this environment.
In my test scenario, I have two relevant pods, NGINX Ingress, and librespeed. librespeed goes through NGINX Ingress, and NGINX Ingress has an 80/443 Service object.
The two pods are on the same node as each other, but a different node from the ARP IP broadcast node (leader).
Traffic comes in, I get correct Source IP, that's desirable.
However the following problems occur:

If the two pods get terminated and regenerate, then they are 100% unreachable, every time. This does not self-heal and requires all Cilium pods be terminated and re-init'd, and/or redeployed.
Eventually after a random period of time between 3 minutes and 1h 30min (ish) the NGINX Ingress Service (or something like that) will just suddenly stop getting traffic (I'm reloading the librespeed page once per minute to validate this). And this never self-heals, and requires all Cilium pods be terminated and re-init'd, and/or redeployed.

For Rancher's RKE2 stuff I have the following contents for the rke2-cilium-config.yaml file, and a daemonset that distributes this content (including updates) to all nodes in the cluster:
  rke2-cilium-config.yaml: |
    apiVersion: helm.cattle.io/v1
    kind: HelmChartConfig
    metadata:
      name: rke2-cilium
      namespace: kube-system
    spec:
      valuesContent: |-
        rollOutCiliumPods: true
        kubeProxyReplacement: true
        kubeProxyReplacementHealthzBindAddr: 0.0.0.0:10256
        k8sServiceHost: 127.0.0.1
        k8sServicePort: 6443
        k8sClientRateLimit:
          qps: 20
          burst: 30
        l2announcements:
          enabled: true
          leaseDuration: 5s
          leaseRenewDeadline: 3s
          leaseRetryPeriod: 200ms
        routingMode: tunnel
        tunnelProtocol: geneve
        loadBalancer:
          mode: dsr
          dsrDispatch: geneve
        socketLB:
          hostNamespaceOnly: true
        debug:
          enabled: true
          verbose: flow

Changes to this file triggers re-deploy for Cilium via Helm Chart, so these generally represent launch parameters for Cilium itself.
For the CiliumL2AnnouncementPolicy I only really have "loadBalancerIPs: true" defined as I have not seen any reason to enable anything else to improve this situation, and have been trying to limit my variables in this scenario.
I'm at my wit's end, I cannot find why this is failing, even after turning debug logging on (as you see).
I've followed both RKE2 and Cilium's documentation on getting this going, and I can't for the life of me tell what I'm doing wrong. Please help, I need this working and I truly cannot see why this is breaking.
Cilium Users Document

[X] Are you a user of Cilium? Please add yourself to the Users doc

Code of Conduct

[X] I agree to follow this project's Code of Conduct

To clarify when I say "the two pods get terminated and regenerate" I mean:

The NGINX Ingress and librespeed pods
They could regenerate on the same k8s node they were on previously, or any different k8s node, and the breakage happens regardless of whichever node they regenerate on.

I hope that the two failure scenarios are related by whatever the source of the problem is, but I really am stuck. Hopefully I can get some help with this soon :(

Still really not finding why this is breaking. Would love to get some help troubleshooting this.

Welp I guess back to trying other technologies instead...

Really not sure where to look for issues here.
Can you post output of cilium status from any cilium pod. Perhaps we can see something there

What's the output of iptables-save?
What's the output of ip a?
Are all nodes masters?
A couple of guesses on what's happening without any cilium config, or other information.

iptables rules remain in place after kube-proxy is disabled, so when pods move around, things break. (iptables-save | grep -v KUBE | iptables-restore would fix this, or rebooting nodes after disabling cilium.)

you have multiple interfaces and cilium isn't running on some interfaces. (I've seen this with a main bonded interface, and other dedicated metallb interfaces.)

Thanks for the attempts to help folks, but I've already moved on and just switched to Calico. I didn't have time to wait around trying to troubleshoot unreliable software that didn't log what the problem was (as a default action). Calico not only solves my instability problem, but also the SourceIP problem I originally aimed to solve. Wish I had better things to say, but this is the truth of what I experienced.

authors: BloodyIron alphabet5 volatilemolotov


text:
Unable to run container with latest cilium

$ docker run \
 --name 'cilium-consul'  -p 8500:8500 \
 -e CONSUL_LOCAL_CONFIG='{"skip_leave_on_interrupt": true, "disable_update_check": true}' \
 consul:0.8.3 agent -client=0.0.0.0 -server -bootstrap-expect 1
$ docker run -v /sys/fs/bpf:/sys/fs/bpf -v /var/run/cilium:/var/run/cilium -v /var/run/docker.sock:/var/run/docker.sock --cap-add NET_ADMIN --net host --privileged docker.io/cilium/cilium:latest cilium-agent --kvstore consul --kvstore-opt consul.address=127.0.0.1:8500 --debug

$ docker network create --ipv6 --subnet ::1/112 --ipam-driver cilium --driver cilium cilium
$ docker run -ti --net cilium  busybox sleep 3000
docker: Error response from daemon: failed to create endpoint upbeat_lamport on network cilium: NetworkDriver.CreateEndpoint: Error creating endpoint [PUT /endpoint/{id}][500] putEndpointIdFailed  Endpoint ID is already set to 48705

@aanm I hit level=error msg="Sending error" code=400 msg="Error creating endpoint [PUT /endpoint/{id}][400] putEndpointIdInvalid  endpoint ID cannot be 0" subsys=cilium-docker-driver but
I couldn't not reproduce it after cilium cleanup

@aanm Did you also update & restart cilium-docker? Master changed the endpoint ID allocation from the plugins to the agent so the plugins needs to be recompiled and reinstalled.

@tgraf that worked!

authors: aanm nirmoy tgraf


text:
Extraneous envoy warning log "Skipping unsupported runtime layer"

During a failure in PR #9491 I saw these cilium-agent logs complaining about some configuration of envoy:
$ grep -v -e "level=info" -e "level=debug" pod-kube-system-cilium-p92rc-cilium-agent.log

...
2019-11-01T18:53:11.529973203Z level=warning msg="[[external/envoy/source/common/runtime/runtime_impl.cc:497] Skipping unsupported runtime layer: name: \"base\"" subsys=envoy-runtime threadID=874
2019-11-01T18:53:11.529997743Z level=warning msg="static_layer {" subsys=envoy-runtime threadID=874
2019-11-01T18:53:11.530049857Z level=warning msg="}" subsys=envoy-runtime threadID=874

What do these logs mean? Is there actually a configuration problem or does this occur in normal operation? If so, should they result in warnings in the cilium-agent logs?
https://jenkins.cilium.io/job/Cilium-PR-Ginkgo-Tests-Validated/15708/testReport/junit/Suite-k8s-1/16/K8sFQDNTest_Restart_Cilium_validate_that_FQDN_is_still_working/
8a6b4fdc_K8sFQDNTest_Restart_Cilium_validate_that_FQDN_is_still_working.zip

@jrajahalme any updates on this? should we still keep it open?

authors: errordeveloper joestringer


text:
CI: Upgrade test on GKE

Please ensure your pull request adheres to the following guidelines:

[ ] For first time contributors, read Submitting a pull request
[ ] All code is covered by unit and/or runtime tests where feasible.
[ ] All commits contain a well written commit description including a title,
description and a Fixes: #XXX line if the commit addresses a particular
GitHub issue.
[ ] All commits are signed off. See the section Developer’s Certificate of Origin
[ ] Provide a title or release-note blurb suitable for the release notes.
[ ] Thanks for contributing!

Fixes: #issue-number
<!-- Enter the release note text here if needed or remove this section! -->

This change is

test-gke K8sUpdates*

Coverage decreased (-0.04%) to 45.651% when pulling 0201d63615729c56dc3e9076cea8ab228afcfd5a on raybejjani:gke-upgrade-test into 19c3f5a12043d78d3154eabfb4c990428fab5d04 on cilium:master.

test-gke K8sDemosTest*

test-gke K8s*

test-gke K8s*

test-gke K8s*

test-gke K8s*

test-gke K8s*

test-me-please

test-me-please

test-gke K8s*

test-gke K8sUpdates*

test-focus K8sUpdates*

test-gke K8sUpdates*

test-focus K8sUpdates*

test-gke K8sUpdates*

test-focus K8sUpdates*

test-gke K8sUpdates*

test-focus K8sUpdates*

test-gke K8sUpdates*

test-focus K8sUpdates*

test-gke K8s*

test-me-please

test-gke K8s*

test-me-please

test-gke K8s*

test-gke K8s*

test-me-please

test-nightly

test-focus (K8sDemosTest)|(K8sUpdates).*

test-gke (K8sDemosTest)|(K8sUpdates).*

test-gke K8s(DemosTest)|(Updates).*

test-gke K8s(DemosTest)|(Updates).*

test-gke K8s(DemosTest)|(Updates).*

test-gke K8s(DemosTest)|(Updates).*

test-nightly

test-gke K8s.*

test-gke K8s(DemosTest)|(Updates).*

test-focus NightlyExamples Upgrade.*

test-focus K8s(DemosTest)|(Updates).*

test-gke K8s(DemosTest)|(Updates).*

test-focus K8s(DemosTest)|(Updates).*

test-gke K8s.*

test-me-please

test-gke K8s.*

test-nightly

test-gke K8s(DemosTest)|(Updates).*

test-focus K8s(DemosTest)|(Updates).*

test-gke K8s(DemosTest)|(Updates).*

test-focus K8s(DemosTest)|(Updates).*

test-gke K8s(DemosTest)|(Updates).*

test-focus K8s(DemosTest)|(Updates).*

test-gke K8s(DemosTest)|(Updates).*

test-focus K8s(DemosTest)|(Updates).*

never tell me the odds

never-tell-me-the-odds

test-gke

never-tell-me-the-odds

test-gke

test-focus K8s(Demos|FQDN).*

test-focus K8s(Demos|FQDN).*

test-gke K8s(Demos|FQDN).*

test-focus K8s(Demos|FQDN).*

test-gke K8s(Demos|FQDN).*

test-me-please

test-focus K8s(Demos|FQDN).*

test-gke K8s(Demos|FQDN).*

test-me-please

test-k8s

test-gke

test-focus K8sDatapathConfig.*

test-gke

test-gke K8sBasic Test Policy.*

test-gke K8sPolicyTest Basic Test

test-gke K8sPolicyTest Basic Test.*

test-gke K8sPolicyTest Basic Test.*

test-gke

test-me-please

test-me-please

test-me-please

test-me-please

test-gke

test-me-please

test-gke

test-me-please

test-me-please

test-gke

test-me-please

test-gke

test-focuse K8s(Updates)|(FQDNTest)|(ServicesTest).*

test-gke K8s(Updates)|(FQDNTest)|(ServicesTest).*

test-focus K8s(Updates)|(FQDNTest)|(ServicesTest).*

test-gke K8s(Updates)|(FQDNTest)|(ServicesTest).*

test-focus K8s(Updates)|(FQDNTest)|(ServicesTest).*

test-gke K8s(Updates)|(FQDNTest)|(ServicesTest).*

test-focus K8s(Updates)|(FQDNTest)|(ServicesTest).*

test-gke K8s(Updates)|(FQDNTest)|(ServicesTest).*

test-focus K8s(Updates)|(FQDNTest)|(ServicesTest).*

test-gke K8s(Updates)|(FQDNTest)|(ServicesTest).*

test-gke K8s(Updates)|(FQDNTest)|(ServicesTest).*

test-me-please

test-gke

Let's ship it.

source: gharchive/pull-request

authors: coveralls nebril raybejjani


text:
v1.6 backports 2020-10-07

#13357 -- contrib: Improve start-release.sh script (@joestringer)
#13408 -- contexthelpers: Fix deadlock when nobody recvs on success channel (@brb)

Once this PR is merged, you can update the PR labels via:
$ for pr in 13357 13408; do contrib/backporting/set-labels.py $pr done 1.6; done

test-backport-1.6


text:
v1.10: Update Go to 1.16.6

test-me-please

test-backport-1.10

I'll merge this one and check if CI continues to fail in https://github.com/cilium/cilium/pull/16829
for future reference the tests that have failed were https://jenkins.cilium.io/job/Cilium-PR-K8s-1.16-net-next/1095/ and https://jenkins.cilium.io/job/Cilium-PR-K8s-1.21-kernel-4.9/1076/

authors: aanm tklauser


text:
clustermesh: add initial support for MCS-API

Please ensure your pull request adheres to the following guidelines:

[ ] For first time contributors, read Submitting a pull request
[x] All code is covered by unit and/or runtime tests where feasible.
[x] All commits contain a well written commit description including a title,
description and a Fixes: #XXX line if the commit addresses a particular
GitHub issue.
[ ] If your commit description contains a Fixes: <commit-id> tag, then
please add the commit author[s] as reviewer[s] to this issue.
[x] All commits are signed off. See the section Developer’s Certificate of Origin
[x] Provide a title or release-note blurb suitable for the release notes.
[ ] Are you a user of Cilium? Please add yourself to the Users doc
[x] Thanks for contributing!

This adds initial support for MCS API (ServiceImport/Export) for Cilium clustermesh. It adds the controller to deals with ServiceImport/Export and create a derived services with the right Cilium clustermesh annotation so that the underlying service is correctly shared.
However this is not fully compliant with the MCS-API KEP as it does not handle automatic creation of ServiceImport yet. This is a first step that is not intended to be fully utilized by actual users yet.
Future work should include automatic creation of ServiceImport (that would be tied to the endpointslicesync package as the mcsapi support is running in the operator) and an associated documentation explaining how to get started with MCS API in Cilium when this would be in a more complete shape.
Related to #27902
Add initial support for Multi-Cluster Services API in Cilium clustermesh

FYI as also stated in the PR/commit description this more a first step toward the goal of supporting MCS API and not used by actual users yet, that's why I would like to not provide documentation in this PR yet and that's more something that I would like to do in in the last PR that would mark this as "usable and/or complete".
Although if you feel that it needs documentation at this stage feel free to say so, so that I can start doing it!

/test

/test

/test

/test

/ci-awscni

/ci-ginkgo

/ci-ginkgo


text:
golint: reduce comment warnings

Fixes all the warnings with the following pattern
... comment on exported function xYZ should be of the form "xYZ ..."
Related-to: #153 (Resolve golint warnings)
Please let me know if anything should be reworded, thanks.

This pull request is now managed with CodeReviewHub. Refresh.

authors: aanm scanf


text:
envoy: Use envoy image with Istio v1.1 support.

Update cilium/proxy dependencies to Envoy with Istio v1.1.1 filters.
This is a required prerequisite to test a new Envoy image before important bug fixes are available.
Go deps for cilium/envoy generated protobufs are updated to the same
SHA as cilium-envoy, which also requires bumping go protobuf
dependency to v1.3.
Istio sidecar proxy image has not been updated yet, and the Istio GSG still refers to Istio v1.0.2. Work to update those to Istio 1.1 is to be done later.
TODO:

[ ] Merge cilium/proxy branch pr/istio-v1.1.0 into master this PR passes CI, and before this PR is merged!

Signed-off-by: Jarno Rajahalme jarno@covalent.io
Fixes: #7463

This change is

test-me-please

test-flannel

Coverage decreased (-0.02%) to 42.716% when pulling 60748df3b756b7dfdc0df9d89a67147452822ae4 on pr/proxy-use-istio-1.1 into 763329d51a4c0d04a52eeb765dea692bc1de5312 on master.

test-flannel

test-me-please

test-me-please

Tests passed, would love to have this so we can announce Istio 1.1 support in 1.5

@tgraf Additional work is still needed on creating the Istio images and making sure the GSG works, but yes, this is the first step to that direction we need to take.

I'll update this once more Envoy fixes land in.

#7602 superceded this and is already merged. Took a bit simpler approach with that, skipping the Go API changes as the protobufs are still compatible. Will refresh this later, but this is no longer a release blocker.

Superseded by Istio 1.1.2 work.

authors: aanm coveralls ianvernon jrajahalme tgraf


text:
Add CFP-30788 Managing Hubble Metrics cardinality

This proposal aims at adding a new dynamic mechanism to manage Hubble metric cardinality.

Overall idea makes sense to me. We've got a few people on the hubble team who are on holiday this week; so hopefully next week they can take a look and we can move forward.

@kaworu: @chancez While I agree conceptually, disabled: false is difficult to read and would be inconsistent with the Hubble flow exporter.

Fair enough, so then should we just remove the option from the dynamic metrics config entirely? Then to disable a given metric option it just needs to not be configure in the list all? Eg to have the feature enabled, but no metrics configured:
       hubbleMetrics:
            metrics: [] # no metrics enabled currently.

That sounds reasonable, check for the presence of this new configmap and/or the lenght of metrics to determine if the feature is enabled. Removing the enabled/disabled section from CFP.

@kaworu  Thank you for the review,

Did you consider a CRD instead of a ConfigMap to configure metrics? The question was discussed for the Hubble exporter, and I feel like an explanation of why the CFP propose one or the other (or something else) would make sense in the "Implementation Alternatives" section.

Ack, i want building on the previous precedence of config maps, but open to discussion on this. I believe configmaps are better solution compared to CRDs as lined out in @chancez 's comment. Added my views to alternatives section.

It's unclear to me whether the CFP plan to deprecate/remove the cilium's config hubble-metrics. IMO we don't want to maintain the two long-term, and thus we're missing a migration path (or at least suggestion) from the current hubble-metrics mechanism to the proposed hubble-metrics-config mechanism in the "Impacts / Key Questions". Are we going to ship / document hubble-metrics-config for the existing dashboards?

That is a great point, we should deprecate the older path, but i am not familiar about the deprecation policy/process of cilium? If there are any pointers on how this is normally handled, i am happy to add it to "Future Milestones". My assumption is that it will take atleast one or two minor version upgrades for existing behavior get deprecated. I.e. if this support lands in 1.16 cilium, by 1.18 existing configuration via cilium-config will be deprecated?

This is a fair assumption, I think a couple of version should be enough to validate the configMap approach and implementation, and at that point we could start on deprecating the cilium-config metrics configuration.

thank for the review, I added the same at the bottom of the proposal stating, we will re-visit deprecation in 2 versions' time.

Last thing before merging, can you create and put this in a /hubble folder rather than the /cilium folder?

Good idea. @xmulligan @vakalapa once it's moved I'll merge the CFP.

Done, moved CFP to hubble folder. @chancez

Heads up that I moved this under cilium/ to match the documented process: https://github.com/cilium/design-cfps/pull/35 .

Ah @xmulligan I didn't see your request there. If we're going to split PRs up like that, then it'll make sense to update the README.md to describe exactly how we expect developers to make those decisions so we can consistently apply the rule :)

ahh you are right sorry about that. I guess I expected the issue to be in the Hubble repo. Thanks for changing

authors: chancez joestringer vakalapa xmulligan

repo: cilium/design-cfps


text:
Fix image creation for Tesla firmware 2019.5.x

As of firmware 2019.5.x, Tesla expects a partitioned device for storing
dashcam recordings. While this is not required for the music drive, this
change modifies both camera and music images to use a partition table
with a single primary partition formatted as FAT32, instead of formatting
the entire device/file..

@cimryan - can you please review this pull request?

I pointed the setup config to @therealmarcone's branch and tested this out as well as manually adding his changes from PR https://github.com/cimryan/teslausb/pull/126.  Worked well for me. Model 3 on 2019.5.15.

This PR does get filesystems that work on newer firmware, however it breaks the fsck /mnt/cam, which needs to be fsck /dev/loop0 style which means that as soon as the filesystem is powered off abruptly, which Tesla likes to do with USB ports, it never recovers.  Testing now with the /dev/loop0 /dev/loop1 fsck.

Why does it break the fsck? Since the filesystem is mounted on /mnt/cam with the correct offset, "fsck /mnt/cam" should just work, no? (not near a pi right now, can't check)

fsck from util-linux 2.29.2
fsck.fat 4.1 (2017-01-24)
Logical sector size is zero.
I'd assume that this is because of the partitioning.  fsck /dev/loop0 works fine.  I've modified my archiveloop to use /dev/loop for now, but there should be a way to get the /dev/loop address from the mountpoint in order to avoid hardcoding.
Incidentally, this may be the solution to the reports of filesystems becoming randomly inaccessible over time.  I was seeing the cam icon and music drive vanishing randomly during the day and tracked it down to the fsck failure.  I also rsync my music from a music archive when the clips are copied, so my install is already a bit custom.

Added a change that looks up the loopback used for the mountpoint being checked, then runs fsck on that instead.

authors: AngusThermo-Pyle atbaron rtanaka therealmarcone

repo: cimryan/teslausb


text:
⚠ St. Lawrence Global Observatory CKAN has degraded performance

In c9fa71a, St. Lawrence Global Observatory CKAN (https://catalogue.ogsl.ca/en/) experienced degraded performance:

HTTP code: 200
Response time: 6424 ms

Resolved: St. Lawrence Global Observatory CKAN performance has improved in d27d2f1 after 6 minutes.

repo: cioos-siooc/cwatch-upptime


text:
Update sbt to 1.10.4

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

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-sbt", artifactId = "sbt" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scala-sbt", artifactId = "sbt" }
}]

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

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 0.00%. Comparing base (64c8312) to head (e6b938c).
Report is 1 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@          Coverage Diff          @@
##            main    #380   +/-   ##
=====================================
  Coverage   0.00%   0.00%
=====================================
  Files          1       1
  Lines         16      16
  Branches       1       1
=====================================
  Misses        16      16

Flag
Coverage Δ

2.13.14
0.00% <ø> (ø)

temurin@11
0.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

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

authors: codecov-commenter scala-steward

repo: circe/circe-generic-extras


text:
Add Defer instances for Decoder and Encoder

Implements #2122

Could we add some documentation as well to the docs for this?  You could easily transform what you have in the accommodating issue and it would be great for discoverability of this.

@morgen-peschke Thanks for adding the tests.  It looks like this build failed MIMA for some reason, do you mind taking a look?

failure is genuine: https://github.com/circe/circe/actions/runs/9078292566/job/24945019131?pr=2123#step:13:2785

authors: hamnis morgen-peschke zarthross zmccoy

repo: circe/circe

license_source: bigquery


text:
feature request: Analyze without exporting

Could you please add feature to only analyze and play the video, without exporting the data ?

Yea, this on the roadmap for the v2.

Woud love to see this!

authors: Gargaj T0biasCZe cirquit

repo: cirquit/trdrop

license: mit


text:
Red Band values issue.

I downloaded,  B4 bands from arn:aws:s3:::sentinel-cogs (https://registry.opendata.aws/sentinel-2-l2a-cogs/)  and  arn:aws:s3:::sentinel-s2-l2a (https://registry.opendata.aws/sentinel-2/)
I've found significant differences between them, but they should be the same, isn´t it?
aws s3 cp s3://sentinel-cogs/sentinel-s2-l2a-cogs/20/H/NG/2022/3/S2A_20HNG_20220302_0_L2A/B04.tif C:\folder

aws s3 cp s3://sentinel-s2-l2a/tiles/20/H/NG/2022/3/2/0/R10m/B04.jp2 C:\folder

The difference is exactly 1000

Hello @Fernigithub ,
Yes, this is due to a change that was made in the Sentinel processing baseline as of January 25th.  See:
https://sentinels.copernicus.eu/web/sentinel/technical-guides/sentinel-2-msi/processing-baseline
Also, the specific note on the changes with the 04.00 changes:
https://sentinels.copernicus.eu/web/sentinel/-/copernicus-sentinel-2-major-products-upgrade-upcoming
In short, there is an offset now applied to data since Jan 25th in order to keep them comparable with data before this date.
The data in the original sentinel-2 dataset (from which the COGs are derived) do not have the offset applied, as described here:
https://forum.sentinel-hub.com/t/sentinel-2-processing-baseline-changes-and-harmonizevalues/4635
Note if you use the original sentinel-2 dataset you should not be creating time series from data crossing this date without applying the offsets.
We are working on a blog post that will be describing these changes and what we've done to update the COG data, so stay tuned for that.

Great!, thanks for your response @matthewhanson!
Hugs!

Closing, since the question was answered.

authors: Fernigithub TaiWilkin matthewhanson

repo: cirrus-geo/cirrus-earth-search


text:
Add links to setting up service principal to the ScubaGear Functional Testing Automation instructions document

Scope
There is a markdown document in the /Testing folder that details how to execute the functional test orchestrator as a user. The document is named "ScubaGear Functional Testing Automation". The scope of this issue is to add the links below to that document for easy reference. The links below are documentation issues that I had created which describe how to setup the service principal used by the automated functional test orchestrator in GitHub and by ScubaGear developers. Those links also describe how to setup the respective conditional access policies that are necessary when running the functional test orchestrator against the Entra Id baseline.

#589
#591

Justification
The reason this is helpful is because these issues are closed and we need to refer back to them every so often when fixing configurations in the tenant or setting up a new testing configuration and this will make it much easier to find them instead of having to search the old closed issues list.
Implementation

[ ] Create a new section in the testing instructions document (this section is for sys admins). Call it Functional Testing Infrastructure Setup or something like that. Add the links above

I received internal feedback from the dev team with a recommendation on how to implement this. I think this is a good approach. Their feedback is included below for reference. If there are any questions please contact @james-garriss for context and further recommendations.

Create a new subfolder under Testing called docs.

Create Markdown files in there with the documentation from the two hyperlinks in the Scope section above. This is basically converting the information from GitHub issues to markdown files.

Create a new section in the /Testing/Readme.md file named Setup Documentation for Sys Admins

Add hyperlinks and a quick description of the two new markdown files into the new Setup Documentation for Sys Admins section.

repo: cisagov/ScubaGear


text:
Formal internal review of Power Platform baseline

This PR is designed to facilitate a formal review of the revised Power Platform baseline from CISA SCuBA principals and the Scuba development team. Following this review the baseline should be in a state for sending to the CISA agency formal review process.
💭 Motivation and context
A broad review by both the development team SMEs and the CISA SCuBA principals ensures a high quality update in line with agency goals and consistent policy format and styling.
✅ Pre-approval checklist

[x] This PR has an informative and human-readable title.
[x] Changes are limited to a single goal - eschew scope creep!
[x] All future TODOs are captured in issues, which are referenced
in code comments.
[x] All relevant type-of-change labels have been added.
[ ] All relevant repo and/or project documentation has been updated
to reflect the changes in this PR.
[ ] All new and existing markdown check tests pass.

✅ Pre-merge checklist

[ ] Resolve conflicts with base branch via rebase.

✅ Post-merge checklist

[ ] Ensure Power Platform related markdown tests pass on merged branch

@ahuynhMITRE @nanda-katikaneni Via discussion triggered by the Teams baseline my recollection is that we agreed to remove admin center links from the baselines for now?
This PP baseline, in the instructions section, contains a link to a Microsoft page that has a list of all the different admin center links. The AAD and Sharepoint / OneDrive baseline do not contain a link to this type of page - not sure about the other baselines. Are we expecting all baselines to follow the approach of PP (i.e. link to an MS page with all the admin center links)?

Policy Group 1 - Creation of Power Platform Environments

Recommend to replace the the language in the group intro. Recommendation below:

By default, any user in the Azure AD Tenant can create additional environments. Enabling this control will restrict the creation of new environments to users with the following admin roles: Global admins, Dynamics 365 admins, and Power Platform admins.
change to:
By default, any user in the Azure AD Tenant can create new environments. The policies in this section restrict the creation of new environments to users with specific administrative privileges.

In both Rationales, replace "additional Power Platform environments" with "new Power Platform environments". Notice I made the same change in my recommendation above. This is to be consistent with Microsoft's language on their PP page and be more clear about what we are referring to.
In the Resources, there is a link named "Environment Administrator" to Digital Transformation Agency of Australia. It is not clear why that link is named that way because when you follow the link it takes you to a part of the web page labelled as "Power Platform".

MS.POWERPLATFORM.2.3v1
How did we come up with the bulleted list of "allowed" apps? Are those somehow deemed as inherently safe in the default environment? I recommend adding the answer to this question to the Rationale.

MS.POWERPLATFORM.2.1v1 instructions
The instructions for this policy are very confusing.

Recommend that you walk through each of the instruction steps and try to think like someone not familiar with the policies in this baseline. I provided some specific steps that confused me in the bullets below, but you may identify more items that can be tightened up. An alternative idea is to give the baseline to someone else on the project and ask them to read the baseline policy and try to follow the steps in the Admin center like I did.
step 5 - "At the Prebuilt connectors section, select the connectors that fit the agency’s needs." It is not clear what is meant by that fit the agency's needs. Needs for what?
step 6 - "Select a connector and click Move to Business." Not clear why a connector is being selected. Maybe say "select the connectors that are for sensitive data and then click Move to Business"
step 7 - It instructs the user to change the connector permissions. What do you want the user to change them to and why?
step 8 - Table 1 is referenced but I could not locate such table in the document.
step 8 - Instructions confusing.
step 9 - "For the default environment, move all connectors that cannot be blocked to the Blocked category." If a connector cannot be blocked, how can it be moved to the Blocked category?
step 11 - Instructions confusing.
steps 12, 13 and 14 - This policy is specifically about the "default" environment but the instructions read like it may be for other environments. I recommend changing those instructions to be more precise.

Recommendation to combine policies due to potential redundancy
Policy MS.POWERPLATFORM.2.3v1 "All connectors except those listed below SHOULD be added to the Blocked category in the default environment policy" does not seem like it should be its own policy. It seems more like an implementation detail of policy MS.POWERPLATFORM.2.1v1 which basically says you must restrict the default environment.
Unless there is a strong reason to have these separate, I would consider combining them.

MS.POWERPLATFORM.2.2v1 consider clarifying policy
This policy states that non-default environments should have at least one DLP policy that affects them. This is more of a nit pick but to me, this reads almost like we are expecting a user to create a custom policy for each non-default environment, but that might not be necessary because a policy can be created that applies to "all" environments.
I would think the configuration below is compliant with our baseline policy.

Recommendation to combine tenant isolation policies
Recommend to create a single policy that includes both MS.POWERPLATFORM.3.1v1 and MS.POWERPLATFORM.3.2v1 since they are both really part of the same policy with 3.2 provided more implementation detail. We have combined policies such as this in the other baselines. See AAD and Sharepoint / OneDrive examples below.

Updated section one to update the group intro and rationales. Also updated resource link to  be named "Power Platform".

Recommendation to combine policies due to potential redundancy
Policy MS.POWERPLATFORM.2.3v1 "All connectors except those listed below SHOULD be added to the Blocked category in the default environment policy" does not seem like it should be its own policy. It seems more like an implementation detail of policy MS.POWERPLATFORM.2.1v1 which basically says you must restrict the default environment.
Unless there is a strong reason to have these separate, I would consider combining them.

I would take this recommendation further and remove the policy as a whole since the connectors listed cannot be added to the blocked category by design. I will however add a note to 2.1v1 noting these so the information is not lost.

MS.POWERPLATFORM.2.1v1 instructions
The instructions for this policy are very confusing.

Recommend that you walk through each of the instruction steps and try to think like someone not familiar with the policies in this baseline. I provided some specific steps that confused me in the bullets below, but you may identify more items that can be tightened up. An alternative idea is to give the baseline to someone else on the project and ask them to read the baseline policy and try to follow the steps in the Admin center like I did.
step 5 - "At the Prebuilt connectors section, select the connectors that fit the agency’s needs." It is not clear what is meant by that fit the agency's needs. Needs for what?
step 6 - "Select a connector and click Move to Business." Not clear why a connector is being selected. Maybe say "select the connectors that are for sensitive data and then click Move to Business"
step 7 - It instructs the user to change the connector permissions. What do you want the user to change them to and why?
step 8 - Table 1 is referenced but I could not locate such table in the document.
step 8 - Instructions confusing.
step 9 - "For the default environment, move all connectors that cannot be blocked to the Blocked category." If a connector cannot be blocked, how can it be moved to the Blocked category?
step 11 - Instructions confusing.
steps 12, 13 and 14 - This policy is specifically about the "default" environment but the instructions read like it may be for other environments. I recommend changing those instructions to be more precise.

updated instructions to better with intent and added more context based on comments.

MS.POWERPLATFORM.2.2v1 consider clarifying policy
This policy states that non-default environments should have at least one DLP policy that affects them. This is more of a nit pick but to me, this reads almost like we are expecting a user to create a custom policy for each non-default environment, but that might not be necessary because a policy can be created that applies to "all" environments.
I would think the configuration below is compliant with our baseline policy.

agree and will add a line in the instructions for the apply to all environments as a compliant option.

Spoke with Ted and my stance is to not combine the two because because one is a SHALL and one is a SHOULD and also if an agency wants all tenants are restricted they would then only need to turn the setting on in 3.1v1 and don't need to see any inbound and outbound allow lists

@nanda-katikaneni this PR is good to go for merge into emerald!

authors: ahuynhMITRE schrolla tkol2022


text:
Changes to Google Chat Baseline to Address the New Moderation Feature in GWS

Based on a Google Product update for the new moderation feature, the following changes need to be made to the Google Chat baseline:

GWS.CHAT.1.1v0.1 needs to be changed to SHALLm instead of SHOULD
A new policy group needs to be added to address content reporting:

GWS.CHAT.7.1v0.1 "Chat Content Reporting SHALL be Enabled"
GWS.CHAT.7.2v0.1 "All Conversation Types SHALL be Selected"
GWS.CHAT.7.30.1 "Spam, Confidential Information, and Sensitive Information SHALL be Selected"
Add a note under GWS.CHAT.7.3v0.1 stating that the other reporting categories can be implemented depending on agency needs.

The changes in this issue have been made and is now in review for the PR created.

repo: cisagov/ScubaGoggles


text:
Add usgov environment to Connect-AzureAD

Just looking quickly on the mobile site and it looks like there isn't an option for setting the 'Connect-AzureAD -AzureEnvironmentName AzureUSGovernment' option. Otherwise looks great and will check it out!

https://github.com/cisagov/Sparrow/pull/2 I've started that

repo: cisagov/Sparrow


text:
Pull logging setup out into a new cyhy-logging repository

Move the logging setup code out of this repo and into a cyhy-logging repo so that it can be used by other parts of the system.
For example, cyhy-keysync-lambda has a need to setup logging earlier and doesn't have a great way to do that yet.  It is currently relying on cyhy-kevsync to for setup.
https://github.com/cisagov/cyhy-kevsync/blob/886f778d4f918f12d2e3361b36be7ebb0941e9c1/src/cyhy_kevsync/main.py#L25-L57
https://github.com/cisagov/cyhy-kevsync/blob/886f778d4f918f12d2e3361b36be7ebb0941e9c1/src/cyhy_kevsync/log_filters.py#L1-L80
See also:

https://pymongo.readthedocs.io/en/stable/examples/logging.html

This has been completed:

https://github.com/cisagov/cyhy-logging/pull/1

repo: cisagov/cyhy-kevsync


text:
setup-env: A tool to automate a development environment setup.

🗣 Description
Adds the setup-env tool to the root of the repository.
This script automates the entire development environment setup process. 🎉
💭 Motivation and Context
This one is for all the Devs!
This automates the steps that are required to get a repo's dev environment up.   See: --help
Additionally it allows the recreation of an environment if it gets polluted, see --force flag.
Even more additionally it will configure the git remotes based on the lineage.yml file!  👏
🧪 Testing

I've been using various versions of this for a while.
There is no way this can fail! 🤦
📷 Screenshots (if appropriate)
🚥 Types of Changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (causes existing functionality to change)

✅ Checklist

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.
[x] Embeds a Python program in a bash script.

While we're here... I'm open to other name suggestions for the tool.  setup-env seemed apt.

RELEASING THE KRAKEN!  🦑

repo: cisagov/skeleton-generic


text:
Adding blacklist support.

Naïve support for alerting on any element referencing a domain name or
IP in one of the blacklist files stored in
malspider_django/blacklists/*.blacklist

Awesome! Thank you for this contribution!

repo: ciscocsirt/malspider


text:
delete nested element: Validation data not found: items,0,type

Description
When removing elements from a nested data field, I get the following error:
Error: Validation data not found: items,0,type

If applicable, a MRE
Use this stackblitz template to create a minimal reproducible example that you can link to here:
https://stackblitz.com/edit/sveltekit-superforms-testing-l35dv1?file=src/routes/+page.svelte
To repro, click the "add link" button a couple of times, then press one of the "-" buttons.

This should hopefully be fixed now with v0.8.3. Please check it out!

This seems to work now. Thanks a lot for your very rapid response!

Great, the whole client-side validation was a bit of a hassle, but I hope it will be stable from now on!

authors: ciscoheat rburgst

repo: ciscoheat/sveltekit-superforms


text:
Mapping of CSL container-title from CFF

@sdruskat @hainesr I am probably missing something obvious, but how do you describe in CFF what can be mapped to container-title in CSL? For DataCite DOIs describing software we use the repository name (e.g. Zenodo), but it could also be GitHub.  I don't see anything in the examples.
In Codemeta and DataCite XML we map publisher to container-title, but in CFF I see publisher only under references.
And also consider that for dataset the repository name, or GitHub would be the expected behaviour.

Thanks @mfenner for the issue, and @hainesr for transferring it here.
You're not missing anything, Martin, this simply isn't a field we have in CFF right now, but I think that we should think about it for the next minor version, as this is something that people will probably want to include in their reference strings (in place of "publisher", e.g., in BibTeX). Should also consider that this may not actually be something that is needed outside of BibTeX hacks to fit software citation?
I have very little bandwidth right now, so this will likely sit without much attention until early 2023.

Just came across this issue and also in support of being able to set at container title / publisher. For example, here is a citation derived from a CITATION.cff file (which is produced by Manubot relying on Zotero translation-server to convert the CITATION.cff to CSL):

greenelab/connectivity-search-analyses repository: Hetnet connectivity search research notebooks
Daniel Himmelstein, Michael Zietz, Kyle Kloster, Benjamin Heil, Yun Hao, Gregory Way, Michael Nagle, Blair Sullivan, Casey Greene
(2022-03-20) https://github.com/greenelab/connectivity-search-analyses

Ideally this would have a container-title like:

greenelab/connectivity-search-analyses repository: Hetnet connectivity search research notebooks
Daniel Himmelstein, Michael Zietz, Kyle Kloster, Benjamin Heil, Yun Hao, Gregory Way, Michael Nagle, Blair Sullivan, Casey Greene
GitHub (2022-03-20) https://github.com/greenelab/connectivity-search-analyses

Thanks @dhimmel for this example. We'll start on planning for the next version soon, and will take this issue into consideration.

@mfenner @dhimmel In running up to the 1.3.0 release, we've discussed this again, and made the decision to not include it in this minor version for reasons of time and resources, but we're very interested in hearing your opinion about possible implementations.
These are some of the points we'd like to get your opinion about:

"Key level": Where should a key (let's call it container-title for now) be located?

The document root: This would set a container title for the whole set of metadata. Signals to users that this is the "publication container" the CFF creators want to have referenced in citations of the software.
Attached to all identifiers: As identifiers may point to "releases" or "publications" of the software project, or a specific version, container-title could be attached to all of them. This would leave tooling with the task to pick the one identifier that should be used.
Attached to one identifier: This would signal users (and tooling) that this is the preferred publication to cite. Would make it easy for conversion tools to pick the "preferred" identifier by implication.

Use cases: If container-title is mainly for tooling to use in conversion to other formats, a case could be made for letting tooling sove this altogether by inferring from, e.g., identifier URLs. This way, we could neglect to add this key altogether, and let others worry about it. Human CFF users could do the same thing, and currently would have to pick the "correct" identifier for their use case.

Additional thoughts:

The original issue seems to be to describe where a citable thing lives. To facilitate this, the simplest option would be to add something along the lines of publisher to the root.
There is the larger question of what "we" (as the software citation community) and what CFF creators would want to put in there. E.g., "we" would prefer to have "Zenodo" whereas developers may naturally prefer package managers, which are better for usability of the software, but may be worse for citation metadata and posterity.
The overhead of maintaining consistency between the software and several fields in CFF is already there, so this isn't a blocker.

For reference, the Zotero translator code is here: https://github.com/zotero/translators/blob/450efe2d873be12131e33f78e37084264ccf6ed0/CFF.js#L70

authors: dhimmel jspaaks mfenner sdruskat


text:
feature: Design tweaks [NP-534]

Related Content gets a top margin to make it start at the same height as the H1 title.
H2 gets a top margin after targeted content and callouts.
Notice banner template adjusted to account for p tags coming in with the content.

See Advice Collection sample page to check changes

LGTM!

authors: panosvoudouris shahzainb

repo: citizensadvice/design-system


text:
Fixes invalid column_name minute for http_request in insert statements

http_request table does not have minute column but in insert statements we are trying to use minute column . I changed it into date_trunc('minute', ingest_time) which was used in other insert statements in the same document

Thanks for noticing and fixing.

authors: gurkanindibay jonels-msft


text:
Feedback from Web

Found this in an article in German:
PaperMerge bietet ebenfalls eine vorgefertigte docker-compose-Datei an. Es ist leicht in Betrieb zu nehmen und bietet eine API an. Allerdings werden hier auch maschinell erstellte PDFs durch die OCR bearbeitet, was natürlich im Vergleich zu Systmen, die das erkennen und die Textextraktion ohne OCR vornehmen können wesentlich langsamer funktioniert. OCR funktioniert automatisch und liefert erwartbare Ergebnisse. Allerdings scheint das System generell noch nicht ausgereift genug für den Einsatz im täglichen Betrieb vor allem für nicht-IT-affine Benutzer: So kommt es etwa beim Versuch, einen Ordner übder das Web-Frontend zu löschen, der noch Dokumente enthält zu einem Fehler, der dem Benutzer einen Stacktrace aus den Eingeweiden des Systems anzeigt. Generell ist auch der interne Workflow noch verbesserungswürdig: Lädt man ein Dokument hoch, beginnt der Prozess der OCR sofort. Löscht man das Dokument wieder bevor die OCR abgeschlossen ist, wird die OCR trotzdem weiter fortgeführt - sogar nach einem zwischenzeitlichen Neustart des Docker-Containers. Die OCR ist so konfiguriert, dass die Erkennung einzelner Seiten mit konfigurierbaren Pausen stattfindet, so dass der Rechner auch bei der Verarbeitung großer Dokumente noch genug Ressourcen für andere Aufgaben hat. Daher muss man sich nicht unbedingt darum kümmern, für die Container Regeln via cgroups anzulegen.

honest, user feedback, helps a lot to improve the system.

repo: ciur/papermerge


text:
Bug with cugraph and MAT.jl

Affects: PythonCall
Describe the bug
I tried to do
using MAT, PythonCall
py_cugraph = pyimport("cugraph");

and it errored (see the end of the bug report for the first few lines of the error).
If, instead I try
using PythonCall
py_cugraph = pyimport("cugraph");
using MAT

it works fine (no errors), and I can run commands from cugraph. But this cannot work when preparing a package because all using commands supersede the pyimport commands defined in the __init()__ routine. g
I am copying below the state of the Project.toml and CondaPkg.toml that reproduces this error on Linux.
System
Information about the system:

The operating system: Linux linux53 5.15.0-75-generic #82-Ubuntu SMP Tue Jun 6 23:10:23 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Julia v1.9.0
PythonCall v0.9.13
MAT v0.10.5
Pkg.status()Status `/tmp/problem/Project.toml`
  [992eb4ea] CondaPkg v0.2.18
  [23992714] MAT v0.10.5
  [6099a3de] PythonCall v0.9.13

CondaPkg.status()CondaPkg Status /tmp/problem/CondaPkg.toml
Environment
  /tmp/problem/.CondaPkg/env
Packages
  cudf v23.06.01 (23.06.1)
  cugraph v23.06.02 (23.06.2)
  scipy v1.11.1 (1.11.1)
Channels
  conda-forge
  nvidia
  rapidsai

Additional context
I am sharing here the first few lines of the error:
s2n_init() failed: 402653193 (NULL pointer encountered)
Fatal error condition occurred in /home/conda/feedstock_root/build_artifacts/aws-c-io_1686376437702/work/source/s2n/s2n_tls_channel_handler.c:203: 0 && "s2n_init() failed"
Exiting Application
################################################################################
Stack trace:
################################################################################
/tmp/problem/.CondaPkg/env/lib/python3.10/site-packages/pyarrow/../../../././libaws-c-common.so.1(aws_backtrace_print+0x59) [0x7f03a8af0839]
/tmp/problem/.CondaPkg/env/lib/python3.10/site-packages/pyarrow/../../../././libaws-c-common.so.1(aws_fatal_assert+0x46) [0x7f03a8ade646]
/tmp/problem/.CondaPkg/env/lib/python3.10/site-packages/pyarrow/../../../././libaws-c-io.so.1.0.0(+0x29641) [0x7f03a8995641]
/tmp/problem/.CondaPkg/env/lib/python3.10/site-packages/pyarrow/../../../././libaws-c-mqtt.so.1.0.0(aws_mqtt_library_init+0x21) [0x7f03a8a902c1]
/tmp/problem/.CondaPkg/env/lib/python3.10/site-packages/pyarrow/../../.././libaws-crt-cpp.so(_ZN3Aws3Crt9ApiHandleC2EP13aws_allocator+0x2d) [0x7f03a9103dad]
/tmp/problem/.CondaPkg/env/lib/python3.10/site-packages/pyarrow/../../.././libaws-cpp-sdk-core.so(_ZN3Aws13InitializeCrtEv+0x30) [0x7f03a92ceaf0]
/tmp/problem/.CondaPkg/env/lib/python3.10/site-packages/pyarrow/../../.././libaws-cpp-sdk-core.so(_ZN3Aws7InitAPIERKNS_10SDKOptionsE+0x4a) [0x7f03a92cd46a]
/tmp/problem/.CondaPkg/env/lib/python3.10/site-packages/pyarrow/../../../libarrow.so.1100(+0x108e233) [0x7f03ab0bf233]
/tmp/problem/.CondaPkg/env/lib/python3.10/site-packages/pyarrow/../../../libarrow.so.1100(_ZN5arrow2fs12InitializeS3ERKNS0_15S3GlobalOptionsE+0x47) [0x7f03ab0c4127]
/tmp/problem/.CondaPkg/env/lib/python3.10/site-packages/pyarrow/_s3fs.cpython-310-x86_64-linux-gnu.so(+0x139e1) [0x7f03a41a69e1]

This sort of thing is often caused by conflicting versions of libraries being loaded - in this case presumably it's Python and Matlab conflicting.
I'd recommend starting Julia like LD_DEBUG=libs julia, which prints out the paths of any libraries being loaded. Run your two examples above and see if there are any libraries which are loaded from different paths between the two runs.

authors: cjdoris fcdimitr


text:
add coverage support

Fix #35
Report at: https://codecov.io/gh/gengjiawen/uvwasi/tree/f38d38beebfc4b4ce824305b307d6c26bbeecfbe.

This looks very cool, thank you! I probably won't be able to test this out until tonight due to travel, but I'm excited to have this functionality.

If we want to show code coverage in PR, we need to setup a codecov account, and set an secret env.

Wait, I just realized that codecov is a paid service. Isn't there a free way to do this? The coverage report doesn't have to be linkable. I'd be fine with it just getting dumped to the CI logs.

The website says "Free for open source". It limits the number of users to 5, but maybe we will only need one for automatic coverage reports?

Free for open source. Plans starting at $10/user per month.

Gosh. It was right next to the part that I did read. 🤦♂

So I went to register for codecov, and it made me a bit uneasy. It seems to want access to a lot of things in my GitHub account just to sign up.

I have never used it, maybe we should consider alternatives? Can we use the same tools that we use for node core?

Can we use the same tools that we use for node core?

We could probably collect the coverage data, but we don't have anywhere like coverage.nodejs.org to put the reports for review (from what I can tell, that's the biggest thing that codecov.io offers). Ideally, I'd prefer something like the coverage information at the bottom of https://travis-ci.org/cjihrig/grpc-server-js/jobs/596687685... but that's a JavaScript project, and I don't know what C has that's similar.

We can report upload the result page to GH pages.

the biggest thing that codecov.io offers

It also can show coverage change in PR.
Maybe I remove coverage.io support in this PR, and just leave the html report as a n artifact.

Maybe I remove coverage.io support in this PR, and just leave the html report as a n artifact.

That sounds like a good idea until we can figure out a way to better integrate coverage into the CI.

Can you squash these commits please.

I always use the Github Squash and merge ? Is it okay for you too ?

Looks like lcov auto print coverage rate in console
Overall coverage rate:
  lines......: 25.0% (287 of 1149 lines)
  functions..: 26.9% (18 of 67 functions)

I use git rebase -i, because otherwise the resulting commit message is a mashup of all of the individual commit messages. No worries, I can squash it for you.

I use git rebase -i, because otherwise the resulting commit message is a mashup of all of the individual commit messages. No worries, I can squash it for you.

Github can edit message when you squash. I heavily use this feature because I worry lose my code when I do rebase :) (being to cautious maybe)

Github can edit message when you squash.

OK, I'm fine with using it then.

Thanks for seeing this through!

authors: cjihrig gengjiawen tniessen

repo: cjihrig/uvwasi


text:
Update to 0.12.1

This is an automated issue created by the CLIc to update the dependencies.

We are rerunning the update process.

We are rerunning the update process.

Auto-Update rerunned: Auto Update.

Auto-Update rerunned: Auto Update.

Auto-Update rerunned: Auto Update.

Auto-Update rerunned: Auto Update.

Auto-Update rerunned: Auto Update.

Rerunn of the Auto-Update workflow : 14.

Rerunn of the Auto-Update workflow : 15.

Rerunn of the Auto-Update workflow : 16.

Rerunn of the Auto-Update workflow : 17.

Rerun of the Auto-Update workflow: #18.

This is an automated issue created by the auto-update workflow following up a new Release of CLIc.
Release Information

Release Tag: 0.12.1
Changelog: View Changelog

Please review the changes and update the dependencies accordingly.


text:
A way to silence drv_unknown_argument warnings.

I use clangd with a compile_commands.json file that's generated by CMake. CMake is invoked with gcc as the compiler for this project, and a gcc-specific argument (-fstack-usage) gets put into compile_commands.json.
clangd warns me that -fstack-usage isn't a valid argument on line 1 of every single file, which is annoying.
Is there a way to silence this warning? If not, I think it'd be nice from a usability point of view to add a way to disable this warning.
Thanks!

Not today. There's a few ways we could go here:

once we have config, we will allow rule-based filtering of args from the compilation database
we could have a hard-coded filter filter well-known ignored args
we could have a hard-coded blacklist of well-known false positives from drv_unknown_argument
we could filter drv_unknown_argument entirely. I worry this is sometimes a symptom of an argv we failed to properly parse, though.

Any of your suggestions would do, really, rule-based filtering being the best.
An alternative would be to allow disabling checks, so you could disable drv_unknown_argument errors altogether.

As of clangd 11, you can create a config file in the project or user config dir that strips -fstack-usage
http://clangd.llvm.org/config.html
And specifically:
CompileFlags:
  Remove: -fstack-usage

Customizable filtering of diagnostics is also an interesting idea we should keep in mind, but I think the original need is addressed (at least in the latest snapshots)

authors: randrej sam-mccall

repo: clangd/clangd


text:
如何自定义 (How to Customize media control bar)

怎么能隐藏控制条？怎么让视频拉伸满屏幕

我已经使用谷歌翻译  translate.google.com，我认为，你的母语是中国人，我很抱歉，我不知道你的语言，但我想你问过：
*您如何隐藏控制栏？对于这一个，你可以开始 chromeless (github.com/clappr/clappr#chromeless）或'disable`在创建后的媒体控制。
*如何让视频全屏拉伸？我不明白这个问题。

I have used google translator (https://translate.google.com/) and I supposed that your native language is Chinese and I am sorry that I don't know  your language, but I think you've asked:

How you can hide the control bar? For this one you can either start chromeless or disable the media control after its creation.
How to make the video full screen stretch? I don't understood this question.

about "full screen stretch" - I think that @liuyukk26 asked how to go fullscreen programmaticaly for chromeless player or resize player to fit container size (adaptive player size).
@leandromoreira , correct me if Im wrong
fullscreen:
var player = new Clappr.Player({source: "http://your.video/here.mp4", parentId: "#player"});
player.setFullscreen();

adaptive resize:
function resizePlayer(){
    var aspectRatio = 9/16,
        newWidth = document.getElementById('liveplayer').parentElement.offsetWidth,
        newHeight = newWidth * aspectRatio;
    player.resize({width: newWidth, height: newHeight});
}
resizePlayer();
window.onresize = resizePlayer;

@liuyukk26 @me-vlad About the fullscreen transition on play, I already mentioned this on #527. There are restrictions on the browser Fullscreen API that prevent entering fullscreen programatically, except during an user interaction. To make this work correctly, we should only transition to fullscreen programatically during a click/touch handler.
We still don't have a public method for the player to enter fullscreen, but with the current API, you could use something like that to enter fullscreen when playing:
var player = new Clappr.Player({
  source: 'http://clappr.io/highline.mp4',
  poster: 'http://clappr.io/poster.png',
  parent: '#player-wrapper',
  mute: true,
  height: 360,
  width: 640
});
player.getPlugin('poster').$el.on('click', function() {
  player.core.mediaControl.toggleFullscreen();
});

Since this is one of the most common questions/requests, I'll create an issue to propose adding an embed option to enter fullscreen on play, and a toggleFullscreen() method to the public interface of the Player object.

authors: leandromoreira liuyukk26 me-vlad towerz

repo: clappr/clappr


text:
Chromeless Shows "Play" Icon

Even though I have set chromeless: true the play icon is displayed.

Also the buffering/loading animation is shown...

Not a problem with master version.


text:
Allow source to be a an instance of a class

useful for cases like https://github.com/tjenkinson/clappr-videocontext-playback

Coverage decreased (-0.02%) to 69.973% when pulling 3c33821c8bfffd7f2a2052ad882cc530b3c23821 on feature/object-source into a3802ba0a060d2502b7af76395879a9ed0a4fae7 on master.

LGTM

wouldn't be easier to pass the instance as a parameter for the new playback? seems weird to have the core source support other things than strings

@thiagopnts do you mean?
var _player = new Clappr.Player({sourceSolver: MyInstance})

How do you mean? Clappr instantiates the playback internally so I'm not sure how that would work

On 23 May 2016, at 17:33, Thiago Pontes notifications@github.com wrote:
wouldn't be easier to pass the instance as a parameter for the new playback? seems weird to have the core source support other things than strings
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

your canplay method can use information from the source string to decide rather it should play or not, e.g. in the 360 plugin I just pass video.mp4#360 as a source and my canPlay just match for /#360$/.

@thiagopnts a string isn't suitable though in the case of https://github.com/tjenkinson/clappr-videocontext-playback because it's another object which is responsible in rendering into a canvas, and methods called on that may change the contents of the timeline.

@tjenkinson would it work with something like this?
constructor(options) {
    super(options)
    this._context = options.context
  //etc
 }
VideoContextPlayback.canPlay = (resource) => {
  return resource === 'video-context-playback'
}

@thiagopnts how would I get it to options.context though?

aren't params from the player constructor passed to the other components anymore?

@thiagopnts it looks like they are I didn't realise that. I think it does actually make sense being the source though as is the linked case the VideoContext object is the source of the content.

agree, I would just avoid adding code for edge cases that can be worked around using the plugin system

authors: coveralls leandromoreira thiagopnts tjenkinson towerz


text:
Keep a record of how many times the !bulb is used/colors

Similar to https://github.com/clarkio/ttv-chat-light/issues/91

Suggested by Janisku7 on Twitch (feel free to correct with GitHub account)

Added feature would be to have a pie chart of most used colors (suggested by deathpax on Twitch)

Keep track of how many unsupported colors are attempted (suggested by codephobia on Twitch)

repo: clarkio/ttv-chat-light


text:
Does Kamaji support accessing the container pod?

In Kamaji, is it supported to enter the container pod? Because when I try using kubectl exec, it can't enter the container pod. Or am I doing something wrong in installing and configuring Kamaji?

Strictly related to #443, prior to giving a try to Kamaji I strongly suggest knowing in depth the architecture of Kubernetes, and Control Plane <> Kubelet communications.
tl;dr; you have to enable Konnectivity, we also have a dedication section on our documentation website.

repo: clastix/kamaji


text:
Move cancel to the end of event queue

Bottom line up front: Awesome plugin! Keep up the good work. — I’ve looked into a lot of similar components, and this is, by far the most stable, and the most easy to integrate component that I’ve seen so far. — Kudos for that.
Summary
This is for people with really sensitive touch devices (like trackpads configured to be really fast; or especially for designers who have gotten used to work fast and with precision.
What was Happening
(hard to describe verbally but I’ll try)

The user starts moving her finger from outside the sortable list towards a sortable container.
(while not stopping the finger movement on the trackpad) the user lightly touches the trackpad (in trackpad terms: this is a regular touch, not a force touch)
(still not stopping the finger movement) the user continues to move her finger while keeping the finger lightly touched; hence triggering a touchmove event.

User’s Experience
The user has _touched the sortable container, but without having time to register a delta a cancel event is fired in the move handler because pressTimer runs the handlePress in a timer. This will cancel the drag but since the user assumes that she’s still dragging, she’ll continue to drag hopelessly expecting the container to move, with no luck.
She will trying to drag the container; but the container will not moving at all.
(because the movement is cancelled before even being able to start; though the finger is still moving on the tracpad and the finger is still pressing against the trackpad)
Since the expected behavior is to see the container drag; container not moving cause a mild annoyance.
How does this commit solve the issue?
By setting an immediate timer, we move the cancel event to the tail of the timer queue, and ensure that it is fired after the pressTimer.
That should not impact a typical use case, and enhance the edge case described in this commit.
Other Options
If this timer fix does not work for some reason; a second option might be to track the state of the pressTimer; and not fire cancel if the press timer has been set but no delta registered yet — though I feel like that will make things even more complicated.

Hey @v0lkan, can you give me more insight into how to replicate this? What kind of touchpad showcases this behaviour? I'm personally unable to replicate this.
I'll also need to test this to make sure there are no side-effects

Hi @clauderic the fix will cause regression because I mistakenly using this.cancelTimer instead of something like () => { this.cancelTimer() }.
I will amend a change.
I am also recording a video (with and without the patch) to show you the experience.
I am using the recent Apple magic trackpad, on a pretty recent version of Macbook Pro (not the latest one on the apple event — without the escape key; the one before that :) )
I tested both recent chrome and safari and outcomes were the same.

Hi @clauderic here’s my recording: https://www.youtube.com/watch?v=g-MkFj10C-U
I also annotated it at important checkpoints;
If it does not cause any regressions, the patch will definitely improve the user experience.
I’ll amend a change momentarily to fix the stuff that mentioned above.

Hi @clauderic; did you have time to watch the video?
Do you have any other input from me to replicate the issue.
Best,
Volkan.

Confirming the exact issue here:
MacOS Sierra 10.12.1 (16B2555)
Chrome 54.0.2840.98 (64-bit)
react 15.4 / react-sortable-hoc 0.3.0
Most the time, the drag does not work on the first try.  My naive intuition was that something in the demo page was just not done loading and I had to wait.  Then locally, I thought maybe there was a default pressDelay of ~200ms applied.  I came looking for a prop that I could set to make items immediately draggable.
I applied the patch manually to the dist files and the issue is mitigated.

Glad that I was not being crazy seeing someone else also got impacted :)
And its good that the patch fixes the issue.
Let’s hope there are no regressions.
cc: @clauderic

Hey @v0lkan,
This looks good to be merged at this point. The last thing I want to check before merging though is that this does not conflict with the changes that were introduced with #71.

I can test this real quick, hang tight..

@clauderic Tested and all is well:
MacBook Pro (Retina, 15-inch, Mid 2015) version 10.12.1 (16B2555)
Google Chrome Version 54.0.2840.98 (64-bit)
react-sortable-hoc v0.4.0
react v15.4.0
pressDelay={0}
Instant dragging, no issues.
pressDelay={1000}
Dragging starts after 1s of holding a click.
no pressDelay
Instant dragging, no issues.

Seems both patches work perfectly together 👍

Oh, should've noted, without the patch here in this PR there is still the issue of having to rest the mouse before dragging else nothing happens.

Just tested myself, looks good!
LGTM 🚢

A bit late to the party :) — Glad to see this merged.
Cheers,
V.

Up

repo: clauderic/react-sortable-hoc


text:
why does it wrap paragraphs within blockquotes in quotes?

the following
> **Hint**: why is
> this paragraph in quotes
>
> * list in blockquote
>
> and another paragraph

yields

I wonder why the paragraphs in the blockquote are wrapped in quotes.

I think you can easily turn this behaviour off

repo: claudioc/jingo


text:
The filename is decoded wrongly on Safari

I'm opening this issue because:

[x] I have found a bug

My Go version / GOPATH is: N/A
(N/A because I use the pre-compiled binary.)

How to Reproduce
touch 啊.txt
# ISO/IEC 8859-1 (Latin 1) does not contain 啊
qrcp send 啊.txt

Then open the link in iOS Safari. You'll find å.txt.
Reason
The filename is declared in UTF-8 as \xe5\x95\x8a.txt in the header Content-Disposition, but Safari interprets it in ISO/IEC 8859-1 as å\x95\x8a.txt.
# Inspect the response with HTTPie
$ https http://*.*.*.*:**/send/****
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Disposition: "attachment; filename=\xe5\x95\x8a.txt"
Content-Length: 110
Content-Type: text/plain; charset=utf-8
…

Possible solution
Add filename* in Content-Disposition.
https://github.com/claudiodangelis/qrcp/blob/8b35ad8a379cec8ce75878b557b8f3de165d39fb/server/server.go#L222-L223
§4.3. Disposition Parameter: 'Filename' - RFC 6266:

The parameters filename and filename* differ only in that filename* uses the encoding defined in [RFC5987], allowing the use of characters not present in the ISO-8859-1 character set ([ISO-8859-1]).

Appendix D. Advice on Generating Content-Disposition Header Fields - RFC 6266:

Include a filename* parameter where the desired filename cannot be expressed faithfully using the filename form. Note that legacy user agents will not process this, and will fall back to using the "filename" parameter's content.

An example in RFC 6266:
Content-Disposition: attachment;
                     filename="EURO rates";
                     filename*=utf-8''%e2%82%ac%20rates

The syntax of the value of filename* is specified in RFC 5987 §3.2.1:
ext-value     = charset  "'" [ language ] "'" value-chars
                   ; like [RFC 2231](https://www.rfc-editor.org/rfc/rfc2231)'s <extended-initial-value>
                   ; (see [[RFC2231], Section 7](https://www.rfc-editor.org/rfc/rfc2231#section-7))

I can make a PR if you want.

I guess #253 should work?

repo: claudiodangelis/qrcp


text:
Riemann is not building on macOS Big Sur

Probably not entirely surprising but I figured I would at least post this as I think at least we can start to gather intel here. Note that this should be only build errors specific to Riemann, not other packages in Clawpack.

This gets thrown when trying to install clawpack in general and just so happens that rp1_acoustics_ptwise is the first recipient of the prize.  Interestingly I think that warning about 11.0 might be more problematic than it seems though.  Take a look at this discussion on scipy issues as a possible lead.
ERROR: Command errored out with exit status 1:
     command: /usr/local/opt/python@3.9/bin/python3.9 -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/Users/mandli/Dropbox/src/clawpack/setup.py'"'"'; __file__='"'"'/Users/mandli/Dropbox/src/clawpack/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' develop --no-deps
         cwd: /Users/mandli/Dropbox/src/clawpack/
    Complete output (25 lines):
    gfortran: warning: couldn't understand version 11.0
    gfortran: warning: couldn't understand version 11.0
    gfortran: warning: couldn't understand version 11.0
    gfortran: warning: couldn't understand version 11.0
    gfortran: warning: couldn't understand version 11.0
    gfortran: warning: couldn't understand version 11.0
    gfortran: warning: couldn't understand version 11.0
    gfortran: warning: couldn't understand version 11.0
    gfortran: warning: couldn't understand version 11.0
    gfortran: warning: couldn't understand version 11.0
    riemann/src/rp1_acoustics_ptwise.f90:5:66:

        5 | subroutine rp1_ptwise(num_eqn, num_aux, num_waves, q_l, q_r, aux_l, aux_r,    &
          |                                                                  1
    Warning: Unused dummy argument 'aux_l' at (1) [-Wunused-dummy-argument]
    riemann/src/rp1_acoustics_ptwise.f90:5:73:

        5 | subroutine rp1_ptwise(num_eqn, num_aux, num_waves, q_l, q_r, aux_l, aux_r,    &
          |                                                                         1
    Warning: Unused dummy argument 'aux_r' at (1) [-Wunused-dummy-argument]
    gfortran: warning: couldn't understand version 11.0
    gfortran: warning: couldn't understand version 11.0
    ld: library not found for -lgcc_s.10.4
    collect2: error: ld returned 1 exit status
    error: Command "/usr/local/bin/gfortran -Wall -g -Wall -g -undefined dynamic_lookup -bundle build/temp.macosx-11.0-x86_64-3.9/build/src.macosx-11.0-x86_64-3.9/clawpack/riemann/acoustics_1D_ptwisemodule.o build/temp.macosx-11.0-x86_64-3.9/build/src.macosx-11.0-x86_64-3.9/build/src.macosx-11.0-x86_64-3.9/clawpack/riemann/fortranobject.o build/temp.macosx-11.0-x86_64-3.9/riemann/src/rp1_ptwise.o build/temp.macosx-11.0-x86_64-3.9/riemann/src/rp1_acoustics_ptwise.o build/temp.macosx-11.0-x86_64-3.9/build/src.macosx-11.0-x86_64-3.9/clawpack/riemann/acoustics_1D_ptwise-f2pywrappers.o -L/usr/local/Cellar/gcc/10.2.0/lib/gcc/10/gcc/x86_64-apple-darwin19/10.2.0 -L/usr/local/Cellar/gcc/10.2.0/lib/gcc/10/gcc/x86_64-apple-darwin19/10.2.0/../../.. -L/usr/local/Cellar/gcc/10.2.0/lib/gcc/10/gcc/x86_64-apple-darwin19/10.2.0/../../.. -L/usr/local/lib -L/usr/local/opt/openssl@1.1/lib -L/usr/local/opt/sqlite/lib -lgfortran -o riemann/riemann/acoustics_1D_ptwise.cpython-39-darwin.so" failed with exit status 1
    ----------------------------------------

repo: clawpack/riemann


text:
🛑 livevault is down

In 947c04b, livevault (https://livevault.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: livevault is back up in a6ca379.

repo: claytonplong/backup-uptime


text:
🛑 livevault is down

In af4c901, livevault (https://livevault.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: livevault is back up in 5af285f.


text:
please post package in downloads

Would you please post a zip package of the WikiNotes source in the
downloads area, for convenience?  THX.

Original issue reported on code.google.com by jehrl...@dairyvets.com on 8 Mar 2008 at 2:27

I have put a zipped version of the source code for WikiNotes for Android in the
downloads area. However I would encourage everyone to use subversion to get the
source instead of the zip file if at all possible. I will try and remember to
update
the zip file on important changes, but the subversion repository will always
represent the latest sample code.

Original comment by dickw...@gmail.com on 12 Mar 2008 at 11:47

Changed state: Fixed

repo: clc/apps-for-android


text:
Cannot call setState() on component instance

I'm trying to call setState on a component instance:
var myComponentInstance = MyComponent({'someProp': 'hello'}, [...]);

...

myComponentInstance.setState({'someProp': 'goodbye'});

This throws an error to the console:
Exception: Unhandled exception:
Class 'JsObject' has no instance method 'setState'.

NoSuchMethodError: method not found: 'setState'
Receiver: Instance of 'JsObject'
Arguments: [Instance of '_LinkedHashMap']
#0      Object.noSuchMethod (dart:core-patch/object_patch.dart:45)

@maxwellpeterson-wf you cannot call setState on the result of component factory. Component factory you created, myComponentInstance, is just descriptor saying to React, here should be that kind of component with these props. But you do not have an access to the component itself and can't call its methods. You can use setState only inside the component itself.

authors: hleumas maxwellpeterson-wf

repo: cleandart/react-dart


text:
Unable to get Cleanlab API

I am trying to do the Cleanlab Python API but can't get the API key.
It shows something like this even though I have signed up for the account by following the process given in the documentation.

Please help me fix this issue, thanks a ton in advance.

Hi @abhigyan631, did you already fill out the access request form?
If so, could you let me know what email you used to sign up?
Thanks + apologies for the inconvenience you experienced in advance!

Apologies, just saw the notification on Github, I created the account, and I got this as the message
"Success! Your account is being created! Expect a welcome email with login info from us in the next day :)"
Thank you.

repo: cleanlab/cleanlab-studio


text:
AE49_181023_194515.405

Type: Missing
Summary:
License
Details:
Add Apache 2.0
Resolution:
https://github.com/aspnet/Configuration/blob/2.0.1/LICENSE.txt
Affected definitions:

Microsoft.Extensions.Configuration.EnvironmentVariables 2.1.1,- Microsoft.Extensions.Configuration.FileExtensions 2.1.1,- Microsoft.Extensions.Configuration.Json 2.1.1

Duplicate of #519

repo: clearlydefined/curated-data


text:
INSTALACAO - Atualizar README.md

Fala @cleitonleonel , tudo bem? Voce poderia por favor atualizar o README.md explicando como faz para instalar o projeto?
Tentei utilizar:
python redecanais.py --search hbo
dentro da pasta redecanais e retorna:
Sistema Operacional win suportado!!!
Se puder atualizar o readme com o setup e utilizacao vai ser otimo.
Abracos!

@future2back Boas amigo(a), vou atualizar o readme em breve...mas vc pode instalar o projeto utilizando o pacote que está no pypi com um simples pip install redecanais ...

@future2back Boas amigo(a), vou atualizar o readme em breve...mas vc pode instalar o projeto utilizando o pacote que está no pypi com um simples pip install redecanais ...

repo: cleitonleonel/redecanais


text:
autotest.sh and mem25

Hi, I sent code to your private email.

Fixed in commit 450f6f5.

authors: Kmanfi cliffordwolf

repo: cliffordwolf/yosys

license: ISC


text:
Error using with llama3.1 405B model

Which API Provider are you using?
OpenAI Compatible
Which Model are you using?
llama 3.1 405B
What happened?
when using with Together ai's llama3.1 405B Model by connecting the api > open ai compactible model> Together api
everythime I input the command.
503 server overload error is showing.
when asking to Together ai  and testing with other (openwebui, anything llm. etc.) the api is working. only showing error when using on claude dev.

Steps to reproduce

Relevant API REQUEST output
503 server is overloaded.

Additional context
No response

503 is out of my hands, I suggest using a different provider until their service is available again

authors: Set-PP saoudrizwan

repo: clinebot/cline