Adjust LIPS text limits

The text engine properly centers LIPS text even after changing horizontal text offset, but it forces strange line breaking behavior on strings longer than 18 characters. This occurs after text is loaded to memory but before it is drawn to screen. In Double LIPS dialogs, when the choices change over after half of the time limit elapses, the text can be seen to be drawn correctly until the text animation ends, at which point the line breaking occurs and disrupts the strings. The limit of 18 characters will need to be changed or disabled for correct LIPS choice display.

LIPS text limits are determined by the parameters of the dialog box that contains them. By altering the operations that compute this number, the limit can be increased to a maximum of 36.


Fixes to Hover Provider

@rojepp, please test on Mac, when you have some time.

I can check tomorrow.

@Krzysztof-Cieslak Hovering seems to work on osx with this PR. LGTM.


Adding disconnection if no PINGRESP

Currently, PINGRESP was not check for PINGREQ. The success of a PINGREQ was only the fact that you send it.
Connection to broker should be closed if PINGRESP if not received (MQTT <IP_ADDRESS>).
Each time a PINGREQ is sent, a flag if raised and it's cleared when PINGRESP received.
Before sending a PINGREQ, if previous PINGREQ has not been answered, we're disconnecting.

@tuanpmt , is there any estimative to analyze this MR?

Thanks @vtunr and @tuanpmt !


Update manifest to use latest and OSS 3.0.3 which has wayland-default-egl support

Will rebase and create a new PR


Add guessLang() with the new 'auto' lang

Thanks for the PR, I think however that less "magic" there is to it, the better. This can also prove somewhat problematic if there's an expection of auto detection, while for example pip requirements.txt can in reality be called with whatever name the developer wishes.
At the current state, I'd rather leave it off, unfortunately.

also - web projects might use multiple dependency managers already; I'm also in favor of less magic.

I agree with the less magic the better and was thinking the same about multiple languages in the same repo (like client npm packages and any backend tech).


Clarification request about Hybrid AAD Join and "line of sight to the domain controller for the first time"

The document states the following:

In the above deployment model, a newly provisioned user will not be able to sign in using Windows Hello for Business until (a) Azure AD Connect successfully synchronizes the public key to the on-premises Active Directory and (b) device has line of sight to the domain controller for the first time.

Does the device must have a line of sight to the domain controller when the user registers to Windows Hello? When he first attempts to login using its Windows Hello PIN? Both?
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 10fcf686-1781-8a62-16bb-b26b3f5982fd
Version Independent ID: 37d733ad-e809-1674-ffbc-ae3d0c495423
Content: How Windows Hello for Business works - Authentication - Windows security
Content Source: windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md
Product: m365-security
GitHub Login: @mapalko
Microsoft Alias: mapalko

From what I see users are able to register for Windows Hello from outside the Corporate Network, but they must have a line of sight to the domain controller to perform their first PIN authentication in order to be able to use Windows Hello. Am I right?

@paolomatarazzo Please help us in resolving this issue. Thanks

Hello @Martony78 , the documentation may have been updated after your feedback, but it calls out: "In the above deployment model, a newly provisioned user will not be able to sign in using Windows Hello for Business until (a) Azure AD Connect successfully synchronizes the public key to the on-premises Active Directory and (b) device has line of sight to the domain controller for the first time."
you can still sign in using cached credentials and enroll in WHFB. But you will be able to use WHFB only after the two conditions in the note above are met.


Remove beta 20170406

This beta is being withdrawn because of cockroachdb/cockroach#14700 and cockroachdb/cockroach#14692.

This change is

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/b0284ad28321e067c5bed86ca1274bcd664c2f6c/


Tagging Docs

This PR adds a description of tagging support to the graphite docs, all suggestions and/or feedback appreciated.

Codecov Report

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

@@           Coverage Diff           @@
##           master    #2037   +/-   ##
=======================================
  Coverage   69.69%   69.69%
=======================================
  Files          78       78
  Lines        7440     7440
  Branches     1440     1440
=======================================
  Hits         5185     5185
  Misses       1969     1969
  Partials      286      286

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 ffb2eac...e5cfda3. Read the comment docs.


Adding mapping for postgres13

Updating downstream with postgres13 integration.

The version actually in quay is this:
postgresql-13@sha256:a9a53f6ca6e73f9baeb15b3c0a596825ef84bd5d775e693ec26a85031ab46909

Whoops, my bad. I've updated the changes to the correct sha.

That would be pretty cool, and wouldn't you know it, they are named that way now @schmidtd


ouctl uses outdated ingress annotation instead of ingressClassName

2023/11/03 10:24:27 Starting delete for "check-hosts-orchestra" ConfigMap
2023/11/03 10:24:27 Starting delete for "test-orchestra-orchestra" Pod
2023/11/03 10:24:27 creating 28 resource(s)
W1103 10:24:27.904487    5338 warnings.go:70] annotation "kubernetes.io/ingress.class" is deprecated, please use 'spec.ingressClassName' instead
Waiting for a few seconds for the operator to runChecking for the openunison-orchestra 0

We've got to work out a good way to do this.  we can't just switch because we have customers on older clusters that are still on beta.

Sure, I was not expecting a solution instantly, just wanted to report my findings...


Final fixes before ISO version release

:warning: Contains the last fixes before releasing. Merge when all the bugs are fixed

Made show settings a <a> in create collection
Fixed a bug when creating a realtime collection

Current coverage is 86.73% (diff: 100%)

Merging #79 into develop will not change coverage

@@            develop        #79   diff @@
==========================================
  Files           103        103
  Lines          1606       1606
  Methods          49         49
  Messages          0          0
  Branches        119        119
==========================================
  Hits           1393       1393
  Misses          177        177
  Partials         36         36

Powered by Codecov. Last update 6e74da6...b74f0df


[FEATURE] Support Captcha and Appsec mode at the same time

Is your feature request related to a problem? Please describe. 🐛
Currently, if appsec is enabled, captcha remediation is never called.
if bouncer.appsecEnabled {
        if err := appsecQuery(bouncer, remoteIP, req); err != nil {
                bouncer.log.Debug(fmt.Sprintf("handleNextServeHTTP ip:%s isWaf:true %s", remoteIP, err.Error()))
                handleBanServeHTTP(bouncer, rw)
                return
        }
}

Describe the solution you'd like ✨
If appsec is enabled, it should call handleRemediationServeHTTP which decides what remediation to call (ban or captcha)
However, should we cache that the captcha has been completed by the user ?
If a malicious user completes a captcha manually and then is cached in the allow list and can use auditing tools with no additional checks from appsec.
If we don't cache and appsec returns a false positive on some pages, the user experience would not be great as the user would have to to a captcha each time he visits this one page.
Last solution could be to cache the user IP and the page accessed for instance to get in the middle.
We're open to suggestion on this.

Following, probably unable to be of much help.


TextField: System.InvalidOperationException after delete/backspace

V: 0.10.0 from May 18, 2018

Type something in TextField
Try delete character using backspace/delete
System.InvalidOperationException:
w Terminal.Gui.TextField.RuneIndexToByteIndex(Int32 index)
w Terminal.Gui.TextField.ProcessKey(KeyEvent kb)
w Terminal.Gui.View.ProcessKey(KeyEvent keyEvent)
w Terminal.Gui.View.ProcessKey(KeyEvent keyEvent)
w Terminal.Gui.Toplevel.ProcessKey(KeyEvent keyEvent)
w Terminal.Gui.View.ProcessKey(KeyEvent keyEvent)
w Terminal.Gui.Toplevel.ProcessKey(KeyEvent keyEvent)
w Terminal.Gui.Application.ProcessKeyEvent(KeyEvent ke)
w Terminal.Gui.WindowsDriver.Mono.Terminal.IMainLoopDriver.MainIteration()
w Mono.Terminal.MainLoop.MainIteration()
w Terminal.Gui.Application.RunLoop(RunState state, Boolean wait)
w Terminal.Gui.Application.Run(Toplevel view)
w Terminal.Gui.Application.Run()
w gui.Program.Main(String[] args)

Might be a side effect of something we are doing here https://github.com/migueldeicaza/gui.cs/issues/81 , but with 0.9.0 you should be fine.

Incoming fix, will be in the 0.11 release


Race Condition in K8S Start

Hi,
I successfully tested the auth plugin follwing your instructions. Now I would like to automate the deployment. What I found out is, that currently I have a race condition between the DaemonSet and KubeApiServer.
While KubeApiServer is starting (after a new master instance is launched by the AWS Autoscaling Group), the KubeAPIServer is not able to find the kubeconfig.yaml. This is because it's not present on the machine. It's not because the DS is nor started before and therefore heptio auth was not able to generate the config file on the local disc of this machine.
Do you have any ideas how to solve this issue? Using K8s 1.7.10 and current version of Kops for installing.
Thx
Raphael

I just ran into this and got around it using fileAssets in kops to place a dummy file. You also need to edit the example deployment to drop the webhook configuration into /srv/kubernetes since it's mounted in the apiserver pod.
fileAssets:
  - content: |
      clusters:
        - name: heptio-authenticator-aws
          cluster:
            certificate-authority: /srv/kubernetes/ca.crt
            server: https://<IP_ADDRESS>:21362/authenticate
      users:
        - name: apiserver
      current-context: webhook
      contexts:
      - name: webhook
        context:
          cluster: heptio-authenticator-aws
          user: apiserver
    name: heptio-authenticator-aws
    path: /srv/kubernetes/webhook-authentication.yaml
    roles:
    - Master

Funny to hear that. I did exactly the same :-). But instead of file Assets I'm using a hook with an execContainer and mounted the path in it.
`

execContainer:
command:

sh
-c
"apk -Uuv add groff less python py-pip && pip install awscli && mkdir -p /rootfs/srv/kubernetes/heptio-authenticator-aws/ && aws s3 cp 's3://..../kubeconfig.yaml' '/rootfs/srv/kubernetes/heptio-authenticator-aws/kubeconfig.yaml' --region eu-central-1"
image: alpine
`

This was using kops 1.8.


Changed urls

I added correct links :)

:+1:

Thanks for your PR, I will take care ASAP.

travis-ci can not build @MALPI

👍

:+1:

👍

:+1:

:+1:

:+1:

👍


i18n(ES) update to latest EN version

Hi @joebordes, first of all thank you for your very first contribution. I've reviewed and everything seems fine so I'll proceed to merge it and release a new version.

Published a new package with v4.11.1, you can install by running:
npm i<EMAIL_ADDRESS>
Thanks again for your contribution!


failed to execute postMessage

Everything is working perfect, but I get a failed to esecute postMessage in my console. I'm pulling a static page no two way information needed, can I resolve?

You can ignore this message, it's a false error message from the browser. Basically the parent page is trying to talk to the iFrame before the iFrame has started loading.

I have multiple iframes, and my console is full of these messages. Is it possible to remove these messages?

It's a bug in the Chrome browser. You need to raise a bug with Google.


DEVX-238: add interceptors to the microservices demo

@ybyzek please don't forget to merge into trunk too -- otherwise build will fail. Thx.


Add value display to podcast info

Displays the value block on the podcast info page if it is present. I find this to be valuable information (pun intended), for the listener as well as for feed debugging purposes :)
Examples

Looks great!

That's pretty slick.


Export to destinyexotics.com

Add a link to destinyexotics filled out with the user's inventory.
TODO:

unbundle destinyexotic's gear database (see
https://twitter.com/hythloday/status/577809372967006208 for the
creation of a JSON endpoint)
highlight completed gear

love it! i'm going to merge it, but i'll make a few small tweaks.


Allow deleting synced users/groups

If a user/group is deleted from the IdP, we currently disable it. However, it would be nice to be able to clean up old users/groups in cases where there are duplicate Actors or a user/group was mistakenly synced from the IdP.
We could warn the admin with "warning: if this group still exists in your IdP, it will be recreated in Firezone" etc

I think the proper solution for this would be default UI filters. The reason why we keep the actors is audit logging and being able to restore them if IdP syncs them back, and we don't have a good heuristic to know if IdP will do that or not. Alternatively, we can try deleting all actors without identities after each sync, but I feel it would be worse.


Test PR to see of if one line in README.md can be ignored

This is still creating a conflict in the README, so the filter isnt working as expected. WIll re-try with "clean" filter.


plugin sidecar failed. Couldn't find cmp-server plugin supporting repository

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
data:
  configManagementPlugins: |
    - name: argocd-vault-plugin
      generate:
        command: ["argocd-vault-plugin"]
        args: ["generate", "./"]
      discover:
        fileName: "./argocd-vault-plugin"
    - name: argocd-vault-plugin-helm-with-args
      generate:
        command: ["sh", "-c"]
        args: ['helm template "$ARGOCD_APP_NAME" -n "$ARGOCD_APP_NAMESPACE" ${ARGOCD_ENV_HELM_ARGS} . | argocd-vault-plugin generate -']
      discover:
        fileName: "./argocd-vault-plugin-helm-with-args"
    - name: argocd-vault-plugin-helm-with-values
      generate:
        command: ["bash", "-c"]
        args: ['helm template "$ARGOCD_APP_NAME" -n "$ARGOCD_APP_NAMESPACE" -f <(echo "$ARGOCD_ENV_HELM_VALUES") . | argocd-vault-plugin generate -']
      discover:
        fileName: "./argocd-vault-plugin-helm-with-values"
    - name: argocd-vault-plugin-kustomize
      generate:
        command: ["sh", "-c"]
        args: ["kustomize build . | argocd-vault-plugin generate -"]
      discover:
        fileName: "./argocd-vault-plugin-kustomize"

secret/argocd-vault-plugin/vault-configuration.yaml
kubectl apply -f vault-configuration.yaml -n argocd
apiVersion: v1
stringData:
  VAULT_ADDR: http://<IP_ADDRESS>:31758
  AVP_AUTH_TYPE: k8s
  AVP_MOUNT_PATH: auth/kubernetes
  AVP_K8S_ROLE: myapp
  AVP_TYPE: vault
  AVP_K8S_TOKEN_PATH: /var/run/secrets/kubernetes.io/serviceaccount/token
kind: Secret
metadata:
  name: vault-configuration
  namespace: argocd
type: Opaque

kubectl exec -ti vault-0 -n vault /bin/sh

vault policy write app app-policy.hcl

[root@mycompany secret]# cat app-policy.hcl
path "kv/*" {
  capabilities = ["read"]
}

vault auth enable kubernetes

vault write auth/kubernetes/config \
   token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
   kubernetes_host=https://${KUBERNETES_PORT_443_TCP_ADDR}:443 \
<EMAIL_ADDRESS>

vault write auth/kubernetes/role/myapp \
   bound_service_account_names=argocd-repo-server \
   bound_service_account_namespaces=argocd \
   policies=app \
   ttl=1024h

vault kv put kv/cred username=mark password=123

patch.yaml
kubectl patch -n argocd  deploy argocd-repo-server --patch "$(cat patch.yaml)"
spec:
  template:
    spec:
      containers:
      - name: argocd-repo-server
        volumeMounts:
        - name: custom-tools
          mountPath: /usr/local/bin/argocd-vault-plugin
          subPath: argocd-vault-plugin
        envFrom:
          - secretRef:
              name: vault-configuration
      volumes:
      - name: custom-tools
        emptyDir: {}
      initContainers:
      - name: download-tools
        image: registry.cn-hangzhou.aliyuncs.com/hxpdocker/argocd-vault-plugin:v1
        imagePullPolicy: IfNotPresent
        command: [sh, -c]
        args:
          - >-
            cp /argocd-vault-plugin /custom-tools/
        volumeMounts:
          - mountPath: /custom-tools
            name: custom-tools
      automountServiceAccountToken: true

secret/argocd-vault-plugin/ap-clusterResourceWhitelist.yaml
kubectl apply -f ap-clusterResourceWhitelist.yaml -n argocd
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: project
spec:
  clusterResourceWhitelist:
  - group: ""
    kind: Namespace
  sourceRepos:
    - https://gitee.com/hxpgit/argocd.git
  destinations:
    - server: https://<IP_ADDRESS>:6443
      namespace: demo
      name: cluster1
    - server: https://<IP_ADDRESS>:6443
      namespace: demo

secret/app-argocd-vault-plugin-configmap.yaml
kubectl apply -f app-argocd-vault-plugin-configmap.yaml -n argocd
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app
spec:
  destination:
    namespace: demo
    name: cluster1
  source:
    repoURL: https://gitee.com/hxpgit/argocd.git
    path: demo1/secretManager/argocd-vault-plugin
    targetRevision: HEAD
    plugin:
      env:
      - name: VAULT_ADDR
        value: http://vault-active.vault.svc:8200
      - name: AVP_AUTH_TYPE
        value: k8s
      - name: AVP_MOUNT_PATH
        value: auth/kubernetes
      - name: AVP_K8S_ROLE
        value: myapp
      - name: AVP_KV_VERSION
        value: "2"
      - name: AVP_TYPE
        value: vault
      - name: AVP_K8S_TOKEN_PATH
        value: /var/run/secrets/kubernetes.io/serviceaccount/token
  project: project
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

[root@mycompany secret]# argocd app sync app
TIMESTAMP                  GROUP        KIND   NAMESPACE                  NAME    STATUS   HEALTH        HOOK  MESSAGE
2023-04-21T20:58:51-07:00             Secret        demo    example-annotation   Unknown

Name:               argocd/app
Project:            project
Server:             cluster1
Namespace:          demo
URL:                https://argocd-server.argocd.svc.cluster.local/applications/app
Repo:               https://gitee.com/hxpgit/argocd.git
Target:             HEAD
Path:               demo1/secretManager/argocd-vault-plugin
SyncWindow:         Sync Allowed
Sync Policy:        Automated (Prune)
Sync Status:        Unknown
Health Status:      Healthy

Operation:          Sync
Sync Revision:
Phase:              Error
Start:              2023-04-21 20:58:50 -0700 PDT
Finished:           2023-04-21 20:58:51 -0700 PDT
Duration:           1s
Message:            ComparisonError: rpc error: code = Unknown desc = Manifest generation error (cached): plugin sidecar failed. Couldn't find cmp-server plugin supporting repository .demo1/secretManager/argocd-vault-plugin

GROUP  KIND    NAMESPACE  NAME                STATUS   HEALTH  HOOK  MESSAGE
       Secret  demo       example-annotation  Unknown
FATA[0001] Operation has completed with phase: Error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots/Verbose output
If applicable, add screenshots to help explain your problem.
If you've tried running argocd-vault-plugin generate with --verbose-sensitive-output to help debug, please include that output here after redacting any secrets.
Additional context
Add any other context about the problem here.

Please follow the guide here https://argo-cd.readthedocs.io/en/stable/operator-manual/config-management-plugins/#sidecar-plugin and https://argocd-vault-plugin.readthedocs.io/en/stable/installation/#custom-image-and-configuration-via-argocd-cm-configmap

I followed the guide,could you see what was wrong in my config?

In this issue you raised https://github.com/argoproj-labs/argocd-vault-plugin/issues/496 you were using sidecar and were able to get AVP to run. So it seems like you should be following the setup you had in that issue to solve this issue.

not support any more


IMU Preintegration

Add a symforce.slam.imu_preintegration module that provides a symbolic implementation of tangent preintegration, and generates Python and C++ runtime functions for the main update function. Also adds a lightweight Python wrapper class to maintain state and tests against GTSAM.

Another thing to discuss @aaron-skydio is that this puts the python generated code into sym.factors. This makes sense to me and matches C++, but I doubt we want it in the symforce-sym package, and also it makes it perhaps so you have to pip install -e . before you can import it (ie the build is required to iterate)

I think it seems reasonable to put the generated python factors into symforce-sym, since we'll presumably do the same for C++ generated factor headers.  Rerunning pip install -e . to update symforce-sym is something we should additionally fix though

This was moved to #279, which is now merged - further work on this should be new PR(s)


Xcode 14 build error (GoogleMobileAds)

Description
Undefined symbols for architecture x86_64:
"OBJC_CLASS$_JSContext", referenced from:
objc-class-ref in GoogleMobileAds(GADOMIDLightJSExecutor.o)
ld: symbol(s) not found for architecture x86_64
Reproducing the issue
No response
Firebase SDK Version
9.6.0, 9.5.0
Xcode Version
14.0.1
Installation Method
Swift Package Manager
Firebase Product(s)
All
Targeted Platforms
iOS
Relevant Log Output
No response
If using Swift Package Manager, the project's Package.resolved

Expand Package.resolved snippet

Replace this line with the contents of your Package.resolved.

If using CocoaPods, the project's Podfile.lock

Expand Podfile.lock snippet

Replace this line with the contents of your Podfile.lock!

Please reach out to AdMob support at https://developers.google.com/admob/ios/support.


Update da-dynamodb-client, da-s3-client to 0.1.28

About this PR
📦 Updates

uk.gov.nationalarchives:da-dynamodb-client
uk.gov.nationalarchives:da-s3-client

from 0.1.27 to 0.1.28
📜 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 = "uk.gov.nationalarchives" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "uk.gov.nationalarchives" }
}]

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

Superseded by #30.


adds sinon lib. updates fetcher module implementation and…

… updates tests. adds error handling wrapping function

Coverage remained the same at 27.176% when pulling 0439ff49db878f555aa160c11fdb12ce131a189b on theseyi:sinon into a12b7dfbe173a7b5f03d6a86c682dd2e1f7cec7a on linkedin:master.

Codecov Report

Merging #886 into master will increase coverage by 0.26%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##           master     #886      +/-   ##
==========================================
+ Coverage   35.26%   35.53%   +0.27%
==========================================
  Files         307      307
  Lines        8231     8236       +5
  Branches     1532     1535       +3
==========================================
+ Hits         2903     2927      +24
+ Misses       5328     5309      -19

Impacted Files
Coverage Δ

wherehows-web/app/utils/api/fetcher.ts
54.34% <66.66%> (+24.46%)
: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 a12b7df...0439ff4. Read the comment docs.


JSON output contains multiple fields with the same key

Hi,
it seems that the json output you are writing contains a dictionary with the same key multiple times. When parsing the file with jq some comments get lost because of the key overlap:
{
  "4.6" : "WARN",
  "4.6" : "WARN: [jboss/base-jdk:8]",
  "4.6" : "WARN: [postgres:10.3]"
}

becomes
{
  "4.6" : "WARN: [postgres:10.3]"
}

For reporting it would be nice if either the key "4.6" is only used once and is a dictionary itself or if the line is a list instead of a single key:
{
  "4.6": { "containers": [ "postgres:10.3", "jboss/base-jdk:8" ], "title": "Ensure HEALTHCHECK ...", "result": "WARN" }
}
{
 [ "id": "4.6", "result": "WARN", "text": "" ],
 [ "id": "4.6", "result": "WARN", "text": "[postgres:10.3]" ],
 [ "id": "4.6", "result": "WARN", "text": "[jboss/base-jd:8]" ],
}

Hi @makefu and thanks for reporting this, #314 and #306 both contains updates to the json output and I'll have a look at both those PRs as soon as possble and hopefully fix this issue thereafter.

@konstruktoid that is great to hear! i only quickly checked in the issues for json output and forgot to check the Pull Requests.
Thanks for your efforts!

Closing since #314 has been merged.


plog: init at 1.1.9

Description of changes
Motivation: required for https://github.com/NixOS/nixpkgs/pull/237099 which will be required for next OBS Studio release.
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[X] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/998

Result of nixpkgs-review pr 238806 run on aarch64-linux 1

2 packages built:

plog
plog.dev


ncurses.h: No such file or directory

Checklist

[X] I've looked through the issues and pull requests for similar reports

Describe your issue
I tried building my almost empty Rust + Cursive playground application, and failed:
$ cross build  --release                                                                                 ✔  26s 
warning: unused manifest key: target.arm-unknown-linux-gnueabihf.linker
warning: unused manifest key: target.powerpc-unknown-linux-gnu.linker
   Compiling signal-hook-registry v1.4.1
   Compiling num-traits v0.2.17
   Compiling getrandom v0.2.10
   Compiling enum-map v2.6.3
   Compiling time v0.3.29
   Compiling term_size v0.3.2
   Compiling crossbeam-channel v0.5.8
   Compiling ncurses v5.101.0
   Compiling enumset v1.1.3
error: failed to run custom build command for `ncurses v5.101.0`

Caused by:
  process didn't exit successfully: `/target/release/build/ncurses-3b76e5da4c5551fd/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=NCURSESW5_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=NCURSESW5_STATIC
  cargo:rerun-if-env-changed=NCURSESW5_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=NCURSESW_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=NCURSESW_STATIC
  cargo:rerun-if-env-changed=NCURSESW_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  cargo:rustc-link-lib=ncursesw
  OPT_LEVEL = Some("z")
  TARGET = Some("x86_64-unknown-linux-gnu")
  HOST = Some("x86_64-unknown-linux-gnu")
  cargo:rerun-if-env-changed=CC_x86_64-unknown-linux-gnu
  CC_x86_64-unknown-linux-gnu = None
  cargo:rerun-if-env-changed=CC_x86_64_unknown_linux_gnu
  CC_x86_64_unknown_linux_gnu = None
  cargo:rerun-if-env-changed=HOST_CC
  HOST_CC = None
  cargo:rerun-if-env-changed=CC
  CC = None
  cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
  CRATE_CC_NO_DEFAULTS = None
  DEBUG = Some("false")
  CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2")
  cargo:rerun-if-env-changed=CFLAGS_x86_64-unknown-linux-gnu
  CFLAGS_x86_64-unknown-linux-gnu = None
  cargo:rerun-if-env-changed=CFLAGS_x86_64_unknown_linux_gnu
  CFLAGS_x86_64_unknown_linux_gnu = None
  cargo:rerun-if-env-changed=HOST_CFLAGS
  HOST_CFLAGS = None
  cargo:rerun-if-env-changed=CFLAGS
  CFLAGS = None

  --- stderr
  /target/x86_64-unknown-linux-gnu/release/build/ncurses-e7af6b71caf2e572/out/chtype_size.c:6:10: fatal error: ncurses.h: No such file or directory
      6 | #include <ncurses.h>
        |          ^~~~~~~~~~~
  compilation terminated.
  thread 'main' panicked at /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ncurses-5.101.0/build.rs:105:5:
  assertion failed: command.status().expect(\"compilation failed\").success()
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error[E0463]: can't find crate for `enumset_derive`
   --> /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/enumset-1.1.3/src/lib.rs:199:9
    |
199 | pub use enumset_derive::EnumSetType;
    |         ^^^^^^^^^^^^^^ can't find crate

For more information about this error, try `rustc --explain E0463`.
error: could not compile `enumset` (lib) due to previous error

This error says I'm missng ncurses.h, but I'm not:
$ ls -alih /usr/include/*curses*                                                                                 ✔
1404502 -rw-r--r-- 1 root root 7,1K 23. Mai 22:02 /usr/include/cursesapp.h
1404503 -rw-r--r-- 1 root root  28K 23. Mai 22:02 /usr/include/cursesf.h
1404501 -rw-r--r-- 1 root root  99K 23. Mai 22:02 /usr/include/curses.h
1404504 -rw-r--r-- 1 root root  20K 23. Mai 22:02 /usr/include/cursesm.h
1404505 -rw-r--r-- 1 root root 8,6K 23. Mai 22:02 /usr/include/cursesp.h
1404506 -rw-r--r-- 1 root root  50K 23. Mai 22:02 /usr/include/cursesw.h
1404513 -rw-r--r-- 1 root root 4,1K 23. Mai 22:02 /usr/include/ncurses_dll.h
1404512 lrwxrwxrwx 1 root root    8 23. Mai 22:02 /usr/include/ncurses.h -> curses.h
  67121 -rw-r--r-- 1 root root  13K 27. Dez 2022  /usr/include/slcurses.h

What target(s) are you cross-compiling for?
powerpc-unknown-linux-gnu
Which operating system is the host (e.g computer cross is on) running?

[ ] macOS
[ ] Windows
[X] Linux / BSD
[ ] other OS (specify in description)

What architecture is the host?

[X] x86_64 / AMD64
[ ] arm32
[ ] arm64 (including Mac M1)

What container engine is cross using?

[ ] docker
[X] podman
[ ] other container engine (specify in description)

cross version
cross 0.2.5 (3c21f9e 2023-10-11)
Example
git clone https://gitlab.com/thomas351/rust-p2p-chat/
cd rust-p2p-chat
cross build --release

Gives the error message /target/x86_64-unknown-linux-gnu/release/build/ncurses-e7af6b71caf2e572/out/chtype_size.c:6:10: fatal error: ncurses.h: No such file or directory
Additional information / notes
The normal cargo build --release works fine.

Hi! First up, targeting powerpc-unknown-linux-gnu is getting trickier since it's deprecated and not supported by Ubuntu for libncurses-dev. Instead, you should probably use powerpc64le-unknown-linux-gnu
The main issue you're encountering stems from cross running in a container that doesnt include libncurses-dev. Installing it on your local system won't affect this isolated container.
To fix this, you'll want to set up a Cross.toml file in your project directory and add:
# Cross.toml
[build]
pre-build = [
    "dpkg --add-architecture $CROSS_DEB_ARCH",
    "apt-get update && apt-get install --assume-yes libncurses-dev:$CROSS_DEB_ARCH"
]

This will install the necessary library in the container for whichever target you're using, see [build]. That should make cross run --target powerpc64le-unknown-linux-gnu and cross run --target x86_64-unknown-linux-gnu work just fine.
As for powerpc-unknown-linux-gnu, your options are:

Utilize Debian's jessie repo to obtain the library. The wiki has more details.

Manually compile the library as a step in the pre-build and place it in /usr/powerpc-linux-gnu/lib.

Opt for a more commonly supported target like powerpc64le-unknown-linux-gnu.

If you have more questions, feel free to ask.

Thanks for the detailed explanation and the clear guide how to proceed, will try it next!
I'm unsure if powerpc64le is the right architecture for my target system, it's an OpenWRT device with a Freescale MPC85xx P1014 SoC, which I believe is a 32bit PowerPC architecture, but I'm not sure. I'll try with powerpc64le-unknown-linux-gnu in a few hours and report back on my results afterwards :)

Okey, so first result, the ncurses.h not found vanished, but it still fails, but I don't understand what the new error is trying to say:
$ cross build  --release --target powerpc64le-unknown-linux-gnu
...
error: failed to run custom build command for `ncurses v5.101.0`

Caused by:
  process didn't exit successfully: `/target/release/build/ncurses-3b76e5da4c5551fd/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=NCURSESW5_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_powerpc64le-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_powerpc64le_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_ALLOW_CROSS
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS
  cargo:rerun-if-env-changed=PKG_CONFIG_powerpc64le-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_powerpc64le_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=NCURSESW5_STATIC
  cargo:rerun-if-env-changed=NCURSESW5_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_powerpc64le-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_powerpc64le_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_powerpc64le-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_powerpc64le_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_powerpc64le-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_powerpc64le_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=NCURSESW_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_powerpc64le-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_powerpc64le_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_ALLOW_CROSS
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS
  cargo:rerun-if-env-changed=PKG_CONFIG_powerpc64le-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_powerpc64le_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=NCURSESW_STATIC
  cargo:rerun-if-env-changed=NCURSESW_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_powerpc64le-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_powerpc64le_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_powerpc64le-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_powerpc64le_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_powerpc64le-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_powerpc64le_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=SYSROOT
  cargo:rerun-if-env-changed=NCURSESW_STATIC
  cargo:rerun-if-env-changed=NCURSESW_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rustc-link-lib=ncursesw
  cargo:rustc-link-lib=tinfo
  cargo:rustc-link-arg=-Wl,-Bsymbolic-functions
  cargo:rerun-if-env-changed=PKG_CONFIG_powerpc64le-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_powerpc64le_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=NCURSESW_STATIC
  cargo:rerun-if-env-changed=NCURSESW_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_powerpc64le-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_powerpc64le_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_powerpc64le-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_powerpc64le_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_powerpc64le-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_powerpc64le_unknown_linux_gnu
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  OPT_LEVEL = Some("z")
  TARGET = Some("powerpc64le-unknown-linux-gnu")
  HOST = Some("x86_64-unknown-linux-gnu")
  cargo:rerun-if-env-changed=CC_powerpc64le-unknown-linux-gnu
  CC_powerpc64le-unknown-linux-gnu = None
  cargo:rerun-if-env-changed=CC_powerpc64le_unknown_linux_gnu
  CC_powerpc64le_unknown_linux_gnu = Some("powerpc64le-linux-gnu-gcc")
  cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
  CRATE_CC_NO_DEFAULTS = None
  DEBUG = Some("false")
  CARGO_CFG_TARGET_FEATURE = None
  cargo:rerun-if-env-changed=CFLAGS_powerpc64le-unknown-linux-gnu
  CFLAGS_powerpc64le-unknown-linux-gnu = None
  cargo:rerun-if-env-changed=CFLAGS_powerpc64le_unknown_linux_gnu
  CFLAGS_powerpc64le_unknown_linux_gnu = None
  cargo:rerun-if-env-changed=TARGET_CFLAGS
  TARGET_CFLAGS = None
  cargo:rerun-if-env-changed=CFLAGS
  CFLAGS = None

  --- stderr
  thread 'main' panicked at /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ncurses-5.101.0/build.rs:107:10:
  /target/powerpc64le-unknown-linux-gnu/release/build/ncurses-e10af3e277872a3d/out/chtype_size failed: Os { code: 8, kind: Uncategorized, message: "Exec format error" }
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...

okey, so next I've tried this:
CROSS_CONTAINER_ENGINE=podman cross build --target x86_64-unknown-linux-gnu --release

which worked fine. So my problems are related to the lesser used cpu architecture targets...

okey, so now I found that if I replace my code which was the most basic sample from the Cursive CUI library with a simple println!("hello") I can compile it to  just fine using cross build --release --target powerpc-unknown-linux-gnu.
So the problem seem to be specific to ncurses (or it's dependencies?) which are used by the Cursive CUI library when compiling for a powerpc archetecture.

okey, but copying the resulting binary to my openwrt device and running it there, doesn't print the string passed to the println macro, but instead:

-ash: rust-p2p-chat_ppc: not found

ah, so after reading this: https://stackoverflow.com/questions/31385121/elf-file-exists-in-usr-bin-but-turns-out-ash-file-not-found
I believe I got differing versions of libc between the build container and the openwrt device, and the build has dynamically linked to that libc present during building.

The error you're getting when building ncurses is the same as https://github.com/jeaye/ncurses-rs/issues/184
I'd say what ncurses-rs is doing here is a bit iffy. It compiles using the target cc, and tries to run it.It does then seem like this is not a cross issue, but a general cross-compilation issue for the ncurses crate.
I do know a way to fix this for users of cross (and more) maybe, utilize the runner thats been specified here.
Also, you are correct, MPC8540 is powerpc, not ppc64el

There we go, adding
[patch.crates-io]
ncurses = { git = "https://github.com/Emilgardis/ncurses-rs", branch = "fix-runner" }

should fix the issue. Interestingly, I couldn't reproduce the exec error on windows, not sure why :3
as for powerpc, I'm not able to use debian ports nor jessie to install libncurses-dev, something in the repo is fundamentally broken. I'm not sure how to proceed except for maybe optint to not use ncurses and instead use something rust native like ratatui

wow, amazing how much effort you put into solving anonymous peoples problems, thank you for being an amazing human beeing ❤
For getting to a running binary faster I already downgraded my sample from using Cursive (CUI lib) to a only std rust using prtinln!("hello world") - but still failed because of the very old libc version on my OpenWRT router.
Can you help me with that also? Should I create a separate issue for this? I've so far documented my research on that problem here: https://users.rust-lang.org/t/compile-rust-for-powerpc-openwrt-device-with-libc-1-2-3/101147/


Looping additional key-value pairs

I'm settting some variables (redis data) in the additional key-value pair. I'm able to access those like $context.authorizer.key  in API gateway.
But If I have hundreds of key-value pair then how can I loop it so that it can be pass it to the endpoint.
https://github.com/awslabs/aws-apigateway-lambda-authorizer-blueprints/blob/4920d93a5f67bb445be57b8e1aa88967a036e0e3/blueprints/nodejs/index.js#L66

Hi, I have updated the answer here:
https://stackoverflow.com/questions/46934755/how-to-loop-all-the-keys-in-context-authorizer-in-aws-api-gateway
Hopefully, this should resolve the issue.
Thanks!


Concept tree not showing narrowers

The expandable Concept tree on many vocab's home page doesn't expand showing narrower concepts, e.g.
https://gsq-prez.dev.kurrawong.ai/v/vocab/defn:address-classes
which should allow Thoroughfare to be expanded, as per the data shown on the Concept's page:
https://gsq-prez.dev.kurrawong.ai/v/vocab/defn:address-classes/ddrss-clsss:thoroughfare

I think the hierarchy only works with broeder, not narrower, e.g. for Borehole Status:
https://gsq-prez.dev.kurrawong.ai/v/vocab/def:borehole-status
see
https://gsq-prez.dev.kurrawong.ai/v/vocab/def:borehole-status/brhl-stts:drilling-completed which indicates its braoder term
We need the UI tree to understand narrower as well as, or in addition to, broader

Upon inspection of both https://gsq-prez.dev.kurrawong.ai/v/vocab/defn:address-classes and https://gsq-prez.dev.kurrawong.ai/v/vocab/defn:geocode-types, it looks like the narrower concepts aren't being shown under the expanded parent concept as those narrower concepts are also top concepts. For example (shortened for simplicity):
<https://linked.data.gov.au/def/address-classes/thoroughfare> dcterms:identifier "ddrss-clsss:thoroughfare"^^prez:identifier ;
    skos:inScheme <https://linked.data.gov.au/def/address-classes> ;
    skos:narrower <https://linked.data.gov.au/def/address-classes/street> ;
    skos:prefLabel "Thoroughfare"@en ;
.

<https://linked.data.gov.au/def/address-classes> a skos:ConceptScheme ;
    dcterms:identifier "address-classes"^^xsd:token,
        "defn:address-classes"^^prez:identifier,
        "def:address-classes"^^prez:slug ;
    skos:hasTopConcept <https://linked.data.gov.au/def/address-classes/street>,
        <https://linked.data.gov.au/def/address-classes/thoroughfare> ;
    skos:prefLabel "Address Classes"@en ;
    prez:link "/v/vocab/defn:address-classes" ;
.

Where "street: is a narrower concept of "thoroughfare", but "street" is also a top concept.
Is this a valid scenario where narrower concepts can also be top concepts?


Fixes broken paths

Quick fix for broken paths in readme file.

Closing this PR since the issue has been addressed via #66


Incorrect Documentation

There is an incorrect value in here:
where it says:

The title configuration is passed into the options.tooltips namespace. The global options for the chart tooltips is defined in Chart.defaults.global.title.

I think it should be Chart.default.global.tooltip

Fixed in f71f525


chore: port leanprover-community/mathlib#18861

I forgot to put some required to_additives in Lean3, I am currently backporting this change in leanprover-community/mathlib#19168.

I'll do option 2 when I get to a computer (~4hrs). It's still unsettling that scott is the bot for this repo.

I ended up not getting to a computer in time, so I copied the aligns. This should be ready to go.

bors r+