Indicate that StartParameter.getProjectCacheDir is not a directory that plugins can write to

Issue type
Inaccurate docs
Problem description
https://docs.gradle.org/current/javadoc/org/gradle/StartParameter.html#getProjectCacheDir-- seems to suggest that it is a reasonable place to put gradle plugin data that needs to survive buildDir removals.
Context (optional)
No response
Page with the problem
https://docs.gradle.org/current/javadoc/org/gradle/StartParameter.html#getProjectCacheDir--

This issue is a good choice for first-time contributors to Gradle, it is actionable and ready for contribution.
See CONTRIBUTING.md for more information.

The documentation should indicate that the project cache dir is for Gradle internals, something like:

Sets the project's cache location. Set to null to use the default location. Note that this folder is reserved for Gradle internal state and plugins are not expected to write anything there.


Separate History

Hello! I need to implement separate history. I am creating app for learners, who can use the same PC and browser.
I think to implement by the with hash from url, at format:
https://www.example.com/example.pdf?v133-279
Every learner has his own version (?v133-279). Is it possible to generate hash fingerprint at url?

It's unfortunately not really clear what you mean by "separate history", given the overall lack of details here.
Please keep in mind that the default viewer is created primarily for Firefox, and while it's obviously possible to extend it in various ways we however can't provide detailed help/support for that.
When opening an issue, please provide all of the information requested in https://github.com/mozilla/pdf.js/blob/master/.github/ISSUE_TEMPLATE.md and please note https://github.com/mozilla/pdf.js/blob/master/.github/CONTRIBUTING.md (emphasis mine):

If you are developing a custom solution, first check the examples at https://github.com/mozilla/pdf.js#learning and search existing issues. If this does not help, please prepare a short well-documented example that demonstrates the problem and make it accessible online on your website, JS Bin, GitHub, etc. before opening a new issue or contacting us in the Matrix room -- keep in mind that just code snippets won't help us troubleshoot the problem.


Release 1.11.0

Because there is a version conflict with previously retracted versions from npm, we will do a major release skip to the first available number: 1.11.0
npm show --json

"@eeacms/volto-eea-design-system": {
    "_id": "<EMAIL_ADDRESS>    "_rev": "82-684d55a328606a23afc1b323cea36943",
    "time": {
      "created": "2022-04-08T13:28:34.409Z",
      "1.0.0": "2021-11-17T19:39:52.655Z",
      "modified": "2023-04-10T10:10:11.486Z",
      "1.1.0": "2021-12-09T17:32:03.153Z",
      "1.1.1": "2021-12-16T14:02:28.823Z",
      "1.1.2": "2021-12-18T17:27:51.016Z",
      "1.1.3": "2021-12-22T13:25:51.192Z",
      "1.1.4": "2022-01-03T17:14:17.900Z",
      "1.2.0": "2022-02-14T19:55:28.911Z",
      "1.3.0": "2022-02-25T18:14:13.869Z",
      "1.3.1": "2022-02-25T20:03:24.609Z",
      "1.4.0": "2022-03-01T20:03:47.045Z",
      "1.5.0": "2022-03-08T20:16:24.539Z",
      "1.6.0": "2022-03-11T18:08:39.724Z",
      "1.7.0": "2022-03-15T18:49:21.389Z",
      "1.8.0": "2022-03-18T18:33:45.575Z",
      "1.9.0": "2022-03-25T19:47:39.055Z",
      "1.10.0": "2022-04-04T19:12:13.666Z",
      "0.2.1": "2022-04-08T13:28:34.756Z",
      "0.2.2": "2022-04-22T13:31:35.401Z",
      "0.2.3": "2022-04-29T17:16:55.777Z",
      "0.2.4": "2022-05-13T07:53:28.531Z",
      "0.3.0": "2022-05-17T20:44:41.800Z",
      "0.3.1": "2022-05-19T20:47:01.647Z",
      "0.4.0": "2022-06-01T08:09:55.315Z",
      "0.4.1": "2022-06-02T16:36:52.232Z",
      "0.4.2": "2022-06-02T19:23:33.668Z",
      "0.4.3": "2022-06-03T19:34:51.024Z",
      "0.4.4": "2022-06-08T09:06:46.124Z",
      "0.4.5": "2022-06-08T11:19:54.376Z",
      "0.5.0": "2022-06-10T21:08:11.756Z",
      "0.5.1": "2022-06-13T20:32:13.540Z",
      "0.5.2": "2022-06-14T06:41:36.298Z",
      "0.5.3": "2022-06-15T21:05:33.554Z",
      "0.5.4": "2022-06-16T16:20:38.916Z",
      "0.5.5": "2022-06-23T07:22:34.631Z",
      "0.6.0": "2022-07-01T13:07:41.447Z",
      "0.6.1": "2022-07-01T14:11:04.671Z",
      "0.6.5": "2022-07-06T12:40:51.326Z",
      "0.7.0": "2022-08-01T08:42:21.745Z",
      "0.7.1": "2022-08-01T12:47:17.426Z",
      "0.7.2": "2022-08-03T10:03:08.958Z",
      "0.7.3": "2022-08-04T09:06:07.592Z",
      "0.7.5": "2022-08-11T18:05:18.208Z",
      "0.7.6": "2022-08-15T16:46:54.666Z",
      "0.8.0": "2022-08-20T18:38:54.223Z",
      "0.8.1": "2022-08-26T16:08:44.893Z",
      "0.9.0": "2022-09-19T17:18:40.214Z",
      "0.9.1": "2022-09-27T16:39:21.040Z",
      "0.9.2": "2022-09-27T18:41:30.852Z",
      "0.9.3": "2022-10-04T14:04:02.387Z",
      "0.9.4": "2022-10-19T08:21:23.867Z",
      "0.9.5": "2022-10-20T10:48:00.486Z",
      "1.0.0-alpha.1": "2022-10-20T17:34:45.608Z",
      "1.0.0-alpha.2": "2022-10-28T12:40:52.764Z",
      "1.0.0-alpha.3": "2022-11-16T16:41:59.298Z",
      "1.0.0-alpha.4": "2022-11-22T19:12:58.480Z",
      "1.0.0-alpha.5": "2022-11-29T18:36:18.287Z",
      "1.0.0-alpha.6": "2022-12-07T11:48:37.680Z",
      "1.0.0-alpha.7": "2022-12-16T14:07:51.048Z",
      "0.9.6": "2022-12-16T19:30:14.951Z",
      "1.0.0-alpha.8": "2022-12-23T20:00:48.257Z",
      "1.0.0-alpha.9": "2022-12-28T17:26:47.086Z",
      "1.0.0-alpha.10": "2023-01-13T10:32:59.171Z",
      "1.0.0-alpha.11": "2023-01-17T21:09:34.289Z",
      "1.0.0-alpha.12": "2023-01-24T18:11:43.943Z",
      "1.0.0-alpha.13": "2023-01-27T16:35:05.786Z",
      "1.0.0-alpha.13.1": "2023-01-30T07:57:23.133Z",
      "1.0.0-alpha.14": "2023-01-30T17:33:27.945Z",
      "1.0.0-alpha.15": "2023-02-07T22:15:40.326Z",
      "1.0.0-beta.1": "2023-02-09T18:31:47.515Z",
      "1.0.0-beta.2": "2023-02-13T17:56:07.630Z",
      "1.0.0-beta.3": "2023-02-21T21:07:37.305Z",
      "1.0.0-beta.4": "2023-03-01T10:27:02.957Z",
      "1.0.0-beta.5": "2023-03-07T19:09:24.787Z",
      "1.0.0-beta.6": "2023-03-10T21:41:40.254Z",
      "1.0.1": "2023-03-12T22:26:39.561Z",
      "1.0.2": "2023-03-14T18:17:56.155Z",
      "1.0.3": "2023-03-24T20:20:50.940Z",
      "1.0.4": "2023-03-27T19:16:04.763Z",
      "1.0.5": "2023-03-28T13:05:09.161Z",
      "1.0.6": "2023-03-29T18:31:37.478Z",
      "1.0.7": "2023-04-10T10:10:11.283Z"
    },
...


Fallback to threshold if confirmationsRequired of transaction is null

Summary
We validate fetched multisig transactions to ensure they are as expected. The MultisigTransactionSchema expected confirmationsRequired to be a number but it can also be null.
This changes the validation to also expect nullish values and default to null is no number is returned.
Changes

Change MultisigTransactionSchema['confirmationsRequired'] to expect a number or nullish values, defaulting to null
Update instances where confirmationsRequired is references, falling back to the threshold of the Safe
Add relative test coverage

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.001%) to 92.839%

Files with Coverage Reduction
New Missed Lines
%

src/routes/transactions/entities/tests/human-description.builder.ts
1
80.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.001%

Covered Lines:
7109

Relevant Lines:
7364

💛  - Coveralls


Menus

Functions for building menus. Intended for use both for Toolbar menus and NavigationView menus.

Are there any updates on this? The changes appear to be approved


Popup overlaps pum window when enabling border option on pum.vim

Problem
Popup overlaps pum window when enabling border option on pum.vim.

Options
Enable pum.vim border.
call pum#set_option({ 'border': 'single' })

Environments

neovim: https://github.com/neovim/neovim/tree/2b252430aa9ef52de7da733e2c0221c97111bce2
ddc.vim: https://github.com/Shougo/ddc.vim/tree/4be33d4e5d0c62da05b8f28c34c5ebc2d40b0d62
pum.vim: https://github.com/Shougo/pum.vim/tree/9c94a23eb575fd880eedd428711799377789eb6c
denops-popup-preview.vim: https://github.com/matsui54/denops-popup-preview.vim/tree/46e8f044b4bf4cfb255a7adb1fda4dd708a7b02f

Thanks for great plugin!

Thanks for reporting! Please wait until the fix in pum.vim is merged.

It's merged. Please update pum.vim.

Thank you for the quick fix!
I have confirmed that the problem has been resolved in my environment.


Revert rename of container disk entrypoint

What this PR does / why we need it:
Revert rename of container disk entrypoint, to not break compatibility for registry disks.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

NONE

In a follow-up PR we can add this:
diff --git a/cmd/container-disk-v1alpha/BUILD.bazel b/cmd/container-disk-v1alpha/BUILD.bazel
index 1c4f7423a..009678067 100644
--- a/cmd/container-disk-v1alpha/BUILD.bazel
+++ b/cmd/container-disk-v1alpha/BUILD.bazel
@@ -21,6 +21,7 @@ container_image(
     entrypoint = ["/entry-point.sh"],
     files = ["entry-point.sh"],
     visibility = ["//visibility:public"],
+    tars = [":diskdir_tar"],
 )

 genrule(
@@ -30,6 +31,19 @@ genrule(
     cmd = "mkdir disk && cat $(location @alpine_image//file) > $@",
 )

+genrule(
+    name = "diskdir",
+    outs = [".empty"],
+    cmd = "touch $@",
+)
+
+pkg_tar(
+    name = "diskdir_tar",
+    srcs = [":diskdir"],
+    mode = "0644",
+    package_dir = "disk",
+)
+
 pkg_tar(
     name = "alpine-iso-tar",
     srcs = [":alpine-iso"],

to keep the empty "/disk" directory.


R: 4.3.1 -> 4.3.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/r/versions.
meta.description for R is: Free software environment for statistical computing and graphics
meta.homepage for R is: http://www.r-project.org/
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 4.3.2 with grep in /nix/store/b2mnb9lq081fk3w2nz3yy217qap5qsgj-R-4.3.2
found 4.3.2 in filename of file in /nix/store/b2mnb9lq081fk3w2nz3yy217qap5qsgj-R-4.3.2

Rebuild report (if merged into master) (click to expand)

42 total rebuild path(s)

42 package rebuild(s)

First fifty rebuilds by attrpath
R
cantor
diffoscope
golden-cheetah-bin
labplot
libsForQt5.cantor
plasma5Packages.cantor
postgresql12JitPackages.plr
postgresql12Packages.plr
postgresql13JitPackages.plr
postgresql13Packages.plr
postgresql14JitPackages.plr
postgresql14Packages.plr
postgresql15JitPackages.plr
postgresql15Packages.plr
postgresql16JitPackages.plr
postgresql16Packages.plr
postgresqlJitPackages.plr
postgresqlPackages.plr
python310Packages.cnvkit
python310Packages.nbdev
python310Packages.radian
python310Packages.rchitect
python310Packages.rpy2
python311Packages.cnvkit
python311Packages.nbdev
python311Packages.radian
python311Packages.rchitect
python311Packages.rpy2
quarto
rstudio
rstudio-server
rstudioServerWrapper
rstudioWrapper
sage
sageWithDoc
spark
spark3
spark_3_2
spark_3_3
spark_3_4
tests.pkg-config.defaultPkgConfigPackages.libR

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/b2mnb9lq081fk3w2nz3yy217qap5qsgj-R-4.3.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A R https://github.com/r-ryantm/nixpkgs/archive/3c7be3591399c6f19e50fb3d9d688648ada2eb65.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/3c7be3591399c6f19e50fb3d9d688648ada2eb65#R

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/b2mnb9lq081fk3w2nz3yy217qap5qsgj-R-4.3.2
ls -la /nix/store/b2mnb9lq081fk3w2nz3yy217qap5qsgj-R-4.3.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review took longer than 45m and timed out

Maintainer pings
cc @jbedo @timokau @omasanori @7c6f434c @collares for testing.

@ofborg build sageWithDocs

@ofborg build sageWithDoc


mud v2 QA checklist

[ ] npm create and build/deploy on windows
[ ] npm create and build/deploy on linux
[ ] build/deploy app with next.js (i.e. webpack instead of vite)
[ ] deploy to various testnets

[ ] eth goerli/sepolia (non-rollup)
[ ] op testnet and/or base testnet (make sure deploy works with eip-1559)

from discord:

We have been trying to test MUD (v1 and v2) on substrate based EVMs (https://github.com/paritytech/frontier) such as Moonbeam. Contracts deploy fine, but when we call functions on the contracts (executeTyped on IncrementSystem for v1, installRootModule on World for v2) we get exceeds block gas limit. This happens with frontier template nodes, moonbeam nodes and on moonbase alpha testnet (https://moonbase.moonscan.io/tx/0xd0d23e1712c0ee9d64589fa4586d74f6da6a48014ccf013446b3b2c0794ea2e4). Any ideas? Has anyone else attempted to use MUD on a Substrate EVM chain? Thanks!

I did a bit more testing yesterday, and I did get installRootModule to work on moonbase alpha testnet. Also, digging into a Moonbeam dev node, it wasn't an exceeds block gas limit error, but  something else happening that shows a similar error during the deploy-v2 call but if I make the same call via remix it works 🤷
I was still getting "exceeds block gas limit" when running against a frontier template node, but we will dig deeper into this on the frontier side this week. If I find anything useful I will update you. Thanks!


Segementation Fault When Reading File With Java App

Bug Description
Reading a file in a Java app (running in a VS Code debugger) triggers a segmentation fault:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f33526e66aa, pid=127287, tid=127295
#
# JRE version: OpenJDK Runtime Environment (<IP_ADDRESS>+1) (build <IP_ADDRESS>+1-Ubuntu-0ubuntu122.04)
# Java VM: OpenJDK 64-Bit Server VM (<IP_ADDRESS>+1-Ubuntu-0ubuntu122.04, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  [libc.so.6+0xe66aa]  readdir64+0x2a
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# hs_err_pid127287.log
#
# If you would like to submit a bug report, please visit:
#   Unknown
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

The config in use contains the following stanza:
{
    "feature": {
        "fs": {
          "mode": "read",
          "read_only": [ "/etc/*" ]
        }
    }
}

Steps to Reproduce

configure and enable mirrord
start a debugging session

Backtrace
Current thread (0x00007f3344046e10):  JavaThread "main" [_thread_in_native, id=127295, stack(0x00007f3350f00000,0x00007f3351000000)]

Stack: [0x00007f3350f00000,0x00007f3351000000],  sp=0x00007f3350ffdfd0,  free space=1015k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libc.so.6+0xe66aa]  readdir64+0x2a

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  sun.nio.fs.UnixNativeDispatcher.readdir(J)[B+0<EMAIL_ADDRESS>j  sun.nio.fs.UnixDirectoryStream$UnixDirectoryIterator.readNextEntry()Ljava/nio/file/Path;+52<EMAIL_ADDRESS>j  sun.nio.fs.UnixDirectoryStream$UnixDirectoryIterator.hasNext()Z+16<EMAIL_ADDRESS>j  java.nio.file.FileTreeWalker.next()Ljava/nio/file/FileTreeWalker$Event;+37<EMAIL_ADDRESS>j  java.nio.file.Files.walkFileTree(Ljava/nio/file/Path;Ljava/util/Set;ILjava/nio/file/FileVisitor;)Ljava/nio/file/Path;+255<EMAIL_ADDRESS>j  java.nio.file.Files.walkFileTree(Ljava/nio/file/Path;Ljava/nio/file/FileVisitor;)Ljava/nio/file/Path;+11<EMAIL_ADDRESS>[...more]

Relevant Logs
No response
Your operating system and version
Ubuntu 22.04.3 LTS
Local process
Java debugger in VS Code
Local process version
No response
Additional Info
For additional context:

The location that is accessed is provided by the Vault agent. So it's not located on the main file system.
Listing all files in "/" returns results form the local system.
Listing all files in "/etc" causes a crash.

We found the source of the bug and fixed it in #2003
All should work with the next release :)

I gave it a try and the issue is resolved. Thanks @Razz4780 and @eyalb181 !


Unify k8s ip pool (restore cluster-cidr to previous value)

Fixes #741
The cluster-cidr expected by the K8s etcd manifests is <IP_ADDRESS>/16 (the default if no cluster-cidr) is specified.  A value of <IP_ADDRESS>/16 was explicitly set which broke accessing a k8s service when using the etcd manifests.  This change restores that value to the default (though sets it explicitly) and changes the kdd manifests to match that value.

These commits need squashing but I left them separate in case we didn't want to make this change to v2.1 and v2.0 but I don't expect that to be the case.

Can you update the description of this to explain how this fixes #741 ? It's not clear to me why this is  needed.

@djosborne PTAL

@tmjd So from what I understand, there's places / values for this field:

The default  --cluster-cidr flag
The user-overridden --cluster-cidr flag
The value of the calico pool.

A little history - I think 2 was originally set to <IP_ADDRESS>/16 because ever since calico's first container implementation, that was the default pool in Calico. So we figured "modify kubernetes to use our default pool" was the way to go. But in actuality, modifiying Calico to use Kubernetes default is more practical.
So I'm concerned that we're changing 3 to be the value we chose for 2 for our demos, but in reality both should match whatever 1 is.
What is the value for 1? Does it depend on the deployment method? What does kubeadm set it by default? Is it ever random?

@djosborne and I chatted so here is some info to leave a paper trail
The default in kubernetes when no --cluster-cidr is specified is <IP_ADDRESS>/16.
If using kubeadm the default when no --pod-network-cidr is specified is to start the kubernetes components without specifying a --cluster-cidr and therefore results in <IP_ADDRESS>/16.
So I believe with the change here we are matching our default IP Pool with the default --cluster-cidr for kubernetes and kubeadm.  We are now explicitly setting --cluster-cidr which should protect us from breakage in the future if the default changes.

@djosborne PTAL

Ok So I double checked and my memory certainly seems incorrect.  I removed --cluster-cidr from all the k8s components and did not have functioning services with that setup.  So It does look like the cluster-cidr is just unset when if it is not specified.

I still think this is the correct change at this time since we had been using <IP_ADDRESS>/16 for our k8s etcd manifests.

@caseydavenport knows the right path here. I think the only reason I involved myself was he was OOO. Now that he's back, I think it's best to let him review this and clear the confusion.

A quick summary of where I've gotten to:
I don't think we should be applying this change to v2.0 or v2.1 KDD manifests.  Those are set to <IP_ADDRESS>/16 for a good reason - compatibility with the default flannel self-hosted manifest (since they provide policy only and need flannel or something else for networking).
In v2.2 (and master) the KDD manifest now includes routing, which means that by default it isn't meant to use with the kube-flannel manifest*, and so it should be OK to adjust the cluster-cidr to match what our etcd based manifests (also policy+routing) have used for a long time.
To be clear, the reason for unifying the value used for etcd+kdd is simply so that they both work on our vagrant guide, which sets --cluster-cidr=<IP_ADDRESS>/16.
This change is related to, and will need to be considered when addressing https://github.com/projectcalico/calico/issues/750.
* For interested readers, see the Canal manifest for the recommended all-in-one combination of Calico + flannel

Once the v2.1 and v2.0 stuff is backed out then I think this is good to merge.

LGTM


Don't recommend deprecated xvfb-run -a

-a is deprecated:
-a        --auto-servernum          try to get a free server number, starting at
                                    --server-num (deprecated, use --auto-display
                                    instead)
-d        --auto-display            use the X server to find a display number
                                    automatically

and can cause problems. See https://github.com/plotly/orca/issues/239#issuecomment-561553654

Thank you @micheljung for reporting this. It does seem like -a is deprecated in recent version of xvfb-run but it hasn't made its way into Ubuntu. Even in version 20.04 I get:
xvfb-run: usage error: need a command to run

Usage: xvfb-run [OPTION ...] COMMAND
Run COMMAND (usually an X client) in a virtual X server environment.
Options:
-a        --auto-servernum          try to get a free server number, starting at
                                    --server-num
-e FILE   --error-file=FILE         file used to store xauth errors and Xvfb
                                    output (default: /dev/null)
-f FILE   --auth-file=FILE          file used to store auth cookie
                                    (default: ./.Xauthority)
-h        --help                    display this usage message and exit
-n NUM    --server-num=NUM          server number to use (default: 99)
-l        --listen-tcp              enable TCP port listening in the X server
-p PROTO  --xauth-protocol=PROTO    X authority protocol name to use
                                    (default: xauth command's default)
-s ARGS   --server-args=ARGS        arguments (other than server number and
                                    "-nolisten tcp") to pass to the Xvfb server
                                    (default: "-screen 0 1280x1024x24")

I'm curious to know whether you installed xvfb-run via your distro's package manger? If so, what distro/version are you using?

After xvfb-run --version didn't exist I gave up looking for its version :) We're on RHEL7. I'll try to gather some more info tomorrow.

We're on RHEL7. I'll try to gather some more info tomorrow.

Good to know :) I am also using a more recent version like you are.

After xvfb-run --version didn't exist I gave up looking for its version :)

I understand! It's a weird omission on their part. It looks like xvfb-run is a one file project. Here's how it's packaged in NixOS.
Anyway, in your PR just mention -d is recommended on newer versions. I would keep mentioning -a for all the Ubuntu users out there who may not get updated for a while.
Thanks again @micheljung

note that xvfb-run was forked from Debian in 2008, and this '-d' thing was added in the Fedora fork 4y ago...


Update Hooks to Foundry VTT 0.8.9

All of the hooks are now properly documented in foundry.js

Already done in #1154


Installing color-picker failed

Whenever I try installing this, or any other package, this is what comes up:
Installing<EMAIL_ADDRESS>failed.
gyp info it worked if it ends with ok
gyp info using<EMAIL_ADDRESS>gyp info using<EMAIL_ADDRESS>| darwin | x64
gyp http GET https://atom.io/download/electron/v2.0.4/iojs-v2.0.4.tar.gz
gyp WARN install got an error, rolling back install
gyp ERR! install error
gyp ERR! stack Error: self signed certificate in certificate chain
gyp ERR! stack     at Error (native)
gyp ERR! stack     at TLSSocket. (_tls_wrap.js:1079:38)
gyp ERR! stack     at emitNone (events.js:86:13)
gyp ERR! stack     at TLSSocket.emit (events.js:185:7)
gyp ERR! stack     at TLSSocket._finishInit (_tls_wrap.js:603:8)
gyp ERR! stack     at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:433:38)
gyp ERR! System Darwin 16.0.0
gyp ERR! command "/private/var/folders/8r/8n4j2jfn56x40y5yq_6msqdm0000gn/T/AppTranslocation/2F28CFCC-BD1F-4FF3-95A6-3324FCB6317D/d/Atom.app/Contents/Resources/app/apm/bin/node" "/private/var/folders/8r/8n4j2jfn56x40y5yq_6msqdm0000gn/T/AppTranslocation/2F28CFCC-BD1F-4FF3-95A6-3324FCB6317D/d/Atom.app/Contents/Resources/app/apm/node_modules/node-gyp/bin/node-gyp.js" "install" "--runtime=electron" "--target=2.0.4" "--dist-url=https://atom.io/download/electron" "--arch=x64" "--ensure"
gyp ERR! cwd /Users/Michelle/.atom
gyp ERR! node -v v6.9.5
gyp ERR! node-gyp -v v3.4.0
gyp ERR! not ok
What should I do? It's driving me crazy.
My atom version is 1.28.1 on a mac OS Sierra

I can install other packages, but not this one.
Atom version: 1.39.1 Computer: macOS Mojave 10.14.5
This color picker works for OS X: https://github.com/gregerolsson/native-color-picker
0 info it worked if it ends with ok
1 verbose cli [ '/Applications/Atom.app/Contents/Resources/app/apm/bin/node',
1 verbose cli   '/Applications/Atom.app/Contents/Resources/app/apm/node_modules/npm/bin/npm-cli.js',
1 verbose cli   '--globalconfig',
1 verbose cli   '/Users/tshutty/.atom/.apm/.apmrc',
1 verbose cli   '--userconfig',
1 verbose cli   '/Users/tshutty/.atom/.apmrc',
1 verbose cli   'install',
1 verbose cli   'https://www.atom.io/api/packages/an-color-picker/versions/1.0.2/tarball',
1 verbose cli   '--runtime=electron',
1 verbose cli   '--target=3.1.10',
1 verbose cli   '--dist-url=https://atom.io/download/electron',
1 verbose cli   '--arch=x64',
1 verbose cli   '--global-style' ]
2 info using<EMAIL_ADDRESS>3 info using<EMAIL_ADDRESS>4 verbose npm-session f937118a84506701
5 silly install loadCurrentTree
6 silly install readLocalPackageData
7 http fetch GET 400 https://www.atom.io/api/packages/an-color-picker/versions/1.0.2/tarball 385ms
8 silly fetchPackageMetaData error for https://www.atom.io/api/packages/an-color-picker/versions/1.0.2/tarball 400 Bad Request: https://www.atom.io/api/packages/an-color-picker/versions/1.0.2/tarball
9 timing stage:rollbackFailedOptional Completed in 3ms
10 timing stage:runTopLevelLifecycles Completed in 538ms
11 verbose stack Error: 400 Bad Request: https://www.atom.io/api/packages/an-color-picker/versions/1.0.2/tarball
11 verbose stack     at fetch.then.res (/Applications/Atom.app/Contents/Resources/app/apm/node_modules/npm/node_modules/pacote/lib/fetchers/registry/fetch.js:42:19)
11 verbose stack     at tryCatcher (/Applications/Atom.app/Contents/Resources/app/apm/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23)
11 verbose stack     at Promise._settlePromiseFromHandler (/Applications/Atom.app/Contents/Resources/app/apm/node_modules/npm/node_modules/bluebird/js/release/promise.js:512:31)
11 verbose stack     at Promise._settlePromise (/Applications/Atom.app/Contents/Resources/app/apm/node_modules/npm/node_modules/bluebird/js/release/promise.js:569:18)
11 verbose stack     at Promise._settlePromise0 (/Applications/Atom.app/Contents/Resources/app/apm/node_modules/npm/node_modules/bluebird/js/release/promise.js:614:10)
11 verbose stack     at Promise._settlePromises (/Applications/Atom.app/Contents/Resources/app/apm/node_modules/npm/node_modules/bluebird/js/release/promise.js:693:18)
11 verbose stack     at Async._drainQueue (/Applications/Atom.app/Contents/Resources/app/apm/node_modules/npm/node_modules/bluebird/js/release/async.js:133:16)
11 verbose stack     at Async._drainQueues (/Applications/Atom.app/Contents/Resources/app/apm/node_modules/npm/node_modules/bluebird/js/release/async.js:143:10)
11 verbose stack     at Immediate.Async.drainQueues (/Applications/Atom.app/Contents/Resources/app/apm/node_modules/npm/node_modules/bluebird/js/release/async.js:17:14)
11 verbose stack     at runCallback (timers.js:789:20)
11 verbose stack     at tryOnImmediate (timers.js:751:5)
11 verbose stack     at processImmediate [as _immediateCallback] (timers.js:722:5)
12 verbose cwd /private/var/folders/n1/h5y3tbd13731m4x6vxlwxpdc0000gp/T/apm-install-dir-119630-4412-253x81.f5c1xj
13 verbose Darwin 18.6.0
14 verbose argv "/Applications/Atom.app/Contents/Resources/app/apm/bin/node" "/Applications/Atom.app/Contents/Resources/app/apm/node_modules/npm/bin/npm-cli.js" "--globalconfig" "/Users/tshutty/.atom/.apm/.apmrc" "--userconfig" "/Users/tshutty/.atom/.apmrc" "install" "https://www.atom.io/api/packages/an-color-picker/versions/1.0.2/tarball" "--runtime=electron" "--target=3.1.10" "--dist-url=https://atom.io/download/electron" "--arch=x64" "--global-style"
15 verbose node v8.9.3
16 verbose npm  v6.2.0
17 error code E400
18 error 400 Bad Request: https://www.atom.io/api/packages/an-color-picker/versions/1.0.2/tarball
19 verbose exit [ 1, true ]


[webinterface] create vhost

[ ] create nginx vhost http://wpn.xm/ for the webinterface

referencing https://github.com/WPN-XM/WPN-XM/issues/610#issuecomment-244968784

The webinterface will be available at the following URLs:
http://wpn.xm/ and http://localhost.dev/webinterface.
The SCP uses the http://wpn.xm/ internally.


Ability to interrupt Serve() through a context

We add ServeContext() which acts exactly like Serve() but takes a
context as a first argument. When the context is cancelled,
ServeContext() will return. Also add a test for that (the test could be
expanded to check more stuff).
Note that the user has to close the "conn" after cancelling the context,
otherwise, there would be a leak of a goroutine. Another possible
improvement would be to pass the context to the handler as well.
Also, the use of context requires Go 1.7.

I believe, serve can be interrupted already by creating a ServeConn that errors on read and write (say an Interrupted error) when you want to close the process.  ServeConn is after all an interface that the user controls.  This would also open the door to ServeIfContext etc, along with requiring Go 1.7, which I don't want to do.


Fix findbugs warning in VmwareStorageManagerImpl.java

Any encoding would do fine as it's just used to generate a UUID. Sticking with UTF-8 for consistency

convinced, LGTM


Pocketbase connection

Very cool !!
Could we add a little more to show it working with pocketbase ? Happy to help :)
I am curious how the toml maps back to a collection in the pb SQLite db .
Maybe add an example of 2 also to help tease out how devs can use it but also any bugs

Sorry, was busy elsewhere. Just saw this... Thank you for your kind words.  TOML maps back to JSON (and from JSON back to TOML) using this excellent binary executable: https://github.com/alceal/jty-converter I simply use the $os.exec(...) function in PB to call that TOML converter when needed. I have not tested for scalability, but I think it is just too tiny and so should work fine for most tasks, I guess.


Proposed fix for multiple image field quality setting

The multiple image content type class ignores user defined quality settings.
The class does an isset() check on the $options variable, which is not defined thus always returns false. As a result the $resize_quality variable is set to it's default of 75%.
This PR fixes the conditional check.

This is not a breaking change and therefore could go into 1.1.  Could you please redo this PR starting from the 1.1 branch instead?  We recommend always using 1.1 as your working branch unless you NEED to rely on some functionality that has already been merged into 1.x


Incompatible hashicorp/aws v4.0.0

A recent upgrade of the hashicorp/aws to https://registry.terraform.io/providers/hashicorp/aws/4.0.0 causes a failure to deploy AFT due to an incompatibility between the the 3.0 and 4.0 versions of the provider and our usage of the 3.0 provider

We are currently working on a release where we will version lock hashicorp/aws provider.

Version 1.3.1 with the fix has been released.

Hi
When I tried to apply it today with module version 1.3.3, I got an error because it had not been updated to aws provider v4.0.0 yet.
% terraform init
Initializing modules...
Downloading aws-ia/control_tower_account_factory/aws 1.3.3 for aft...
- aft in .terraform/modules/aft
- aft.aft_account_provisioning_framework in .terraform/modules/aft/modules/aft-account-provisioning-framework
- aft.aft_account_request_framework in .terraform/modules/aft/modules/aft-account-request-framework
- aft.aft_backend in .terraform/modules/aft/modules/aft-backend
- aft.aft_code_repositories in .terraform/modules/aft/modules/aft-code-repositories
- aft.aft_customizations in .terraform/modules/aft/modules/aft-customizations
- aft.aft_feature_options in .terraform/modules/aft/modules/aft-feature-options
- aft.aft_iam_roles in .terraform/modules/aft/modules/aft-iam-roles
- aft.aft_iam_roles.aft_exec_role in .terraform/modules/aft/modules/aft-iam-roles/admin-role
- aft.aft_iam_roles.audit_exec_role in .terraform/modules/aft/modules/aft-iam-roles/admin-role
- aft.aft_iam_roles.ct_management_exec_role in .terraform/modules/aft/modules/aft-iam-roles/admin-role
- aft.aft_iam_roles.log_archive_exec_role in .terraform/modules/aft/modules/aft-iam-roles/admin-role
- aft.aft_lambda_layer in .terraform/modules/aft/modules/aft-lambda-layer
- aft.aft_ssm_parameters in .terraform/modules/aft/modules/aft-ssm-parameters
- aft.packaging in .terraform/modules/aft/modules/aft-archives

Initializing the backend...

Initializing provider plugins...
- Reusing previous version of hashicorp/aws from the dependency lock file
- Finding latest version of hashicorp/archive...
- Finding latest version of hashicorp/random...
- Finding latest version of hashicorp/local...
- Finding latest version of hashicorp/time...
- Installing hashicorp/archive v2.2.0...
- Installed hashicorp/archive v2.2.0 (signed by HashiCorp)
- Installing hashicorp/random v3.1.0...
- Installed hashicorp/random v3.1.0 (signed by HashiCorp)
- Installing hashicorp/local v2.1.0...
- Installed hashicorp/local v2.1.0 (signed by HashiCorp)
- Installing hashicorp/time v0.7.2...
- Installed hashicorp/time v0.7.2 (signed by HashiCorp)
╷
│ Error: Failed to query available provider packages
│
│ Could not retrieve the list of available versions for provider hashicorp/aws: locked provider registry.terraform.io/hashicorp/aws 4.2.0 does not match
│ configured version constraint >= 2.7.0, >= 3.72.0, < 4.0.0, 4.2.0; must use terraform init -upgrade to allow selection of new versions
╵


Custom  AbstractSoulPlugin not work

Describe the bug

According to the document https://dromara.org/projects/soul/custom-plugin/ "Matching Traffic Processing Plugin" does not work, request does not enter
Environment

Soul version(s): [e.g. 2.3.0]

Steps to reproduce
Expected behavior

Debug logs

Click to expand
replace this line with your debug logs

Please describe in detail.

@yqwoe We need a clear and concise description of what the bug is and the steps to reproduce.


Version 5.17.6 is broken for OverflowMenuItem when you click on the options

Version 5.17.6 is broken for OverflowMenuItem when you click on the options:
OverflowMenuItem.js:26 Uncaught TypeError: closeMenu is not a function
    at handleClick (OverflowMenuItem.js:26)
    at HTMLUnknownElement.callCallback (react-dom.development.js:542)
    at Object.invokeGuardedCallbackDev (react-dom.development.js:581)
    at Object.invokeGuardedCallback (react-dom.development.js:438)
    at Object.invokeGuardedCallbackAndCatchFirstError (react-dom.development.js:452)
    at executeDispatch (react-dom.development.js:836)
    at executeDispatchesInOrder (react-dom.development.js:858)
    at executeDispatchesAndRelease (react-dom.development.js:956)
    at executeDispatchesAndReleaseTopLevel (react-dom.development.js:967)
    at Array.forEach (<anonymous>)
    at forEachAccumulated (react-dom.development.js:935)
    at processEventQueue (react-dom.development.js:1112)
    at runEventQueueInBatch (react-dom.development.js:3607)
    at handleTopLevel (react-dom.development.js:3616)
    at handleTopLevelImpl (react-dom.development.js:3347)
    at batchedUpdates (react-dom.development.js:11082)

Thanks @Amir-61 for reporting! Seems to be the same as https://github.com/carbon-design-system/carbon-components-react/issues/579, please don’t hesitate to reopen if it’s not the case.


Support adding custom annotations to generated secret

Is there support for adding custom annotations to generated secret for syncing using kubed or similar?
If not, is this feature in the pipeline?

There was some discussion on this previously here: https://github.com/jetstack/cert-manager/issues/566
It's not something that we're working at the moment or see as a priority as there are known workarounds for it already, and it'll require special handling for e.g. what if the values have changed/are out of sync.
For your use-case (kubed), can you match on one of the existing labels/annotations we already add to Secret resources?

I've hit this issue a few times myself. We haven't found a solution. We would like to setup our tenant-namespace chart https://hub.helm.sh/charts/pnnl-miscscripts/tenant-namespace to automatically create letsencrypt based wildcard certs for each tenant created. The way we're doing this is to have two namespaces:
 and -admin.
-admin is where we keep tenant specific services such as nginx-ingress so that only the cluster-admins can manage them. Ideally our Issuers/Certificates are in this namespace too so the users are not bothered by them.
But nginx-ingress only will look for secrets in  so we need to sync them.
We want the chart to be the only thing we have to manage, so the workaround specified other places would be to stick the secret into the chart. But at least with helm2, I believe it will overwrite the whole secret on upgrade. So the workaround doesn't work around the issue in our environment.
Do we think it would be a hard feature to add? Is there any opposition to adding the feature, or just lack of hands?
Thanks,
Kevin

The specific issue/concerns are around:

The API schema was expose for this
How we 'reconcile' changes to these fields - i.e. if someone updates them on the Certificate, or on the Secret, what should happen?
How to allow users to opt-in/out of this behaviour

(1) is probably the harder of these problems to solve - trivially we could have spec.secretTemplate.metadata.annotations and spec.secretTemplate.metadata.labels, but I'm keen to hear if anyone else has thoughts on API format/schema 😄

Do we think it would be a hard feature to add? Is there any opposition to adding the feature, or just lack of hands?

The questions above are pretty much it :) I don't think this would be particularly tough, aside from the need for updating documentation, writing tests etc. We are also going to be undertaking some ~fairly significant refactoring in the Certificates controller for this release (tracked here: https://github.com/jetstack/cert-manager/issues/2691) - this should not impact the feature too much, but worth noting :)
& yes, lack of hands is definitely a problem! I'd ask that if someone is keen to see this feature added, please take the lead on it 😄
/help-wanted
/priority backlog
/kind feature

spec.secretTemplate.metadata.annotations and spec.secretTemplate.metadata.labels would allow for the things we need to be done right now, while leaving room for doing all sorts of things in the future. So sounds good to me.

can we make it behave as kubectl apply would?
the existence of secretTempate triggers the new behavior?

@munnerz

How we 'reconcile' changes to these fields - i.e. if someone updates them on the Certificate, or on the Secret, what should happen?

I think the Secret should always reflect its associated Certificate, because the Certificate declares its desired configuration. So these fields should be overwritten in the Secret and should get overwritten again when they are changed behind cert-manager's back. Any extra annotations or data should be left alone, but I think that is already the case (in my ArgoCD setup I noticed cert-manager actually added its TLS data to an existing Secret becaue I used the same name, but did not touch the existing fields).
I can't think of a use case where you would expect to keep your changes if you change things by yourself while a k8s operator is actively managing it.

How to allow users to opt-in/out of this behaviour

I'd say by annotating the Certificate. Default to false (opt-in) for backward compatibility.
The https://github.com/emberstack/kubernetes-reflector project actually does this by looking for its own annotations on a Certificate which will then be copied to a Secret (but I feel this creates an unnecessary inter-project dependency on your API, and would therefore be better style if the cert-manager project itself would handle this on its own CRD).

What about a kubectl apply style? 3-way merge
a copy of the annotations/labels applied by cert-manager is saved in an annotation at the time of application.
If the CR is changed, it can compare the annotations/labels in the CR vs the ones that it previously applied. That can allow it to delete annotations/labels that were removed from the CR that were previously managed. It also can ignore annotations/labels added by the user directly to the secret without ever being in the CR.

Any updates for this? Still a problem for us.

I also need this. Is there a bounty for it?

Any objections to adding
extraSecretLabels
and
extraSecretAnnotations
to the Certificate CRD under spec?
Just digging through the code real quick, it does not look like it would be very hard to add the functionality?
Is it just need to be added here? :
pkg/controller/expcertificates/internal/secretsmanager/secret.go line 238

We also need this for kubed, it makes it really cumbersome to distribute a secret around namespaces if you can't even annotate it.

We moved from Kubed to https://github.com/emberstack/kubernetes-reflector for this very reason.

We also need this for kubed, it makes it really cumbersome to distribute a secret around namespaces if you can't even annotate it.

@onmyflow We moved from Kubed to https://github.com/emberstack/kubernetes-reflector for this very reason.

Thanks for the suggestion! I'll try to switch to reflector since all we use kubed for, is to sync secrets anyway.

Yeah, this looks very promising. Thanks.

I continue to use Kubed because kubernetes-reflector is not a full replacement; it does not allow syncing between clusters, nor is it possible to create a dummy mirror Secret without valid data.
This feature requirement remains open on cert-manager for me. I'm willing to implement it or potentially fund its implementation, but need @munnerz to acknowledge the suggestion from @kfox1111 before investing time in something that might be rejected.

For me too +1

@munnerz what do you think?

Do we have an update on this ticket?

Is it possible for secretTemplates to be added to the Issuer and ClusterIssuer specs or to ingress-shim to enable mirroring of automatically generated Certificates?

Have you solved this case?

Is it possible for secretTemplates to be added to the Issuer and ClusterIssuer specs or to ingress-shim to enable mirroring of automatically generated Certificates?

@Kab1r @rikirolly I've created a PR to allow setting secretTemplates from Ingress annotations: https://github.com/cert-manager/cert-manager/pull/6839


Added stunning.edu.np

I have not got any update?

@bikash0070 Thank you for your patience while waiting for a review and processing your request. Pull request merged.


update warning message

Warning message in setup.py points to old compile commands.
Update to use single line make command as in documentation.

Closed with merge of #65.


Encode ClientId/Secret in Basic Authorization Header per OIDC Spec

See <IP_ADDRESS> at http://openid.net/specs/openid-connect-basic-1_0.html#TokenRequest
Also removes the id and secret from the body of the message, although it's unclear if any Identity Providers will actually fail if its included both places, so might be worth leaving for compatibility even though it is against the spec.

Addresses #1737

Do you know of any services that don't work with the current bahavior?

And for that matter, any providers that this change works with?

it's unclear if any Identity Providers will actually fail if its included both places, so might be worth leaving for compatibility even though it is against the spec.

No, don't do that... it's illegal and standard-compliant servers will reject your request if you do that (e.g my 2 OIDC server libs will return a Multiple client credentials cannot be specified. error).
This change is a potential breaking change (if your credentials include a : in either the identifier or the secret, your app will no longer work with client_secret_basic). You should make it opt-in.

This just cost our company an embarrassing amount of time and money to track down. It's mandated as optional in the OAUTH 2.0 spec, but required by the OIDC spec. Your current implementation isn't even allowed by the OIDC spec.
And you knew about this BUG a year and a half ago?
The point of having a spec is that each implementer doesn't a get a vote about what they think makes sense for one reason or another. We implement a spec so that all the different solutions will be interoperable. For once, someone actually makes one of those rare and precious specs that isn't ambiguous and open to interpretation, and then your team decides to ignore it anyway.

The identity provider for our company does not work if the client id and secret are included in the body. Any idp that does so is non-compliant.
I would be surprised if the change actually breaks any providers, but if it does, then the bug is on their end. At the very least, the default behavior should be compliant, and a simple flag could be added to do it the old way.
Why would a colon or non-ascii char in the id or secret cause a problem? The spec says that the authorization header should be base64 encoded, so putting the id and secret directly into the header separated by a colon would also be non-compliant.

Why would a colon or non-ascii char in the id or secret cause a problem?

For non-ASCII, the problem is that the original basic authentication RFC doesn't specify the encoding which is used before the string is base64-encoded. In practice, many implementations assume ASCII, not UTF-8.
Read https://tools.ietf.org/html/rfc7617#section-2 for more information.

My PR didn't actually send credentials in both header and form. I only mentioned it in the Issue, because I was trying to think of a way to keep everyone happy. I agree it's a bad idea.
I didn't read the whole spec, but I (maybe mistakenly) thought the OIDC was trying to simplify interop by mandating client_secret_basic.
I see what you mean now by the colon.
I also did notice the failure to specify UTF8, although it seemed to be implied by other places I noticed in the spec that did specify UTF8.  I'm well familiar with ambiguity problems in specs, having spent years making CORBA implementations interoperate.
I also understand the resistance to making breaking changes. If I could get all of our (at least the newer core 2+) services to work out of the box with a one-line setting change instead of having to hack in a custom RedeemToken function then I would be very happy. Most of the teams at our company before me ended up either writing their own middleware from scratch, or even implementing the OIDC flows at  the app layer with controllers. I've been pushing for our latest project to build all of our services relying on the stock core 2 middleware as much as possible. I don't want us to be in the OIDC/OAUTH business.

Just had a brief read through the full spec. Yikes.
I'll try to push our identity provider to at least support client_secret_post as an option, but it would still be nice if core 2+ at least supported client_secret_basic as an option since it was supposed to be the default.

For completeness, here's a link to the past discussion of this bug. https://github.com/aspnet/Security/issues/1032

If the header is used for client authentication, it should use the encoding specified in RFC6749 - everything else is a bug.

@leastprivilege assuming you're referring to the formurl encoding, even that is quite risky as it has never been correctly implemented in many (if not most) OAuth2/OIDC implementations, including yours and mine :sweat_smile:

Curious: did you do that in a major release or in a minor one? Did you implement a quirk?

minor. we got some error reports. People accepted it. My client lib has a "legacy mode". The world moved on.

I just checked the OIDC certification tests - they test that the OP supports both the authz header approach as well as POST body.
So it's totally fine for the OIDC handler to POST client id/secret.
BTW - the OIDC handler should get certified. I always tell customers to pick software from that list:
https://openid.net/certification/ - unfortunately the ASP.NET Core OIDC handler is not on it..
@blowdart

In summary: We could add this but it would need to be optional opt-in.
Certification issue: https://github.com/aspnet/Security/issues/1197

Triage discussion: While we think it could be good to support this, we are not taking this PR as-is because we think it needs to be opt-in (off by default, for compatibility), and we would likely also want to add additional test coverage.


Use Colors as a repeated pattern rather than 1:1.

I'm proposing a change to how drawing text with multiple colors works. While issue
https://github.com/FontStashSharp/FontStashSharp/issues/29 is working as currently intended, I think it defies expectations somewhat and pretty much requires the making of a custom Color[] function to work sanely.
The first part of the change is to make the array repeat after Colors.Length is exhausted inside TextColorSource.
Old
color = Colors[ColorPosition];
New
color = Colors[ColorPosition % Colors.Length];
This new code will should only error out if the Length is 0, which would be an error in any situation. This code itself would also would probably not break any custom functions anyone has made to make a custom Color[] function. If nothing else, I think this change would be useful and provide expected results.

This produces

However, I personally don't feel this is quite what would be expected either. Notice the o in hello and the W in world are both green. This is because with the repeating pattern, the position of the space between the two words is receiving the red. I think most expectations would be that the W would be red.
To change this, I modified TextSource to include decoupled functions for getting the next codepoint and getting the next color. I modified the two rendering classes to use these two methods and to only advance the color if the resulting glyph is not empty.
This produces

However, this almost certainly will break custom Color[] functions people have made to achieve the same result, assuming they inserted their own check for spaces or empty glyphs and added extra colors to their arrays to compensate. Those checks and compensations would need to be removed. Since recent and future versions of FSS seem to be open to some API changes, I think this would be a minor annoyance.
It is my opinion that this change would reduce the likelihood of errors from mismatched string and array lengths that result either from custom functions or hard coding. I also think that it would reduce the workload to achieve the effect that I think is probably the first expectation of this feature.

Ignore my dyslexia, the code I screenshot swapped green for red and red for green. That code does work properly too.
Repeating

Ignore Emtpy

That's great idea! Thanks!


Fix Async Message Pump

We recently added a Message Pump #138 to our main to get more effective with our thread management.
This caused an issue with marshaling all the threads on to the main thread, since we didn't have a .ConfigureAwait(false) on any of the await task.
To fix this item we need to add on all await task a .ConfigureAwait(false) starting in Program.cs with the top await call shown below.
await deviceSimulator.RunSimulationAsync(scenario, ct);
should be
await deviceSimulator.RunSimulationAsync(scenario, ct).ConfigureAwait(false);
Note: There are 2 await calls in Program.cs.
Probably should be added after #156, #157  PR are done

Related to #161.

Could we push some more of the message pump bits into the console host class? It looks like it's a bit redundant across the console hosts. It doesn't need to happen as part of this work item. I just want opinions. If there's a consensus. we'll add a specific work item.

Must do this for the ColdStorage code.

The goal for this task was to add ConfigureAwait(false) to the Solution where appropriate.
@bennage Taking a look at moving more of the message pump bits to the console host class is very doable - probably a couple of hours.  Created task #187 to consolidate the message pump code to console host.


tasks/raxmon_agent_install.yml does not upgrade to a new version correctly

The git module called out of tasks/raxmon_agent_install.yml does not seem upgrade the git repo correctly. Running the setup-maas.yml playbook out of the master branch will leave the git repo stale. I did clone it manually to progress but we might want to check on that.

@BjoernT is this still an issue?

@BjoernT closing this for now - please re-open with additional detail if it's still a thing

No it's not an issue anymore after we killed rpc-maas repo. This issue would be still present for juno but that's quickly dying


Fix outbound transit after acapy upgrade

After learning about the plugin and how to test it properly I realized the custom outbound transit broke with the acapy upgrade. I think the order of the wire_format and root_profile parameters must have changed and it wasn't using named arguments. I fixed it by copying how the http outbound in acapy was using the base class.

👍🏻 from me - don't know much about WHY you're encountering the error you found though.
Question: are we planning on executing tests on PR submissions in the future?

Yes. I the plugin repo runs integration tests for changed plugins on every PR. It would have caught this. The failing unit tests should have been an indication that there was a problem as well but I didn't know enough to realize what problem it was causing.
The error was:

integration-faber-1      | Traceback (most recent call last):
integration-faber-1      |   File "/usr/local/lib/python3.9/asyncio/tasks.py", line 256, in __step
integration-faber-1      |     result = coro.send(None)
integration-faber-1      |   File "/usr/src/app/.venv/lib/python3.9/site-packages/aries_cloudagent/transport/outbound/manager.py", line 148, in start_transport
integration-faber-1      |     transport = self.registered_transports[transport_id](
integration-faber-1      | TypeError: init() missing 1 required positional argument: 'wire_format'

I had noticed it before but didn't realize that the outbound transit was breaking because of it.

I could change the integration tests to the ones I'm adding in the plugin repo. I think they are more thorough. One reason I didn't catch this sooner was because the integration tests didn't really tests the outbound transit.


[POC] add metrics from demcompare

Context
The purpose of this ticket is to implement the demcompare metrics into geoutils. We have decided not to include them in xdem because these measurements apply specifically to rasters.
Code
We propose first to copy the metric directory from demcompare into geoutils.
Example script:
import geoutils as gu
from geoutils.metric import Metric

filename_rast = gu.examples.get_path("exploradores_aster_dem")
rast = gu.Raster(filename_rast)

metric_obj = Metric("pdf")
output = metric_obj.compute_metric(rast.data)

print(output)

To do:

[ ] Remove the matrix_2d_metrics file and open a ticket to move the SVF to the terrain attributes in xdem (also check the init file).
[ ] Recode the compute_surface_normal and remove_nan_and_flatten functions in geoutils.

Tests
For testing, you can retrieve and adapt the following files:

[ ] scalar
[ ] vector

Documentation
A section should be added inspired by the demcompare documentation.

I understand the previous discussion to go to geoutils for the simple metrics and to have metrics on geoutils, but i see now a dichotomy with matrix_2D metrics (svf, hillshade) that are kept in xdem.
I feel here we split the metrics in geoutils and xdem, I feel that we will have difficulty to have a common unique way of automating metric computation through a CLI pipeline (such as demcompare). It was my question in : https://github.com/GlacioHack/xdem/issues/551
and I don't know if you have discussed this matter.
I would have thought that the overall Metric structure would be in xdem and this structure could call geoutils sub functions for "simple" raster if interesting to have them in
Not sure with these splits.
In demcompare pipeline, we can  choose also svf, hillshade metric to generate them based on pipeline configuration file. I don't know if I am clear, please tell me if not.
So before finalizing this function, I think it could be important to be sure how we plan to use this structure from user and pipeline point of view and see if this design match. To be discussed...
for compute_surface_normal and remove_nan_and_flatten  in demcompare, it was not well architectured, so take the easier approach with xdem/geoutils philosophy in mind. Geoutils seem the best way, i agree.

I did not fully realize that under "metrics" were many different functions: from a single value metric (mean, STD), to a distribution (PDF) and visualization (hillshade). I think we might have only shortly mentioned this during our discussion in August, and I agree with @duboise-cnes that in that case, wrapping all of this directly in xDEM would make the most sense.
Additionally, it seems the primary use of the Metric class would be to link the CLI with a functionality that already exists separately in the Python API (whether it's a NumPy reduction function like np.mean(), or terrain attribute like terrain.hillshade()). In that case, it seems the Metric class would not be useful in the Python API, but only as a CLI link, and thus we could make it non-public. That would be further justification to have everything implemented in xDEM (as it would bring little value to GeoUtils if it is non-public; at least as long as we don't require a CLI in GeoUtils... but currently we don't have any pipeline there, like we have coregistration for DEMs...).


Unable to run lein dev

Hi, I'm not sure if there's a super obvious solution to this:
I ran the following (on windows 10):
lein new re-frame project
cd project
lein deps
npm install
lein dev

and lein dev returns me a result of:
λ lein dev
lein-shadow - preparing npm package.json
lein-shadow - installing npm packages
lein-shadow - npm package installation failed with
Error encountered performing task 'do' with profile(s): 'dev'
lein-shadow - npm package installation failed with

I'm starting out with clojure, and am not familiar with the tooling. Is this a misconfiguration on my end?

Thanks for the report @Wagk New users is a primary use case for re-frame-template so we definitely want to fix this if there is an issue.
First, its not causing your build to fail but your report highlighted a bug in our documentation. As I recently migrated the template to lein-shadow that manages package.json, npm etc now so running npm install manually is just a no-op since there is no package.json file until lein-shadow writes it to disk. I have updated the documentation which will be reflected in the next release.
Otherwise the commands look correct.
I have tested on Windows 10 and it works for me with these versions:
> gcm lein
CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
ExternalScript  lein.ps1                                                      C:\Scoop\shims\lein.ps1

> lein --version
Leiningen 2.9.3 on Java 11.0.7 OpenJDK 64-Bit Client VM

> gcm node
CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     node.exe                                           <IP_ADDRESS>  C:\Program Files\nodejs\node.exe

> node --version
v12.16.3

> gcm npm
CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     npm.cmd                                            <IP_ADDRESS>    C:\Program Files\nodejs\npm.cmd

> npm --version
6.14.4

Can you see any output after the last line npm package installation failed with ?

@superstructor no I can't

Those version all look fine. gcm is a PowerShell thing like which on *nix.
After you run the failed command it should leave a non-empty package.json in that directory ?
What are the contents of the package.json file ?
What is the output of running npm install in that directory after lein dev has failed ?
lein dev writes out package.json and executes npm install via lein-shadow so just trying to peal back the layers and make the failure/error message visible so we can identify the root issue.

The contents of the package.json is the following:
{"dependencies":{},"devDependencies":{"shadow-cljs":"2.8.109"}}

So it looks like npm install by itself is successful ?
The code for lein-shadow here simply

executes npm install
checks for a successful exit code
if not successful prints stdout and stderr of the npm output to the console.

So its odd that

npm install doesn't appear to fail when run independently ?
there is not stdout or stderr to explain the error ?

yes, it's quite odd.
I attempted to run the command in the repl using the following:
λ lein repl
nREPL server started on port 52370 on host <IP_ADDRESS> - nrepl://<IP_ADDRESS>:52370
REPL-y 0.4.4, nREPL 0.6.0
Clojure 1.10.1
Java HotSpot(TM) Client VM 1.8.0_251-b08
    Docs: (doc function-name-here)
          (find-doc "part-of-name-here")
  Source: (source function-name-here)
 Javadoc: (javadoc java-object-or-class-here)
    Exit: Control+D or (exit) or (quit)
 Results: Stored in vars *1, *2, *3, an exception in *e

user=> (use '[clojure.java.shell :only [sh]])
nil
user=> (sh "npm" "install")
Execution error (IOException) at java.lang.ProcessImpl/create (REPL:-2).
CreateProcess error=2, The system cannot find the file specified

I'm not sure how exceptions map from java to clojure, though this would make sense if my shell is only capturing the stdout channel.
Does this help?

That is interesting. I can confirm that is your issue. Some kind of environmental or PATH issue with the JDK.
I get this for example:
> lein repl
REPL-y 0.4.4, nREPL 0.6.0
Clojure 1.10.1
OpenJDK 64-Bit Server VM 11.0.7+10
    Docs: (doc function-name-here)
          (find-doc "part-of-name-here")
  Source: (source function-name-here)
 Javadoc: (javadoc java-object-or-class-here)
    Exit: Control+D or (exit) or (quit)
 Results: Stored in vars *1, *2, *3, an exception in *e

user=> (use '[clojure.java.shell :only [sh]])
nil
user=> (sh "npm.cmd" "--version")
{:exit 0, :out "6.14.4\n", :err ""}

There is something we can change to improve, which is to print a clearer error message for this failure case when npm is not found. That is a lein-shadow issue and I will follow it up.
Therefore there is no bug in re-frame-template as such, so closing.
Thanks for the information and feedback, it has helped us improve the error messages for future users 😄

Thanks for the prompt response.
I've managed to successfully lein dev on WSL, so it does look like an issue local to my (windows) machine.
Cheers


handleCalculatePositions returns value that wasn't expected

If checkPositionBounds is used a object of {x: number, y: number} is returned, but if transformEnabled is false handleCalculatePositions returns { newPositionX: number, newPositionY: number }

Both places where handleCalculatePositions is used {x: number, y: number} is expected to be the return type

Additional info here.. this would eventually cause positionX and positionY to be NaN if swapping between transform being enabled and disabled


Can't find stylesheet to import: @import "font-awesome" when using dartsass-rails

If submitting a bug report about missing icons or unexpected behavior:

[x ] Yes, I have tried all 10 debugging steps outlined in the Contribution Guidelines. Though it was not needed.

I have met  a problem to use the gem font-awesome-rails.
The command rails dartsass:build produces an error.
Error: Can't find stylesheet to import.
  ╷
2 │ @import "font-awesome"
  │         ^^^^^^^^^^^^^^
  ╵
  app/assets/stylesheets/application.scss 2:9  root stylesheet
bin/rails aborted!
Command failed with exit 65<EMAIL_ADDRESS>
I suppose the problem is that the file to be included with @import "font-awesome" from
font-awesome-rails-<IP_ADDRESS>/app/assets/stylesheets/font-awesome.css.erb') is of the format .erb and therefore can not be parsed:
$ bec
Loading development environment (Rails 7.2.0.alpha)
3.2.3 :001 > require 'sass-embedded'
 => true
3.2.3 :002 ><EMAIL_ADDRESS>Error: expected "(".
   ╷
14 │   src: url('<%= font_path('fontawesome-webfont.eot') %>');
   │                                                   ^
   ╵
  ../../../../font-awesome-rails-<IP_ADDRESS>/app/assets/stylesheets/font-awesome.css.erb 14:51  root stylesheet

I do not know, of which gem is the bug. The candidates are:

dartsass-rails
sass-embedded
font-awesome-rails

The whole project that demonstrates the bug is here.

I also have this problem


License checklist

Examine the license for your project and consider whether this is the choice you want to make, or whether you want to change the license. Discuss and reason the license choice.

We have decided to stick with MIT license for our project. For detailed discussion regarding this, please go to this issue.


segfault on GPIO configure

Jetson Orin Nano
# R35 (release), REVISION: 3.1, GCID: 32827747, BOARD: t186ref, EABI: aarch64, DATE: Sun Mar 19 15:19:21 UTC 2023

The below error is caused when setting the GPIO to an OUTPUT.
[ 1742.458497] ---[ end trace c9b4cbc2ab4c73c3 ]---
[ 1796.382888] CPU:0, Error: cbb-fabric@0x13a00000, irq=25
[ 1796.388290] **************************************
[ 1796.393217] CPU:0, Error:cbb-fabric, Errmon:2
[ 1796.397703] 	  Error Code		: FIREWALL_ERR

[ 1796.403372] 	  Error Code		: FIREWALL_ERR
[ 1796.407497] 	  MASTER_ID		: CCPLEX
[ 1796.410993] 	  Address		: 0x32e0000
[ 1796.414580] 	  Cache			: 0x0 -- Device Non-Bufferable
[ 1796.419771] 	  Protection		: 0x2 -- Unprivileged, Non-Secure, Data Access
[ 1796.426747] 	  Access_Type		: Read
[ 1796.430238] 	  Access_ID		: 0x15
[ 1796.430242] 	  Fabric		: cbb-fabric
[ 1796.437136] 	  Slave_Id		: 0x35
[ 1796.440356] 	  Burst_length		: 0x0
[ 1796.443845] 	  Burst_type		: 0x1
[ 1796.447157] 	  Beat_size		: 0x2
[ 1796.450373] 	  VQC			: 0x0
[ 1796.453149] 	  GRPSEC		: 0x7e
[ 1796.456195] 	  FALCONSEC		: 0x0
[ 1796.459425] 	**************************************
[ 1796.464467] ------------[ cut here ]------------
[ 1796.464486] WARNING: CPU: 0 PID: 0 at drivers/soc/tegra/cbb/tegra234-cbb.c:577 tegra234_cbb_isr+0x130/0x170
[ 1796.474494] Modules linked in: nvidia_modeset(OE) fuse(E) lzo_rle(E) lzo_compress(E) zram(E) ramoops(E) reed_solomon(E) loop(E) bnep(E) snd_soc_tegra186_asrc(E) snd_soc_tegra186_dspk(E) snd_soc_tegra210_ope(E) snd_soc_tegra210_mvc(E) snd_soc_tegra210_iqc(E) snd_soc_tegra186_arad(E) snd_soc_tegra210_afc(E) snd_soc_tegra210_dmic(E) snd_soc_tegra210_admaif(E) snd_soc_tegra210_adx(E) snd_soc_tegra210_amx(E) snd_soc_tegra_pcm(E) snd_soc_tegra210_mixer(E) snd_soc_tegra210_i2s(E) snd_soc_tegra210_sfc(E) aes_ce_blk(E) crypto_simd(E) cryptd(E) aes_ce_cipher(E) ghash_ce(E) rtl8822ce(E) r8168(E) sha2_ce(E) sha256_arm64(E) sha1_ce(E) rtk_btusb(E) btusb(E) snd_soc_tegra210_adsp(E) btrtl(E) btbcm(E) btintel(E) snd_soc_tegra_machine_driver(E) snd_soc_spdif_tx(E) snd_soc_tegra_utils(E) snd_hda_codec_hdmi(E) snd_soc_simple_card_utils(E) snd_soc_tegra210_ahub(E) r8169(E) realtek(E) userspace_alert(E) fusb301(E) tegra_bpmp_thermal(E) nvadsp(E) snd_hda_tegra(E) tegra210_adma(E) cfg80211(E) snd_hda_codec(E)
[ 1796.474603]  nv_imx219(E) snd_hda_core(E) spi_tegra114(E) nvidia(OE) binfmt_misc(E) ina3221(E) pwm_fan(E) nvgpu(E) nvmap(E) ip_tables(E) x_tables(E) [last unloaded: mtd]
[ 1796.474630] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W  OE     5.10.104-tegra #1
[ 1796.474632] Hardware name: NVIDIA Orin NX Developer Kit (DT)
[ 1796.474636] pstate: 60400089 (nZCv daIf +PAN -UAO -TCO BTYPE=--)
[ 1796.474638] pc : tegra234_cbb_isr+0x130/0x170
[ 1796.474640] lr : tegra234_cbb_isr+0x10c/0x170
[ 1796.474642] sp : ffff800010003e10
[ 1796.474643] x29: ffff800010003e10 x28: ffffd05082682680
[ 1796.474646] x27:<PHONE_NUMBER>000001 x26:<PHONE_NUMBER>000080
[ 1796.474649] x25: ffffd050820a7778 x24: ffffd050829ebe40
[ 1796.474652] x23: ffffd05082387000 x22:<PHONE_NUMBER>000019
[ 1796.474655] x21: ffffd0508280ef20 x20:<PHONE_NUMBER>000002
[ 1796.474657] x19: ffffd0508280ef10 x18:<PHONE_NUMBER>000010
[ 1796.474660] x17:<PHONE_NUMBER>000000 x16: ffffd050809e2d90
[ 1796.474662] x15: ffffd05082682bf0 x14: ffffffffffffffff
[ 1796.474665] x13: ffff800090003917 x12: ffff80001000391f
[ 1796.474667] x11:<PHONE_NUMBER>010101 x10: 7f7f7f7f7f7f7f7f
[ 1796.474670] x9 : ffff800010003c30 x8 : 2a2a2a2a2a2a2a2a
[ 1796.474672] x7 : 2a2a2a2a2a2a2a09 x6 : c0000000ffffefff
[ 1796.474675] x5 : ffff7787a8377958 x4 : ffffd05082697968
[ 1796.474677] x3 :<PHONE_NUMBER>000001 x2 : ffffd05080b77460
[ 1796.474679] x1 : ffffd05082682680 x0 :<PHONE_NUMBER>010001
[ 1796.474683] Call trace:
[ 1796.474685]  tegra234_cbb_isr+0x130/0x170
[ 1796.474694]  __handle_irq_event_percpu+0x60/0x2a0
[ 1796.474697]  handle_irq_event_percpu+0x3c/0xa0
[ 1796.474699]  handle_irq_event+0x4c/0xf0
[ 1796.474701]  handle_fasteoi_irq+0xbc/0x170
[ 1796.474705]  generic_handle_irq+0x3c/0x60
[ 1796.474707]  __handle_domain_irq+0x6c/0xc0
[ 1796.474712]  gic_handle_irq+0x64/0x130
[ 1796.474713]  el1_irq+0xd0/0x180
[ 1796.474720]  cpuidle_enter_state+0xb4/0x400
[ 1796.474722]  cpuidle_enter+0x3c/0x50
[ 1796.474726]  call_cpuidle+0x40/0x70
[ 1796.474727]  do_idle+0x1fc/0x260
[ 1796.474729]  cpu_startup_entry+0x28/0x70
[ 1796.474737]  rest_init+0xd8/0xe4
[ 1796.474744]  arch_call_rest_init+0x14/0x1c
[ 1796.474746]  start_kernel+0x50c/0x540
[ 1796.474748] ---[ end trace c9b4cbc2ab4c73c4 ]---

For context, if you can copy and paste your code please? If it is one of my examples just tell me which one.
This can take around a week for me to check, I am abroad and don't have my Orin at hand.

OK so I ran some examples on my Orin Nano here but I am not able to reproduce your problem, I can trigger outputs just fine. No cbb fabric "firewall" issues on my kernel log either.
Anyways, looking at your log in line "[ 1796.410993] 	  Address		: 0x32e0000"  this error is related to the Orin cbb firewall stopping an application in user space writing to register: 0x32e0000 which is the one controlling PWM7 aka PWM in pin 32. I tested  that also but I don't have that problem either (by installing my library that is taken care of)
So in short, with no more feedback from your side I am not able to find any problem on my side of things. There is an observation I would like to make though, your version of Linux for Tegra is: 35.3.1, that if I recall correctly was the first release supporting Orin Nano and that one was quite incomplete/buggy. Not sure what your actual problem is, but maybe reflashing with a newer version is a good idea, whether you use my library or something else, check the list here: https://developer.nvidia.com/embedded/jetpack-archive
Finally, ALL cbb-fabric firewall problems can be sorted out by modifying the device tree file controlling the behaviour of the cbb and then reflashing, for more info of how to disable the cbb firewall you can check this one: https://forums.developer.nvidia.com/t/i2c-reads-writes-over-32-bytes-cause-cbb-error-on-i2c-0/234855


Pair volunteer and elderly befriendee contacts

As a voluntary organisation manager, I can pair volunteer and elderly befriendee contacts, so that I can keep track of which volunteers are paired with which elderly befriendees easily, and relay relevant information accordingly.

Befriendee and Volunteer objects will have a corresponding Volunteer/Befriendee as a field
Pair command will update the bidirectional association between Befriendee and Volunteer


'create-react-app' is not recognized as an internal or external command

C:\Windows\system32>cd C:\Users\ugur\Desktop\deneme
C:\Users\ugur\Desktop\deneme>npm init
This utility will walk you through creating a package.json file.
It only covers the most common items, and tries to guess sensible defaults.
See 'npm help json' for definitive documentation on these fields
and exactly what they do.
Use 'npm install  --save' afterwards to install a package and
save it as a dependency in the package.json file.
Press ^C at any time to quit.
name: (deneme)
version: (1.0.0)
description:
entry point: (index.js)
test command:
git repository:
keywords:
license: (ISC)
About to write to C:\Users\ugur\Desktop\deneme\package.json:
{
"name": "deneme",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo "Error: no test specified" && exit 1"
},
"author": "Ugur<EMAIL_ADDRESS>(http://www.abc.com.tr)",
"license": "ISC"
}
Is this ok? (yes)
C:\Users\ugur\Desktop\deneme>npm install -g create-react-app
C:\Users\ugur\AppData\Roaming\npm\create-react-app -> C:\Users\ugur
AppData\Roaming\npm\node_modules\create-react-app\index.js
C:\Users\ugur\AppData\Roaming\npm
--<EMAIL_ADDRESS> +--<EMAIL_ADDRESS> | +--<EMAIL_ADDRESS> | +--<EMAIL_ADDRESS> | +--<EMAIL_ADDRESS> | | --<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| --<EMAIL_ADDRESS> +--<EMAIL_ADDRESS> | +--<EMAIL_ADDRESS> | | +--<EMAIL_ADDRESS> | | --<EMAIL_ADDRESS>| --<EMAIL_ADDRESS> |   --<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>`--<EMAIL_ADDRESS>C:\Users\ugur\Desktop\deneme>create-react-app new_app
'create-react-app' is not recognized as an internal or external command, operable program or batch file.
Also npm configuration path is like
C:\Users\ugur\AppData\Roaming\npm\node_modules\create-react-app\
Try with this
npx create-react-app my-app

Create-react-app is an outdated solution for creating react apps.
Just use the vite and run:
npm init vite
Then, select the react template


GitHub App configuration support

This PR is the continuation of #46, after development has been stale for over two weeks.
Most of the work has been done by @blacksd and already reviewed by @AndreZiviani. I have only fixed style errors of the README.
Closes #46

Thanks for picking this up!
@lkysow can you approve the CI and review the PR please?

This still needs a review, right?

only big issue is being able to pre-set a secret for the app pem file and secret key. So those are in clear text if you do a helm get values atlantis

only big issue is being able to pre-set a secret for the app pem file and secret key. So those are in clear text if you do a helm get values atlantis

This is a general issue of helm. That's why helm state is encoded in secrets. Users without access to those secrets are not able to retrieve the deployed apps of the namespace.
Furthermore, this PR does not introduce this issue as other secrets (aws_secret_access_key,...) are already configurable.

@mzupan @lkysow what's blocking us from adding Github app support to the chart?


Configure log highlighting, add flag "-log-display-highlight"

With this change highlighting of logs displayed on stdout can be
configured. The default is to highlight using color, if stdout is a
terminal. This can be overridden with the -log-display-highlight flag -
to force color output, or force plain output.
An Enum is used, rather than a boolean to allow other highlighting
schemes (e.g. underline).
Fixes #169

A prototype, and focus for design discussion as much as anything. Questions/alternatives

Is DisableContextualDisplaying meant to serve this purpose? It seems to conflate highlighting with adding timestamps, log level, etc.
Is the "auto" behaviour a suitable default?
Should the ASCII art banner ever be disabled? E.g. if stdout is not a terminal.


qq: support wayland ozone

Description of changes
Add support for NIXOS_OZONE_WL
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

[x] 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.

Result of nixpkgs-review pr 244205 run on x86_64-linux 1

1 package built:

qq

Works great, thank you!


Accessing the Permissions page crashes the app

As in the title. Looking at the callstack, I'm hitting an unhandled exception at RNPermissions.cpp@64
Could be the gallery app is missing some app manifest attributes, compared to the example one in the RNPermissions repo.

@tritao we're seeing crashes with this sample page.  Can you take a look?

I will check what's going on.

The CI Loop is currently producing this error:
error MSB3271: There was a mismatch between the processor architecture of the project being built "x86" and the processor architecture, "AMD64", of the implementation file "C:\Users\chiaramooney\Documents\Code\react-native-gallery\node_modules\react-native-windows\target\x64\Release\Microsoft.ReactNative\Microsoft.ReactNative.dll" for "C:\Users\chiaramooney\Documents\Code\react-native-gallery\node_modules\react-native-windows\target\x64\Release\Microsoft.ReactNative\Microsoft.ReactNative.winmd". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and implementation file, or choose a winmd file with an implementation file that has a processor architecture which matches the targeted processor architecture of your project. [C:\Users\chiaramooney\Documents\Code\react-native-gallery\node_modules\react-native-permissions\windows\RNPermissions\RNPermissions.vcxproj]. Check your build configuration.
Could this be connected to this issue?

I don't think its related, I already have a fix for this issue and will open a PR in a bit. We can check the CI then.


Best way to display complex nested Schema

I publish a Report defined by a ReportSchema. The Reports contain several things like title and an array of findings defined by a FindingSchema, which are fairly complex themselves.  I want to update the report (which is working) so that one finding at a time is displayed and I can dynamically control which finding fields are displayed.

I can embed a template within a template and use {{with aFinding}} to pass a finding object to a non-autoform list of object properties (e.g.  {{findingNumber}}  ). Problem is no Autoform so no cool functionality.

I can make embed a template containing an autoform to display the findings (e.g. {{> afQuickField name='findingNumber'}} ).  I can get the collection= parameter to use the Finding Schema, but this is an update and I can't figure out what to put for doc=.   doc=this refers to the Report document passed as data from the router and displayed correctly in the report itself.  doc=this.findings could refer to the array of findings, but  nothing i've tried sets the data context of the embedded template autoform is displayed and validated.  It displays with the correct fields but no data?

I can iterate over each finding field with {{#each affieldNames}} {{afQuickField name=this.name}} {{/each}}.  this.name works to display each field but I cannot limit which finding fields are shown. All is the only option. fields='myFieldName" or omitFields is ignored.  name=this.name.myFieldName also fails.  The only way I can control field visibility is within the schema, which is then not dynamic on the client (?).

I would highly recommend avoiding array fields until the performance issues are fixed. When I have a schema that contains an array, I render the array manually:
<template name="report">
{{#autoForm doc=this type='update' collection='collection' }}
    {{> afQuickField name='someReportField'}}

    {{#each findings}}
        {{> finding }}
    {{/each}}
{{/autoForm}}
</template>

Now, you won't be able to use autoform components inside finding, and you cannot nest AutoForms, so if you need form fields inside that template, move it outside the AutoForm block:
<template name="report">
{{#autoForm id='reportForm' doc=this type='update' collection='collection' }}
    {{> afQuickField name='someReportField'}}
{{/autoForm}}

{{#each findings}}
    {{> finding }}
{{/each}}
</template>

<template name="findings">
{{#autoForm id='findingForm' class='findingForm' doc=this schema='FindingSchema'}}
    {{> afQuickField name='someFindingField' }}
{{/autoForm}}
</template>

Use AutoForm hooks to add the finding array back to the document when the form is submitted.
AutoForm.addHooks('reportForm', {
    docToForm: function(doc){
        // If each finding template contained an AutoForm of its own
        doc.findings = [];
        $('.findingForm').each(function(){
            // Get the values for this AutoForm
            var values = AutoForm.getFormValues($(this).attr('id'));
            doc.findings.push(values);
        });

        return doc;
    }
});

The idea is to split array items into their own AutoForm instances instead of allowing AutoForm to use it's array field, which suffers from performance issues when the array gets longer than 10-20 items.

Thanks. I had a feeling there was a problem with my approach.
On Tue, Sep 1, 2015 at 7:42 PM -0700, "Andrew Becker"<EMAIL_ADDRESS>wrote:
I would highly recommend avoiding array fields until the performance issues are fixed. When I have a schema that contains an array, I render the array manually:

Now, you won't be able to use autoform components inside finding, and you cannot nest AutoForms, so if you need form fields inside that template, move it outside the AutoForm block:

Use AutoForm hooks to add the finding array back to the document when the form is submitted.
AutoForm.addHooks('reportForm', {
docToForm: function(doc){
// If each finding template contained an AutoForm of its own
doc.findings = [];
$('.findingForm').each(function(){
// Get the values for this AutoForm
var values = AutoForm.getFormValues($(this).attr('id'));
doc.findings.push(values);
});
    return doc;
}

});
The idea is to split array items into their own AutoForm instances instead of allowing AutoForm to use it's array field, which suffers from performance issues when the array gets longer than 10-20 items.
—
Reply to this email directly or view it on GitHub.

You can try the following:
  {{#autoForm id="reportForm" schema=schema type="insert" }}
    {{> afArrayField name='findings'}}
  {{/autoForm}}

It worked for single level complex schemas, hope it works for you.


Access for assistive devices is required but not checked

Eventually aborting the application and throwing the following error :
lib/rb-scpt.rb:542:in _send_command': CommandError (Appscript::CommandError) 		OSERROR: -1719 		MESSAGE: Access for assistive devices is disabled. 		OFFENDING OBJECT: app("/System/Library/CoreServices/System Events.app").processes["iTerm2"].menu_bars[1] 		COMMAND: app("/System/Library/CoreServices/System Events.app").processes["iTerm2"].menu_bars[1].menu_bar_items["Window"].menus["Window"].menu_items["Select Split Pane"].menus["Select Split Pane"].menu_items["Select Pane Left"].click() 	from /Users/carlo/.gem/ruby/2.0.0/gems/rb-scpt-1.0.1/lib/rb-scpt.rb:642:in method_missing'
from /Users/carlo/src/i2cssh/lib/i2cssh.rb:103:in block (2 levels) in split_session' 	from /Users/carlo/src/i2cssh/lib/i2cssh.rb:102:in upto'
from /Users/carlo/src/i2cssh/lib/i2cssh.rb:102:in block in split_session' 	from /Users/carlo/src/i2cssh/lib/i2cssh.rb:101:in upto'
from /Users/carlo/src/i2cssh/lib/i2cssh.rb:101:in split_session' 	from /Users/carlo/src/i2cssh/lib/i2cssh.rb:26:in initialize'
from ./i2cssh:302:in new' 	from ./i2cssh:302:in '
At least on Sierra, a system pop up will spawn asking for authorization to enable UI and showing iTerm in the list of applications that requested "UI" access.
Once that is enabled the following Applescript would return true :
tell application "System Events"
set GUIScriptingEnabled to (UI elements enabled)
return GUIScriptingEnabled
end tell
As an alternative, using instead Keys (as done in csshX) should allow for this to run without the need for "UI special access", which is restricted for Security reasons

Same problem.


60 progress bar incrementation

First version of zone generation and change to progress bar

Added zones and progress bar


Exception being thrown during initialization of LogManager with  HAVE_MAT_STORAGE disabled.

Building win32-lib on VS2019 with MSVC 14.2. sqlite module is disabled via the HAVE_MAT_STORAGE flag being disabled in config-custom.h.
When initializing LogManager with HAVE_MAT_STORAGE disabled, an exception is thrown. It occurs at Line 89 of OfflineStorageHandler.cpp.
Exception thrown: read access violation.
std::shared_ptr<Microsoft::Applications::Events::IOfflineStorage>::operator->**<Microsoft::Applications::Events::IOfflineStorage,0>**(...) returned nullptr.

I'm pretty sure this is happening because of OfflineStorageFactory::Create() in OfflineStorageFactory.cpp. If MAT Storage is disabled, it returns nullptr (Lines 39-40 of OfflineStorageFactory.cpp).
Is this was intended behavior? Or am I doing something incorrectly in my initialization to cause this exception?

Most likely it's a recent regression. There is presently no CI loop to validate that build combo. This is not very frequently used build combo... Thus, highly likely got regressed without being noticed. Need to fix it.

I sent the fix for review. Please take a look.


cca for windows 10?

I just found cordova had supported windows 10 now, any plan for cca supports windows 10?
something likes:
cca platform add “windows@https://aka.ms/cordova-win10” ?
thanks.

We have no plans for this to be honest, but would happily accept patches to our plugins that add win10 support.

It's ok, I will look into how feasible porting my chrome app to windows 10, hope it's less pain with cordova instead of node-webkit.

Great news, just found node-webkit had supported Chrome App a month ago.
https://groups.google.com/forum/#!msg/nwjs-general/zeC6SedUSFY/BlumrYJeVHYJ

That's really cool!
On Thu, Aug 6, 2015 at 10:25 PM, Imskull<EMAIL_ADDRESS>wrote:

Great news, just found node-webkit had supported Chrome App a month ago.
https://groups.google.com/forum/#!msg/nwjs-general/zeC6SedUSFY/BlumrYJeVHYJ
—
Reply to this email directly or view it on GitHub
https://github.com/MobileChromeApps/mobile-chrome-apps/issues/590#issuecomment-128564790
.


KiBuzzard labels trip warning for "duplicate footprints"

KiCad 5.99 now throws a warning for duplicate footprints on DRC if multiple footprints have the same reference. This would be easily avoided by appending a unique ID to each label created.

This sounds reasonable.
I've added a hex timestamp to the end of the footprint name, does this fix the DRC issues?

Works great! Thank you.