Docs do a poor job of explain what this library does

It took me several hours to understand how this library worked... the docs need a lot of love.

In the readme and intro docs, a test is added with that looks through "tests/cmd/*.trycmd" but no example is shown of a trycmd so I had no idea these files actually needed to exist (I thought TRYCMD=dump would create them and was very confused for a while). An example of the trycmd file is needed.
It also needs to be mentioned that md files are interpreted the same way.
The example here makes no sense. It looks like that rust code will be compiled on the fly (it isn't) and where is my-cmd coming from? And how does the output make any sense? It says print hello world but then only hello is printed. This example needs to be completely reworked: it should clearly and explicitly be shown that you have a basic rust binary with a main function that prints something, an md/trycmd file that calls that binary (no need for input params), and a test that has the trycmd file as a case.
Eliding content needs an example because I still can't figure out what it does: https://github.com/assert-rs/trycmd/issues/140

See

0079aeeb1dbae09f111f72eb03a7602cc1ee15fc
ff4c769268fb998959147ac46a4262864a62426d
dceeaaa7c506221c50175d3531432096e50a2d78

This is very disappointing: it misses the point that there should be a concrete example. You've described the example without actually providing a real example people can look at. Also it's deeply ironic to have incorrect examples because you aren't using the library you're trying to demo.

This is very disappointing: it misses the point that there should be a concrete example.

This issue is not about a concrete example but specific pain points.  Feel free to create an issue about concrete examples
Roll up issues are not ideal because they are rarely ever "done", being a constant moving target.

Feel free to create an issue about concrete examples

Sure: #146


add pci-compliance note

This change is

Note that this must not be pushed until the certification release, currently set for Aug 5. Confirm with @abhinavg6

Note that this must not be pushed until the certification release, currently set for Aug 5. Confirm with @abhinavg6

@adbrenn - FYI, the doc release for PCI-DSS is currently planned for Aug 5.


shiro-security when using release 3.1.5 of wicket-spring-boot-starter not working

Hello @MarcGiffing,
I was trying this example : https://github.com/MarcGiffing/wicket-spring-boot-examples/tree/master/spring-security
with the last version (3.1.5) of wicket-spring-boot-starter but I got some errors when running :
java.lang.IllegalStateException: Couln't find sign in page - please annotate the sign in page with @com.giffing.wicket.spring.boot.context.scan.WicketSignInPage 	at com.giffing.wicket.spring.boot.starter.configuration.extensions.stuff.shiro.ShiroSecurityConfig.init(ShiroSecurityConfig.java:48) ~[wicket-spring-boot-starter-3.1.5.jar:3.1.5] 	at com.giffing.wicket.spring.boot.starter.app.WicketBootStandardWebApplication.init(WicketBootStandardWebApplication.java:77) ~[wicket-spring-boot-starter-3.1.5.jar:3.1.5]
After some time debugging, I found that ShiroSecurityConfig is processed before anything is done in ClassCandidateScannerConfiguration as a workaround I defined this bean of type ** WicketClassCandidatesHolder** and everything is working .
Am I missing some configuration or is it the desired behavior?
Find attached the modified sample I am working on
shiro-security.zip

Can you please try 3.1.6
AnnotatedMountScannerConfig no longer picking up base packages in 3.1.5 #186

Hello @MarcGiffing
3.1.6 works like a charm.Thanks for the fix!


more general histograms?

the current histogram operates on float data only. biocaml has a more general histogram type, built on their accum structure where the data type is polymorphic, and one has to pass a comparison function, as well as a function which increments the count which is also polymorphic. this is quite general and seems useful, but biocaml depends on core and is quite specialized. maybe a more general histogram would be something for a less specialized math/stats library like oml?

Hello,
After a bit of digging through Biocaml, I found the histogram and accu modules. By accum I think that you are referring to the latter. I agree that it is potentially very useful; though I think it serves a more general ability of being able to aggregate and group data; but I'm not certain that I want that functionality in a function to create histograms. Perhaps in a separate module?
Regarding the histogram implementation, very often, I don't know the boundaries of a potential histogram. At these points I'll use `Buckets _ or  `Width _ arguments to get a quicker sense of the data before investigating further; I want to preserve this ability to generate a simple assoc like that I can easily interpret. That is why I like its signature and I am a bit hesitant on a more general Histogram module, but I would definitely merge one. Maybe we can afterwards rename the function in Descriptive to something simple_hist :smile:
I agree 100% that limiting the possible data input to floats (or _ arrays for that matter) is a big limitation and something that the library has to rectify, but at the moment I don't have a good flexible strategy of accomplishing that. If I had to do that right now, I think it will require functorizing many methods and I would prefer use modular implicits to solve these problems. But again a fun thing to try and a PR would be welcome.

yes, sorry i meant accu. disclaimer: i have not actually used it, just browsed the interface. i agree that the auto-binning is very useful, and any more general histogram should not replace a more specialized float-based histogram interface.  also, obviously multidimensional float histograms for vector valued data would be great to have. by far the most important would be 2d i believe. not sure i can find the time for a PR but if i do, i'll give it a shot.

Sounds good.


doc: update node.js docs to mention layers

Updates the docs to point users at the Node Agents layer.

@bmorelli25 From a tech writing/elastic standards point of view, do you think we need to repeat the "how to add a layer in the UI" instructions a second time (as its written now), or can we assume the user will have picked this up from the initial section?

:green_heart: Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

Start Time: 2022-03-03T18:22:32.522+0000

Duration: 6 min 29 sec

Test stats :test_tube:

Test
Results

Failed
0

Passed
84

Skipped
6

Total
90

:robot: GitHub comments
To re-run your PR in the CI, just comment with:

/test : Re-trigger the build.

run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)


Hotfix suppress LINQ warnings

When NetFabric.Hyperlinq.Analyzer is installed it emits warnings about the use of .Single() because most of the time .First() is more appropriate.
Specific Error: https://github.com/NetFabric/NetFabric.Hyperlinq.Analyzer/blob/master/docs/reference/HLQ005_AvoidSingle.md
What is the current behaviour?
Warnings are emitted for the use of .Single() in LogProjectUtils
What is the new behaviour?
The warnings are suppressed.
In this case the use of Single is appropriate since we're asserting that there is only one of the queried value at the same time as the query.
What issues does this resolve?
None
What PRs does this depend on?

None

Does this introduce a breaking change?

[ ] Yes
[x] No

Huh, weird warning

Yea it's a bit heavy handed imo but the potential performance impacts are valid vs .First()


Add option to install old cellery vm when creating local setup

Add option to install old cellery vm when creating local setup

Codecov Report

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

@@           Coverage Diff           @@
##           master     #652   +/-   ##
=======================================
  Coverage   66.82%   66.82%
=======================================
  Files          36       36
  Lines        1248     1248
  Branches      108      108
=======================================
  Hits          834      834
  Misses        375      375
  Partials       39       39

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 f61429e...6f1bcd9. Read the comment docs.


python312Packages.dissect: 3.16 -> 3.16.1

Diff: https://github.com/fox-it/dissect/compare/refs/tags/3.16...3.16.1
Changelog: https://github.com/fox-it/dissect/releases/tag/3.16.1
Description of changes

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] 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/)
24.11 Release Notes (or backporting 23.11 and 24.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

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

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

4 packages built:

python311Packages.dissect
python311Packages.dissect.dist
python312Packages.dissect
python312Packages.dissect.dist


Add basic disjoints support for Elk

From<EMAIL_ADDRESS>on January 09, 2012 21:22:16
See
<a href="https://groups.google.com/forum/#!topic/elk-reasoner-discussion/w7w75WYfUNo" rel="nofollow">https://groups.google.com/forum/#!topic/elk-reasoner-discussion/w7w75WYfUNo

It would be useful to have this in Oort and in TG until full Elk support comes. This could go in a generic library of ontology transformations.
Original issue: http://code.google.com/p/owltools/issues/detail?id=29

From<EMAIL_ADDRESS>on September 18, 2012 15:27:50
Elk supports disjoints now
Status: Invalid


fsck: Orphan entries while filer.copy running

Describe the bug
When running weed filer.copy (per the recommendation) and then volume.fsck it's returning orphans for already split files as the file entry has not been committed yet. This results in data loss when using the -reallyDeleteFromVolume option.
System Setup

5.4
unknown command: version | version 30GB 2.85 19555385 linux amd64

enabled = true
dir = "/data/filerldb2"```
Expected behavior
No data loss.
Additional context
There doesn't appear to be a way to configure volumes or anything with the k8s operator, so I've written my own deployment. Filer fails to deploy properly because the index is locked by the other rs. Additionally it's pretty painful to use something like k8s with seaweedfs because you cannot specify which filer.toml to use.

Is the volume.fsck run after the weed filer.copy, or at the same time?

Same time.

Not good to run it at the same time, with the reason as you described.
Maybe later an "age" setting can be added to skip volumes too close to current timestamp.

From what I'm seeing (I'm only like 3 hours into code - so pretty fresh) it looks like this is never a safe operation if there are any clients connected. I agree with the expert tag on the flag, however the documentation seems to indicate that removing the entry is as good as a deletion (from an encryption perspective). Running fsck twice does not guarantee the same operation, and as such is never safe to run in its present state.
This is my completely naive understanding of it.

This should have been fixed with the above 2 PRs.


Add BG translations for documentation, mix-tasks and mix

Just adding mix, mix-tasks and documentation translations.

@agit0 off the top of my head I am not sure, do we have an issue open for this translations? Just wanna ensure its updated/accurate and didnt see a reference.

@ybur-yug whoopsie, yep there is an issue, just forgot to add it here(updated it though): https://github.com/doomspork/elixir-school/issues/691

Thank you @AgIt0!


Frontend Release: cherry-pick-into-prod-beta

Frontend Release: cherry-pick-into-prod-beta  :boom:
This PR will push the fix to below bug into prod-beta
RHCLOUD-26437 - Remove async lifecycle hook for ROS Details route.
(cherry picked from commit e0fc43293bf0ac05fc528f5841536cd6dd25ec65)
Why do we need this change? :thought_balloon:
For ROS frontend release
Documentation requires update? :memo:

[ ] Yes
[ ] No

Security Checklist :lock:
Upon raising this PR please go through RedHatInsights/secure-coding-checklist
:guardsman: Checklist :dart:

[ ] Bugfix
[ ] New Feature
[ ] Refactor
[ ] Unittests Added
[ ] DRY code
[ ] Dependency Added

Additional :mega:
Feel free to add any other relevant details such as links, notes, screenshots, here.

Codecov Report
Patch coverage has no change and project coverage change: -0.07 :warning:

Comparison is base (6f4fcb3) 17.81% compared to head (acdc79a) 17.74%.

:exclamation: Current head acdc79a differs from pull request most recent head fa60c35. Consider uploading reports for the commit fa60c35 to get more accurate results

Additional details and impacted files
@@              Coverage Diff              @@
##           prod-beta     #251      +/-   ##
=============================================
- Coverage      17.81%   17.74%   -0.07%
=============================================
  Files             39       39
  Lines            814      817       +3
  Branches         147      148       +1
=============================================
  Hits             145      145
- Misses           619      621       +2
- Partials          50       51       +1

Impacted Files
Coverage Δ

src/Routes/RosSystemDetail/RosSystemDetail.js
0.00% <0.00%> (ø)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

/retest

/retest


Ability to add values to grafana ingress

This already exists for Prometheus and Alertmanager (under helm).  I also need ability to sign labels for Grafana ingress as we are moving to using traefik ingress.

@gianrubio my bad, should be all good now.  Thanks!

thanks @bradenwright


Add all DPE crates to a workspace

Make a common workspace to make it easier to format/build all code at once.
Set the rust version to a common version to ensure the same compiler is being used locally and in CI.

Have you tried this as part of the caliptra-sw repo? I've heard of problems with nested workspaces.

I fixed this warning in openssl.rs (found in cicd job logs) and tried to build locally
error: length comparison to zero
  --> crypto/src/openssl.rs:23:25
   |
23 |         let e_code = if s.len() > 0 {
   |                         ^^^^^^^^^^^ help: using `!is_empty` is clearer and more explicit: `!s.is_empty()`
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#len_zero
   = note: `-D clippy::len-zero` implied by `-D warnings`

The Rust build completed with warnings. The Go tests failed as simulator was not built.
# all "cargo build" , "clippy build", "cargo test" commands in ci.sh are giving this warning
unused manifest key: bin.0.target

I have never seen this warning earlier when CICD was working. Is it because of this warning simulator is not available at  ../simulator/target/debug/simulator?

LGTM as long as it works with caliptra-sw

Confirmed that this works. The DPE crates are already explicitly excluded from the Caliptra workspace, so there's not really any nesting.


Java 10 support ?

Yes as Java 10 is already out do we have any plans for it ?

@anapsix I'd like to work on this. Not sure exactly how to go about it.

@kouky, thank you for enthusiasm.
take a look at generate_dockerfiles.sh. Java 10 has a different versioning format, for it would look like 10.0.2-13-19aef61b38124481863b1413dce1855f. Changes to the script would need to be made to be able to deal with changed format.
You might need to add new template specifically for Java 10 JRE/JDK, as it might need to be customized in what extra libs can be removed to slim down the image, etc.
Perhaps refactor templates: one template per version (7 vs. 8 vs. 10), and not type (jre vs. jdk).

this is unlikely to happen with current Oracle Java licensing terms (see #82)


write CompactContractBytecode instead of CompactContract

Motivation
The existing CompactContract doesn't have enough information for our needs in foundry. So we write out CompactContractBytecode instead which is a slightly stripped down version of ContractBytecode. The reason to strip it down is because we lose a decent amount of performance if we write all the other things in ContractBytecode. This is a compromise between speed and the needed information.
Solution
Write CompactContractBytecode instead of CompactContract
PR Checklist

[ ] Added Tests
[x] Added Documentation
[ ] Updated the changelog

still fails to compile due to changed types.

wdym? compiles fine for me?

looks like a doc-test https://github.com/gakonst/ethers-rs/runs/4952579664?check_suite_focus=true#step:9:539

oh ye the test fails, but it compiles okay


Update link-icon-svg.json to new Safari 9 note

Apple dropped non-standard mask attribute and now provide support for more issueless, non-standard rel="mask-icon", so description and link update.

@marsjaninzmarsa Thanks, looks like you didn't escape the quotes in the new text though.

@Fyrd right, fixed, I'm used to single quotes in JSON.

Thanks!

np. :smiley:


[Label] ARIA issue detected by Lighthouse

Bug report
Hi, I'm using the <Label> component on my site and Google's Lighthouse detected an ARIA issue with it. I wasn't sure if it is how I'm using it or intrinsic to the component itself, so I ran Lighthouse on the docs page for <Label> and got the same result.
Current Behavior
Lighthouse detects an ARIA issue with <Label>.
Expected behavior
<Label> should pass all Lighthouse ARIA tests.
Reproducible example
Run Lighthouse on the docs page: https://radix-ui.com/primitives/docs/utilities/label
Additional context

@rafgraph you might be interesting in the new changes I'm working on here https://github.com/radix-ui/primitives/pull/672
This improves the native label accessibility so now, the only real reason to chose the custom label once this is merged would be because it avoids this unnecessary text selection on click:

I'm contemplating updating our Label component to use the native label now that we have these improvements which would have the added benefit of silencing your lighthouse errors.


Update link to Red Hat Architecture

This is an automated message:
You can preview this docs PR at http://450.docs-pr.validatedpatterns.io
Note that they get generated every five minutes, so please wait a bit.

/ok-to-test


Possible to run server side blocks on a cluster?

This proposal seems quite similar to the Swift Distributed Actor one: https://github.com/apple/swift-distributed-actors
It though, rather than being geared towards just something like WebWorkers, is also geared towards executing the distributed actors outside of the local machine and across a cluster of machines.
From the browser perspective executing stuff elsewhere but locally  wouldn’t make sense, but from a server side perspective (Node.js, Deno and such) it could make equal sense to go beyond the local I machine as it does for Swift to do so.
The challenge that Web Workers and such require separate files to be loaded is also something that somewhat exists in the serverless function space (AWS Lambda and such) and could benefit as much from being able to define such functions online and then on execution time schedule and run those on a defined cluster.
I do realize that the specific logic for how to run something on a cluster would be out of scope for this proposal (just like it is out scope of the Swift Distributed Actor one) and would require a transport like https://github.com/apple/swift-distributed-actors to be built to do the scheduling of module blocks across a cluster.
What I do am wondering though is whether this proposal is written in a way that would facilitate such a mechanism and whether it is in line with the intention of this proposal or whether it should be seen as something module blocks would not be intended to be used for?
Original Twitter thread where @surma mentioned this proposal to me: https://twitter.com/voxpelli/status/1459127412860542976?s=21

The challenge that Web Workers and such require separate files to be loaded

Nowhere near as clean and developer-tooling friendly as module-blocks but it is possible, in some situations, to run a worker without a separate file:
new Worker(`data:text/javascript,console.log('hi')`)
// 'hi' logged from worker thread

It's not a perfect analogy by any means, but imagine module-blocks as a special type of string that can only contain valid JavaScript. Now we can be sure when sending this 'string' to another realm/thread/process/machine to run - it was at least syntactically valid. So I don't think they necessarily provide a way to run code in a way that we couldn't before, but they do make for a much more robust and friendly experience.

imagine module-blocks as a special type of string that can only contain valid JavaScript

That + the fact that its javascript is never allowed to reference anything in its outside scope, which eg. the content of a toString() on a function would? And thus making it much more likely for such a function to be possible to launch in a totally separate context, right?
Also:
There is a Use with workers and such in the README, all being client side uses, would love for a non-client use to be documented as well, to show if the spec is meant to be used for use cases outside of those.

There is a Use with workers and such in the README, all being client side uses, would love for a non-client use to be documented as well, to show if the spec is meant to be used for use cases outside of those.

It can't really help out of the box as even with .toString() there is no way to know what a relative specifier (i.e. import "./some/relative/url.js") would refer to when stringified. Like if you create the module block yourself it's fine as you can use import.meta.url but if you got a module block returned from a function, the actual module that this block came from might be completely unknown.
Although it does beg the question, should we have a meta object on module blocks that store this information? If we did you could just serialize both the module block (using .toString()) and the .meta object to know the base url i.e.:
const moduleBlock = module {
    export default class Foo {}
}

moduleBlock.meta.url; // whatever the import.meta.url of the module block would be

Whether or not people want to expose that information on all module blocks is another question, sometimes it's arguably a refactoring hazard or with ShadowRealms potentially a security hazard.

I think anything cross-engine is out of scope for this proposal for now. But maybe a future proposal can bring this capability to JS.


Try to upload mapsui nuget packges to nuget repository

Try to upload nuget packages to the nuget repository so that every pull request can be downloaded in a nuget feed.

It seems because the checkin would upload the build NuGet Packages to Github NuGet Package Registry
It isn't executed

My understanding is that the objective is that every PR by everyone will result in a nuget package hosted in the Mapsui nuget repository.
I am not convinced we should do this. Reasons:

It is hosted in the Mapsui repository, so the Mapsui project has some responsibility in this but it has not been reviewed while everyone can use the nugets. It does not seem right.
I don't see how this could work with respect to version numbers. Usually you would want to use the latest nuget. The version number determines which nuget is the latest. If nugets are pushed from master and from branches how should te version be determined?

Are there github repositories which do something like this?

I thought about it and I agree. There are some repositories that make nightly builds of main available as a nuget Repository on myget. Bit this is not free so I wanted to test it if it works on github Repository and then decide if it is worth it. But I think my change would stop building pull requests on github actions. So I would have to introduce a 4 th task to generate the packages on approved checkins. So I'm closing this.


Add inTopK op

FEATURE
This PR add inTopK op, which behaves the same way as tf.math.in_top_k in TensorFlow. This op help develop further metrics which depend on inTopK operation, such as, topKCategoricalAccuracy (feature requested in tensorflow/tfjs#27 ), sparseTopKCategoricalAccuracy (feature requested in tensorflow/tfjs#26). Relative PR tensorflow/tfjs-layers#537
This PR:

Add new inTopK op to src/ops
Register inTopK in src/ops/ops.ts
Add inTopK kernel to backend
Add shared inTopK implementation between webgl and cpu
Add relative tests for inTopK

Reference:

TensorFlow in_top_k doc
TensorFlow in_top_k implementation
TensorFlow in_top_k test cases

This change is

Hi @nsthorat , it seems that in backend_cpu, this.readSync is widely used to synchronously read data, so I replaced the previous .dataSync() with this.readSync, and all tests passed. While in backend_webgl, the .dataSync() still exists in nonMaxSuppression, floatPrecision, where, topk, if you figure out how to solve this synchronous call, please let me know, I would apply your way to fix it.

I'm going to merge this and send a follow up to remove this as a kernel, apologies. This will be fine for now.
Thanks for the PR!


Build randomly fails when output format is imported from a Hugo module

There appears to perhaps be an edge/race condition in Hugo causing both hugo and hugo mod clean --all to randomly fail on a site when the output format is imported from the config of a Hugo module, resulting in a single error like
Error: from config: failed to resolve output format "WebAppManifest" from site config

To reproduce, create a Hugo module with an index.webmanifest layout and the following config:
mediaTypes:
  application/manifest+json:
    suffixes: [webmanifest]
outputFormats:
  WebAppManifest:
    mediaType: application/manifest+json
    rel: manifest

Then create a site which imports that module (including its config) and loads that module's output format
outputs:
  home: [ "HTML", "WebAppManifest" ]

Running any hugo command will randomly fail with the above error message. May be related to cache issues when a user attempts to update the module?
hugo mod clean --all also then fails to delete the cache
Is it expected that hugo mod clean --all fails when Hugo cannot build a site? Can we not prevent the cache deletion command failing by just deleting the contents of Hugo's cache folder without attempting to build the site?
Workaround
After manually deleting Hugo's cache folder, the Hugo commands work fine again without any changes to the code.
What version of Hugo are you using (hugo version)?

$ hugo v0.83.1+extended darwin/amd64 BuildDate=unknown

Does this issue reproduce with the latest release?
Yes

I wonder if this could not be caused by branch switching in git after having upgraded the module etc...

While looking at something else, I notice that we "swallow" an error when loading the configuration from the modules. I will fix that. Which goes to say that the above would still fail, but with a more relevant error.

I am unable to reproduce this with v0.124.1.
git clone --single-branch -b hugo-github-issue-8591 https://github.com/jmooring/hugo-testing hugo-github-issue-8591
cd hugo-github-issue-8591
rm -rf public && hugo && tree public

Then run the last command repeatedly. There are no failures.

Closing per previous comment.


Provide utility methods for Futures: getDone, checkSucceess

getDone is an unchecked variant of Guava's Futures#getDone
checkSucceess is equivalent to getDone but does not return value
and conveys intent better, if the caller is interested in just that

Moved to airlift from https://github.com/prestodb/presto/pull/8166/commits/63ed2fae6020430cb68aa4e78f951b3a562691ab (prestodb/presto#8166).

cc @losipiuk @martint

@dain , would you like to review this?

@dain, i did it a bit differently in order to preserve future's exception
if there is one.

@dain , back to you. (Can't assign because it's airlift)

@dain , tests added

Merged, thanks!


November 2021 Challenge

Proposal for the November  2021 challenge

Thank you, @MaldoAlberto, for this contribution. Since it took me a while to get to this, I'll just go ahead and update it for December.


fix hostname

Signed-off-by: Jaehyun Nam<EMAIL_ADDRESS>

Codecov Report

Merging #706 (631c0ad) into main (418554a) will decrease coverage by 0.83%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #706      +/-   ##
==========================================
- Coverage   37.04%   36.21%   -0.84%
==========================================
  Files          25       25
  Lines        8983     8983
==========================================
- Hits         3328     3253      -75
- Misses       5204     5283      +79
+ Partials      451      447       -4

Impacted Files
Coverage Δ

KubeArmor/config/config.go
85.85% <100.00%> (ø)

KubeArmor/monitor/systemMonitor.go
37.89% <0.00%> (-10.91%)
:arrow_down:

KubeArmor/monitor/logUpdate.go
67.72% <0.00%> (-3.99%)
:arrow_down:

KubeArmor/monitor/processTree.go
89.88% <0.00%> (-3.38%)
:arrow_down:

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 418554a...631c0ad. Read the comment docs.


chore(deps): update common-dev-assets digest to 4ad928f

This PR contains the following updates:

Package
Update
Change

common-dev-assets
digest
6c83209 -> 4ad928f

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Renovate Bot.

:tada: This PR is included in version 2.3.2 :tada:
The release is available on:

GitHub release
v2.3.2

Your semantic-release bot :package::rocket:


Improve preview pane appearance

Dynamically changes the styles depending on if there is a replace text value, as VS Code does:
https://github.com/yassinebridi/serpl/assets/47499684/9f6083c8-e72e-4e46-9370-e60012a5eb1d

It was difficult to figure out how to display selected lines but I've gone for bold modifier here. I think it is still not quite visible enough as selected so I'm curious to hear your thoughts on how that can be improved.

I love this, it's visually much better to use the blue highlight instead of red when the replace input is empty.
About the bold choice, this actually fixes another issue where the select highlight color always overlaps the replace text background color, so using a bold styling is better imo.
Thanks for this PR, and thanks for fixing the clippy issue ^^

Thank you for merging! Really loving this tool, been looking for something like this to complete my transition to editing fully in the terminal instead of back and forth with VS Code and Neovim :D

This was the missing piece for me too, glad you like it!


Real position in camera space

Excellent work. Does this approach accurately provide the actual 3D positions of the SMPL model? For instance, methods like 4D-humans and Pymaf are known to be imprecise in outputting depth information. Could you recommend an advanced approach for achieving real position 3D human reconstruction utilizing monocular video footage? Your expertise and insights on this matter would be immensely appreciated.

Thanks for your question. W-HMR is more concerned with pose correction in world space and mesh-image alignment for precise training. You can check out the following works https://liuyebin.com/proxycap/, https://github.com/vye16/slahmr and https://github.com/IDEA-Research/Motion-X. They may help you.

非常感谢您的回复。我面临的一个难题是：重建具有真实绝对位置的SMPL，而不是相对位置。您提到的slahmr--它是通过优化的方式来解耦相机，虽然可以获取人体的真实绝对位置，但此类后优化的方法，无法修改为实时的方案。而我想要一个能够实时运行的捕获真实绝对位置的人体重建方法，目前想到的是通过身高进行简单的后优化，但这过于简单。您方便的话，我想加您的微信，向您请教一下，我将不胜感激，我的微信是：Weafree


Refactor Presentation XML for terms

Continuing https://github.com/metanorma/isodoc/issues/610
The refactor needed most urgently for the preservation of Semantic XML under Presentation XML is the refactor of how terms are handled. This is a precondition for us to remove the duplication of Semantic XML under Presentation XML, since it was terms Semantic XML that @Intelligent2013 needed to access, that led to him requesting it for Presentation XML.
Terms render Semantic XML in a multitude of ways depending on flavour, each of them currently implemented destructively wrt Semantic XML. The constants across flavours for rendering are:

Content may be rendered as a standalone block, or as part of another block. In Presentation XML, we will realise fmt- blocks for the  required blocks, and we will use inline semx to relate content rendered inline in a block, back to its source Semantic XML.

For example, in some flavours, the designation is rendered as a separate header paragraph. In others, it is rendered inside  the same block as the definition.

The following is the maximum possible of rendered blocks; any of them (but one) can instead be inline in another block.

There is a term name, the number of the term.
There is a term primary designation.
There are secondary designations, alternative and deprecated.
There is term metadata, such as grammatical information, term cross-references or domain. (This is usually rendered inline with either the designation or the definition.)
There is the definition.
There are term examples and term notes.
There is a term source.

Of these, only the definition, term examples, and term notes are universal across flavours as a rendering block. Even the definition can be severely manipulated: ITU conflates multiple definitions inline into the one paragraph.
Term examples and term notes are the only block from Semantic XML which (as far as I can tell) is not rearranged when rendered as Presentation XML.
Implementation will therefor involve leaving untouched all Semantic XML content, as this refactor intends, and rendering the term example and term notes as read from the Semantic XML. All other Semantic XML term elements are to be ignored, and rendering will involve at least one of the following Presentation XML fmt- elements, which replicate, rearrange, and link back to Semantic XML content:

fmt-name (already done)
fmt-preferred
fmt-alternative
fmt-deprecated
fmt-related-term
fmt-term-metadata (may refine, I'm not sure it appears as a standalone paragraph anywhere)
fmt-definition
fmt-source

Done base terms refactor, although have not yet done concept markup; that is not urgent.


passed clientOptions and authorizationUrl to @slack/oauth

Summary
passed clientOptions and authorizationUrl to @slack/oauth.
Exported interfaces from @slack/oauth and everything from @slack/types.
Added npm run watch command that uses nodemon to rebuild the source on every change.
Issue: #585
Requirements (place an x in each [ ])

[x] I've read and understood the Contributing Guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.

This needs https://github.com/slackapi/node-slack-sdk/pull/1081 to be merged and released first


Removes Icon props from Button

Issue number: #328 | #337
This PR does the following:

Makes Button's onClick property options
Removes all icon props from Button. Button now uses Icon as a child

Front End Review:

[ ] View the example in Storybook

What's the difference between the search and search_small icons? Possibly for a different ticket.

What's the difference between the search and search_small icons? Possibly for a different ticket.

These both exist within the Figma library and should probably be cleaned up. (A holdover from moving to Google Material Design icons.) The original thinking is that you'd use "small" (which is thicker) on dark backgrounds or in smaller locations... but I think we should eliminate it, it's just confusing. That said I agree that it's a separate ticket since it includes a conversation with Kathy


Heredocs can create Interpolated(X)StringNodes or (X)StringNodes

Prior to this commit, heredocs were automatically InterpolatedNodes regardless of whether there was actually interpolation. With this commit, heredocs are only interpolate if there is actually interpolation
Closes #1414

Sorry I haven't gotten a chance to look at this yet, but I will first thing next week!

@jemmaissroff just needs a rebase


Added VK_KHR_pipeline_executable_properties extension support.

BTW, what do you folks think about adding small documentation to extension types (like this PipelineExecutableProperties) as they are implemented by people, not autogenerated? Link to the corresponding page in the Khronos registry at least, but as for me small code examples would also be nice. Or this crate was designed to be super-dry?

BTW, what do you folks think about adding small documentation to extension types (like this PipelineExecutableProperties) as they are implemented by people, not autogenerated?

My overall plan is to auto generate all the extensions in the future which would include the docs, but I haven't had much time to work on it.


PHPLIB-461: Fix functional tests for change streams on sharded clusters

https://jira.mongodb.org/browse/PHPLIB-461
Due to the way getMore works on sharded clusters, we can't rely on the first getMore call after an insert to return the data we expect. I'll quote the response from the query team to my questions about why getMore behaves this way.

First, it will be useful to understand the semantics of getMore on a tailable awaitData cursor such as that created by $changeStream:

If there are documents available when the getMore starts running, then getMore will read up to batchSize OR EOF, whichever comes first. It will then return immediately without waiting for any further results.
If there are no documents available when the getMore starts running, it will wait up to the specified awaitData timeout to see if any documents become available.
If documents become available while the getMore is waiting, it will adopt the behaviour outlined in (1). In other words: once the getMore has obtained at least one result, it cancels its awaitData timeout and does not wait again.

The second thing to understand is the behaviour of change streams in a sharded cluster. For reasons outlined in this comment, change streams must open a cursor on every shard even when monitoring an unsharded collection. Because each change stream is globally-sorted, it cannot return result A from shard X until it has obtained at least one result from every other shard that sorts later than result A. In other words, it cannot return A to the client until every other shard has promised that they will never produce a result that sorts before A. To guard against the possibility that one or more shards never return any results, each shard has a no-op writer that updates its oplog every periodicNoopIntervalSecs seconds. This allows the shard to return a high-water-mark promising that it will never return a future result which sorts before that point, so we are guaranteed that the change stream will eventually be allowed to return result A to the client.

With an maxAwaitTimeMS of 500 ms we stay below the minimum periodicNoopIntervalSecs of 1 second, which can cause our getMore commands on shards without data to time out before a no-op is read from the oplog. One way to solve this would be to increase the maxAwaitTimeMS to a value above 1000 ms to ensure that getMore calls don't time out before another no-op is written, but this causes tests to be significantly slower. Furthermore, we should never make any assumptions as to what batch a change stream event is returned in, only that it will eventually be returned in the correct order. To ensure the tests don't unnecessarily fail on sharded clusters, they will now execute multiple getMore calls if necessary, only failing if a given number (currently 5) of getMore calls fails to return any data. This was also necessary since resume operations would still yield empty batches on the initial call to aggregate.
This PR also contains a workaround for PHPC-1419, where a NonResumableChangeStreamError error label is not applied to the ServerException create for a ChangeStreamFatalError. This causes the iterator to repeatedly retry resuming the change stream for an unresumable error. This workaround can be removed once the above issue was fixed.

Note: build failure is because of a segmentation fault. I highly suspect it's for the same reason that @jmikola is investigating in #638.

Review feedback addressed in separate commit. I'll squash once the build is stable and after updating to a newer driver release that fixes PHPC-1419.

@alcaeus: Regarding the unexpected passing builds despite the lingering double-free issue (PHPLIB-432), I noticed that the job for this most recent, passing build ran on PHP 7.3.9 (built August 30). IIRC, previous failed builds were using 7.3.2 (built February 11).
I wasn't able to find the Travis build history for the branch you were using to research this issue, but you may want to check that to see if your recently passing builds also display a new version. If so, it's possible this was fixed upstream; however, I don't see anything in https://github.com/travis-ci/travis-ci/issues or https://github.com/travis-ci/php-src-builder to suggest it was an intentional fix.

I'm still observing the failure on PHP 7.3.9, see the most recent build log for example: https://travis-ci.com/alcaeus/mongo-php-library/jobs/231388623#L239. This branch was rebased to pull in latest changes from this PR, which interestingly enough no longer shows this behaviour, neither in the PR build on travis-ci.org nor in my branch build on travis-ci.com. I was afraid that the behaviour might only exhibit itself on travis-ci.com (since that uses different infrastructure IIRC), but that doesn't seem to be the case either.
Restarting the build a couple of times did not bring those failures back, so I'm even more at a loss than before.

@jmikola it looks like #694 got rid of the use-after-free issue we were seeing on previous builds. I re-ran the offending builds multiple times and was no longer able to provoke that behaviour.


typo on pathMaches()

There is a typo it seems, tried submitting a pull request, travis build failed.
    public function register()
    {
        /** @var \Illuminate\Http\Request $request */
        $request = $this->app['request'];

        $this->app['config']->package('barryvdh/laravel-cors', realpath(__DIR__ . '/config'));

        if (!$this->pathMaches($request)) {
            return;
     }

Fixed in https://github.com/barryvdh/laravel-cors/commit/18c001f97d1553e46ce2bcba40ab2fa7f650e29a


Spring Boot 3 Demo Application Source Code

Where can I find the source code to the running applications from the documentation for Spring Boot 3?:
https://springdoc.org/v2/#springdoc-applications-demos

This is the link https://github.com/springdoc/springdoc-openapi-demos/tree/2.x
docs will be updated accordingly


Adding webhook to e2e tests with kind, moving deploy to gateway-system namespace

What type of PR is this?
/kind cleanup
What this PR does / why we need it:
This PR includes 3 related changes:

Moves webhook deployment from gateway-api to gateway-system
Adds webhook deployment as part of kind e2e verification tests
Adds invalid examples that are only covered by webhook validation

Which issue(s) this PR fixes:
Fixes #1040
Does this PR introduce a user-facing change?:
The Gateway API webhook is now deployed in a `gateway-system` namespace instead of `gateway-api`.

/lgtm


Make configuration callbacks consistent with config source precedence

A client had noted that when passing NEW_RELIC_ERROR_COLLECTOR_IGNORE_ERRORS to a Ruby application, this value was overwritten by server-side config values for error_collector.ignore_errors. Investigation revealed that certain config settings would use environment variables over server-side configs, but others would not. This was reproducible in local testing.
A possible cause for this lies in the way some parts of the agent code fetch config values. Whenever a config source - e.g. ServerSource, YamlSource, EnvironmentSource - is loaded, the agent invokes NewRelic::Agent::Configuration::Manager#replace_or_add_config on that source, which passes its values to any callbacks for each config setting that's been defined. For example, ErrorCollector registers this callback on setup:
Agent.config.register_callback(:'error_collector.ignore_errors') do |ignore_errors|
  initialize_ignored_errors(ignore_errors)
end

What this means is that whenever a config source is loaded, this callback will be called with ignore_errors being the value given by error_collector.ignore_errors in that source. The initialize_ignored_errors method will then populate an @ignore variable based on this value.
Where I think we're hitting trouble is the fact that server configs are loaded after other sources initially, and then again whenever the server-side config changes. This causes the agent to overwrite whatever may have been set in the environment by what is provided by the server. This is not consistent for all configuration settings - it depends on how the agent checks the value of any particular setting. For example:
def distributed_tracing_enabled?
 NewRelic::Agent.config[:'distributed_tracing.enabled']
end

Helper methods like this will always check the configuration cache, which observes the config precedence stack. However, a registered callback like the one above will only set its relevant value once on loading, bypassing precedence.
I had some discussion with the Ruby Agent team about this. The question arose of whether our documentation is wrong, and that we should make server-side config a higher precedence than environment variables - this is already done in other language agents. However, I suspect that our docs are correct, that the intent is that environment variables should have higher precedence, and that over the course of 8 or so years of development, the config event callback system has gotten out of sync with the source precedence system, and that this has been a latent issue since clients aren't as likely to be overriding server-side configs with env variables.
Whatever the intended precedence, we should review the config callback system in place, particularly:
https://github.com/newrelic/newrelic-ruby-agent/blob/dev/lib/new_relic/agent/configuration/manager.rb#L159
A full review of this code and existing callbacks I estimate would take 1-2 weeks of work.
@angelatan2 @tannalynn

Please verify the assessment above with the x-agent spec for Expected Errors and Ignore Error.
Internal Only
Note for the case of Expected errors and Ignore error feature configuration, many of these configurations are not meant to be specified in the environment configuration.

Closing as per Ruby agent dev team discussion today.


Win 10/ IE 11- Election 2016- Mass.Question 4 window overlapping issue

View your issue at Applause Testing Services - https://my.applause.com/u/a#!&view=issues&subview=issues&productId=15105&bugId=2315252
---- ACTION DETAILS ----
Action Performed:

Launch URL as per instruction
Select Election 2016
Scroll down and observe the last window Mass Question 4-Legalize Marijuana
Observe

Expected Result:
No overlap issue
Actual Result:
Text is overlapping in that window
Additional Info:
win 10/ IE 11
URL
http://elections.dev.passenger.bostonglobe.com/elections/2016
Error Code/Message:
---- ENVIRONMENT ----
Language:English ,Operating System:Windows,Web Browser:Internet Explorer 11,Operating System Version:10
---- UTEST PROPERTIES ----
uTest Bug Id: 2315252
Title: Win 10/ IE 11- Election 2016- Mass.Question 4 window overlapping issue
Status: Pending Approval
Type: GUI
Frequency: Every Time
Severity: Medium
Product: Elections (dev)
Test Cycle: Boston Globe Elections Exploratory Cycle
---- UTEST Attachment ----
Bug2315252_overlap.png : https://utest-dl.s3.amazonaws.com/9716/15105/120249/null/bugAttachment/Bug2315252_overlap.png?AWSAccessKeyId=AKIAJVVOIXUIFRTEEEKQ&Expires=1793825512&Signature=CEwYcJIXwCG81MRaOdIrhooGHwI%3D
Bug2315252_overlap.swf : https://utest-dl.s3.amazonaws.com/9716/15105/120249/null/bugAttachment/Bug2315252_overlap.swf?AWSAccessKeyId=AKIAJVVOIXUIFRTEEEKQ&Expires=1793825512&Signature=WaZDt%2FO7443j%2BNU0aU4ubfa058A%3D

this is not an issue in the updated version


Add music list plugin with filtering and search

Can now filter the music list on Unlocked/Locked/All in the same way as already exists for quests.
Also added search functionality for music.
Closes #8473

Do we want this?

The search would be very nice for the new music clues, it's very fiddly trying to scroll to the right track
Would the filtering have the same issue as #8390?

Also fixes https://github.com/runelite/runelite/issues/8601

This functionality was added in #8779


No way, no how on WinXP64

Have tried many times with many permutations to install Msys2 on WinXP64 (all SP's) using msys2-x86_64-20160205.exe.  It almost never even gets to the first step of update-core due to "GPGME" etc errors.

on the rare occasions that it has, any variation of pacman -Su, Syuu etc fails with "GPGME error" "invalid crypto" etc.  (see attached jpg).  Apparently MSys2's databases become "corrupt" and after that it will not work.  One attempt at a solution is to delete the Sync Dir.   This allows a pacman Su etc to work once in the sense that it recreates the Sync dir, but again with "corrupt" db's.

There is no possibility of downloading anything even with Sync deleted, since it must first create Sync for the download, and immediately creates corrupt db's, preventing any further communication with the server.

On some occasions, not idea why, it completely "looses bash", and will not accept any bash commands at all (e.g. pacman).

Have tried various other "fixes" seen on the web (autorebase) etc., no joy.

... couldn't find an WinXP64 specific solutions on the MSys forum
No idea how to proceed, but would desperately wish to have a working WinXP64 install.
PS.  Have tried several times to attach a jpg of a screen print example of the GPGME etc errors, but the blog keeps responding with "Something went really wrong, and we can't process that file".  Trying again doesn't help

Well we not support Win XP 64. Never try it and never test on it.

That's weird, according to Ray Donnelly, an MSys2 developer:
  "We target Windows XP SP3 as a minimum and support both 32bit and 64bit Windows"

as seen here (http://stackoverflow.com/questions/25019057/how-are-msys-msys2-and-msysgit-related-to-each-other).
I actually did some checking before my tests to make sure WinXP was supported, and apparently it is.  Also, on the net, various people discuss using MSys2/WinXP.
So, is Ray Donnelly wrong, or ???
If so, the MSys2 installer should have enough sense to check for Win Ver, and NOT install on incompatible Windows.
Please advise.

Well installer is not working on Win XP at all. Need use turbans to extract base MSYS2. We support Win XP 32-bit. 64-bit Win XP is very rare case and I have not installed it anywhere. If you want support for 64-bit Win XP please dig into problems and provide solution for it.
MSYS2 is free time project so if you want if anything will be fixed soon - spend some time yourself

OK, so:

I am not sure if it's some "language thing", but I don't understand some of the words you are using.  I have no idea what "turbans" are in this context.

As the developers state that WinXP is "targeted", it should be supported.  In the alternative, make it clear on your dload/install pages that your product does not work with WinXP so people don't waste their time with ... and it may help if all the staff at MSys2 "has the same story", rather than the conflicting story unfolding here.

As WinXP is an important platform, we definitely would wish for it to be supported.

As for us to the "dig into problems and provide solution for it".  We have spent many man hours trying to get it to work, so far all that time is a waste.  The problems with MSys2 seem to "deep in its bowels", and we have no access to, control over, or knowledge of why it throws GPGME errors, and why it insists on corrupting its own databases, which are managed with proprietary and inaccessible machinery in MSys2.

I should say that also, while it may not be intended, your responses seem to come across a bit confrontational and unhelpful.  At the very least, you might provide information on how one would even approach a "solution" to the stated errors.  Perhaps Ray Donnelly or somebody might be asked to respond.

@DrOli: For what it's worth, there is more information about GPGME errors here: https://github.com/Alexpux/MSYS2-packages/issues/393   I have never encountered that error personally.

@DrOli, sorry some words are wrongly written by autocompletition here.
turbans - tarballs

Based on DavidEGrayson's suggestion, I performed all that I could from that link, with the errors as described below:
completely removed MSys2
Follow instructions from https://github.com/Alexpux/MSYS2-packages/issues/393
no MacType anywhere
no gnupg anywhere
had cygwin/cygwin terminal installed, so just in case, uninstalled that (not a simple process)
... from BLODA, I have no software installed that is on their "conflict" list
rebooted
clean install MSys2, following the EXACT instructions from (https://msys2.github.io/)
gpgme errors all over the place, so, (David's suggested link)

Try re-installing gpgme libgpgme, gnupg and pacman packages (you can temporarily disable signature checking in /etc/pacman.conf)
... no joy.

Try removing /etc/pacman.d/gnupg, then pacman-key --init, pacman-key --populate msys2, pacman-key --refresh-keys.

... the first two steps appeared to go OK, but he last step produced and ERROR, as per:
$ pacman-key --refresh-keys
gpg: refreshing 8 keys from hkp://pool.sks-keyservers.net
gpg: requesting key 3E058AFD from hkp server pool.sks-keyservers.net
gpg: requesting key CA25678A from hkp server pool.sks-keyservers.net
gpg: requesting key AEEA755C from hkp server pool.sks-keyservers.net
gpg: requesting key 3E0D0813 from hkp server pool.sks-keyservers.net
gpg: requesting key 3E652008 from hkp server pool.sks-keyservers.net
gpg: requesting key A47D45A1 from hkp server pool.sks-keyservers.net
gpg: requesting key 2C51581E from hkp server pool.sks-keyservers.net
gpg: requesting key 4CA56930 from hkp server pool.sks-keyservers.net
gpgkeys: key 6EB171030F67EB34A071054739D5AE203E058AFD not found on keyserver
gpg: DBG: armor-keys-failed (KEY 0x6EB171030F67EB34A071054739D5AE203E058AFD BEGIN
) ->0
gpg: DBG: armor-keys-failed (KEY 0x6EB171030F67EB34A071054739D5AE203E058AFD FAILED 6
) ->6
gpg: key CA25678A: "Alexey Pavlov (Alexpux<EMAIL_ADDRESS>4 new signatures
gpg: key AEEA755C: "Martell Malone (martell<EMAIL_ADDRESS>3 new signatures
gpg: key 3E0D0813: "Ray Donnelly (MSYS2 Developer - master key<EMAIL_ADDRESS>2 new signatures
gpg: key 3E652008: "Ignacio Casal Quinteiro<EMAIL_ADDRESS>2 new signatures
gpg: key A47D45A1: "Alexey Pavlov (Alexpux<EMAIL_ADDRESS>1 new signature
gpg: key 2C51581E: "Martell Malone (MSYS2 Developer<EMAIL_ADDRESS>not changed
gpg: key 4CA56930: "Ray Donnelly (MSYS2 Developer<EMAIL_ADDRESS>2 new signatures
gpg: Total number processed: 7
gpg:              unchanged: 1
gpg:         new signatures: 14
gpg: keyserver communications error: key not found
gpg: keyserver communications error: bad public key
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   4  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   4  signed:   3  trust: 0-, 0q, 0n, 4m, 0f, 0u
gpg: depth: 2  valid:   3  signed:   0  trust: 3-, 0q, 0n, 0m, 0f, 0u
gpg: keyserver refresh failed: bad public key
==> ERROR:
... this probably will make the rest of tests meaningless, but continue with rest of

Maybe autorebase.bat is sometimes needed even for 64-bit MSYS2.

... restarted Msys2, update-core --> gpgme error as usual

Try debugging for GPGME by export GPGME_DEBUG=9 before running pacman ...something... 2> ~/gpgmelog and looking at the logfile ~/gpgmelog

... try pacman -Syuu 2> ~/gpgmelog and looking at the logfile ~/gpgmelog
... the log file contains:
error: GPGME error: Invalid crypto engine
error: GPGME error: Invalid crypto engine
error: GPGME error: Invalid crypto engine
error: GPGME error: Invalid crypto engine
error: failed to update mingw32 (invalid or corrupted database (PGP signature))
error: GPGME error: Invalid crypto engine
error: failed to update mingw64 (invalid or corrupted database (PGP signature))
error: GPGME error: Invalid crypto engine
error: failed to update msys (invalid or corrupted database (PGP signature))
error: failed to synchronize any databases
error: failed to init transaction (invalid or corrupted database (PGP signature))
... OK, so what do I do now?

There are no staff at MSYS2 nor is there anything proprietary. It is entirely open source and done in our spare time.
For supported operating systems, we do our best to not break support for what we claim to support, which is 32 bit xp sp3. Windows xp 64 is a very unusual beast indeed and since none of us have it installed we can't really make any guarantees that it runs on that operating system.

Dear MR Donnelly
Thank you for the clarification, though I am not sure if it gets us to the next step.  However, a couple of items before "the next step", which I leave for last.

I am not sure why you have taken issue with the word "staff", a standard dictionary definition includes "The personnel who carry out a specific enterprise", and so my usage is perfectly accurate.  Nevertheless, I am happy to change to the word to "team" or any other reasonable choice you may suggest ... but I wonder if this is the sort of thing our time should be spent on.

"Proprietary":  The GPGME errors are accompanied by expressions like "invalid or corrupted database".  We tried to assess the db's in our efforts to determine the "corruption", but could not find any db machinery in our possession that could open those files.   It is in this sense that I used the word proprietary, since the MSys2 db's did not seem accessible by any standard db mechanism at our end.  Again, I am happy to change the semantics.

WinXP 64:  Would you agree that your comment on StackOverflow:

"We target Windows XP SP3 as a minimum and support both 32bit and 64bit Windows"
is reasonably interpreted as including WinXP64?   And as such, would invite investment into the process on that expectation.  Apparently, based on what you say now, that should have been appended with something like "except WinXP64" ...  though now after considerable investment by us.

As indicated in my previous submissions, we had CygWin64 already installed and working.  We un-installed it based on the  possibility of a conflict, as implied by link #393

I don't know what "#msys2 channel on the oftc irc network" is, but I'll look into it.

Be that as it may, I wonder if our time would be better spent on actually getting this thing to work.  Thus far, we have invested in excess of 70 man-hours testing a vast number of permutations and variations, and with little help from your team.  There are a quite a number of places where your team invites/encourages the public to test/report etc etc.  Well, we've been doing just that.
... and in our case, it is not simply "in our spare time", it is also on "company time", and so that means REAL cash has been spent (based on the expectation that WinXP64 was supported, as per your earlier statements).
We are not sure why your team cannot explain or otherwise assist with tracking down why this thing is throwing GPGME/corrupt database errors, or why it can't get the public key right, etc, etc as per our reports.  As it's your code, one would imagine you might know where and why in the code these error's are thrown ... at least to the point to allow some testing, even just to get to the "boundaries".
Your response follows exactly one of those detailed detailed/test reports I submitted, with logs, error messages, etc.  We are not sure why your team could not respond to that in any specific way.
Clearly, we are prepared to invest time in this process, but we are "math geeks" (not "IT geeks"), so a little help pointing us in the right direction would be appreciated ... we are happy to give you our time, but "throw us a bone" now and then :-)
... in the alternative, if you are now simply "throwing us to the dogs", and after those invitations/encouragements to invest time/resources, I think MSys2's reputation/credibility will, quite correctly, take a hit.
Cheers
DrO
PS. I am a little surprised that you would be willing to support Vista64 and not XP64, when Vista is commonly accepted as one of the greatest software abominations in recorded history.  Indeed, as XP64 is really just a variation of Server03, would you need to update your "support commitment statement" to only non-server Windows variants?
And, while no offence is intended, and while I appreciate the issue of "scarce resources/time", it seems somewhat odd to hear that your team can't get their hands on a copy of WinXP64.  Even just amongst us "math geeks", we have access to/saved all software going back to DOS, win3, Win95, etc.  So we would have imagined that IT types would have even greater access to such things ...  In any case, we have WinXP64, so we could/would/like to get it going, but some "directions" are needed, to do what you would accomplish at your end if you had installed WinXP64.

BTW, an experiment we would have performed earlier, had there not been the discouragement on the MSyse pages to MSys2-32bit, is that of installing msys2-i686-20160205.exe on WInXP64.
FYI, it actually does NOT have any of the 64bit's GPGME errors.  Unfortunately, it has other, apparently terminal, problems.  For example, trying to close the shell, say after running update-core (which works with the 32bit MSys2), one gets various errors, such as there being multiple bash.exe's in TaskManager, and the inability to close the shell (at least not without "end Task" in TaskManager).
Following that it may be possible to launch the shell or not, with errors like "usr/bin/mintty: could not detach from caller", but typically if a second launch succeeds, that's about it.  No more shell launching after that, with the same mintty issue.
So, 64 bit can't communicate with the server, but the shell works.  32 bit, can communicate with the server, but the shell crashes ... all on the same WinXP64 box.
... this seems to suggests that a working 64bit should be possible, if it could just have the same coms reliability as the 32bit.

... oops, I clicked the Comment button accidentally before finishing the last Comment.
Not sure why, but the 64bit batch files are via CMD.exe, while the 32bit batch files are executed directly.  If the 32bit batch files are launched via CMD, then the mintty problem is alleviated to some extent.
That is, it may be possible (need more testing) to have a working MSys2 on WinXP64 with the 32bit version of MSys, though clear getting the 64bit to work is desired.

libalpm is a part of pacman. That is the library that you need to read the databases of MSYS2 (and ArchLinux), the source can be found here: https://projects.archlinux.org/pacman.git/
We're not throwing anyone to any dogs or anything of the sort, I don't have XP 64, have no way of getting it and no interest in illegal means of doing so. I don't collect old operating systems.
XP 64 is IMHO a complete oddity in the MS OS ecosystem and all variants of XP are end-of-lifed anyway. You are using an Operating System that doesn't receive security updates anymore and quite soon Cygwin will stop supporting it. When that happens, MSYS2 will also drop all XP support.
If you want to learn how to investigate it for yourself I'm happy to help you out with that though. The IRC channel is the best place.

Even in its heyday, XP64 was not fully supported by the vast majority of software (or hardware, for that matter). It was not widely-used or installed (in fact, I don't think I ever saw it included with consumer PC purchases; only the 32-bit version was). Part of the reason is due to an incomplete implementation of WoW64, which was more robust starting with Vista. See: https://en.wikipedia.org/wiki/Windows_XP_Professional_x64_Edition#Software_compatibility http://betanews.com/2010/07/09/after-five-years-64-bit-editions-of-windows-make-up-nearly-half-of-install-base/ (less than 1% of XP machines were 64-bit at the time of this 2010 article)

Many thanks for all the thoughts, though there continues to be digressions away from the issue at hand.  I don't really see that it is a good use of your or our time to go off on those digressions
As a matter of courtesy, I provide some limited response to the digression by Mr Donnelly and GranoblasticMan, though I don't think I will do too much of that in the future.
As these digressions dilute the important issue of getting MSys2 to work, I have separated my response into two parts.  This part/Comment is just for the digressions.  I will submit a separate and independent Comment focusing on the technical matters, and moving forward.
CAVEAT:  the digressions made previously require something of tome to respond to properly.  I simply don't have the time or budget for that.  So I touch on a few salient points, purely as illustrative examples.

Pooh-poohing XP64 is all well good, though some of the remarks made don't stand tests/results we have performed/obtained from actually doing our own test, rather than relying on third party opinions.

64bit Windows variants are designed to run 32bit apps, so even if you (now) don't support XP64, the XP32 variant should work on 64, but it does not (though we have figured out a way to make it work, sort of, on XP64 ... more on this in my "Part 2/next Comment").

The continued insistence on not installing XP64 seems miss-placed at MSys2, since, as per my earlier submissions, we have it, and we are willing to do the work without MSys2 needing to install it ... so long as we get a little help along the way.

In any case, the original point was (several comments ago), if you don't want do XP64, don't, that's your right, no need to make excuses for us ... and which you have stated in your follow-up Comment since.

The "end of life" issues may drive MSys2 to whatever decision MSys2 believes best at your end.

Having said so, approximately 30% or the planet (as of this month) is running XP.  I am willing to bet it would be bigger were it not for MS's business model, and quite frankly some chicanery.
Bizarrely, the XP installed base grew faster than the 8.1 installed base in the last couple of months.
The links GranoblasticMan's Comment are 404's.  Though it is easy enough for us to obtain installed based stats.
From where we sit, we think XP user's wont "go gently into the good night", see also below.

There are quite a few misdirections implied by some of the remarks.  For example, GranoblasticMan remarks such as "XP64 was not fully supported by the vast majority of software (or hardware, for that matter)" seems to be misplaced.

We have found good support for both software and hardware, indeed better compared to WIn7 (see below)
Moreover, those sorts of problems exist, and often worse, for other OS's.  Just as one of many examples I could provide, Adapatec refuses to make a proper scsi driver for Win7/64 (still).  As all of our machines are scsi based, it means, amongst other things, we lose half the scsi channels if we boot into Win7, and with that lose access to any and all hard drives on those channels.  I could go on for sometime on these sorts of things ...
We don't have any such problems on XP64.
... as noted, all these digressions are well a good, but they are not all that helpful to the current matter, and, quite frankly, not entirely a reliable basis for pooh-poohing XP/XP64.
I won't even begin commenting on Vista (a word that should not be used in polite company :-), which, and oddly in our mind, is supported by MSys2.  Indeed, if GranoblasticMan's implied logic of relying on installed base as criteria for "support" is extrapolated, then Vista should be dropped from support also.
As for the more recent versions of Windows, starting with 7, they have incorporated a colossal number of ridiculous and preposterous "features" that make the cost of ownership and just the cost of doing otherwise simple tasks required on a daily/routine basis, unbelievably difficult/expensive, due MS's choices.
... you may wish to pooh-pooh XP, but things are much worse, from our perspective, in each every WIn ver since.
We are "OCP math geeks".  It is not only good business, but also we are "hard-wired" to test carefully and thoroughly.  We make our decisions following considerable assessments.  If we have taken a decision to go down a particular path, perhaps you can give us the benefit of doubt that it is for good reasons, even if you are not aware of those reasons.
... so while we respect the choices MSys2 makes, it would be nice if MSys2 respected the choices we make for ourselves.
I am obliged to remind ourselves that we got here in the first place since MSys2 had made clear representation that WinXP 32 and 64 were "targeted" by MSys2.  I appreciate that now MSys2 has decided not to support XP64, and that's MSys2's right ... but then, really, are all these digressions necessary.  All these hand-waving arguments of "this that and the other thing" about XP64 are not worthy of your or our time, and some of it comes across as a smoke screen.
So, gentlemen, while I appreciate your digressions and views, I think I will now and moving forward restrict my attention to the technical issues.
Finally, Mr Donnelly, thank you for kind offer, we will do our best to make good use of it.
... Please see some WinXP64 test results in my next Comment.

Some WinXP64 MSys2 test results:
A) First, we have updated our MSys2 testing strategy:  it is now a parallel test, one for MSys2/64, and one for MSys2/32.
B) The results in this Comment relate to some findings with MSys2/32 on WinXP64.

First, the good news, we can get MSys2/32 to work, sort of, on WinXP64.  It does not work reliably "out of the box", but with a couple of simple adjustments, it can be made to work quasi-reliably, though still with some "concerns", some of which are detailed below.

Out of the box, MSys2/32 cannot be used reliably on WinXP64 for a number of reasons.  On the first launch of an MSys2 shell, there are at least two problems:

(i) running update-core appears to complete (to that point it asks for itself to be closed), but then the "shell"/MSys2 "freezes" or "is not responding", requiring end process in TaskMan to close.
(ii)  Thereafter, it is not possible to run the MSys2 Shell (directly), since any attempt to launch fails with a dialogue box stating to the effect "mintty could not detach from caller".
... this may be related to another mintty "issue" discussed below.
... our "guess" is that after the very first shell was launched, MSys2 may have connected to mintty through services.exe, or bash.exe, or ??, but when the shell is closed, somehow services.exe is not told to drop mintty, etc ... or something to that effect.
... also, depending on the exact sequence of the install (and making the adjustments in 3) below), under some conditions, every time a shell is launched, yet another entry for bash.exe appears in TaskMan (so if you launched/close the shell 3 times, there will be three bash.exe in TaskMan).

On a hunch, we decided to create short-cuts to msys2_shell.bat via cmd.exe, rather than simply attempting to run D:\Apps\msys32\msys2_shell.bat directly.  The idea being that WinXP64's cmd might help intercede with "detaching's" etc.  That is, the short-cut now has

C:\WINDOWS\system32\cmd.exe /A /Q /K D:\Apps\msys32\msys2_shell.bat
we also tested exactly the same thing with a 64 bit cmd.exe, but that discussion is omitted for now.
... this WORKS, sort of.  The "mintty detach" issue does not seem to come up to prevent launching a shell.  A Shell is launched, and can be used, sort of, for many, but not all, things.
Some of the issues under these conditions include:
a)$ update-core
bash: update-core: command not found
... no idea why, or how to fix (keeping in mind that update-core appeared to work on the very first launch of the shell, but then "froze" the shell after it appeared to  complete the update, and explicitly asked for itself to be closed).
b)$ pacman -Syuu
:: Synchronizing package databases...
mingw32                  265.8 KiB   255K/s 00:01 [#####################] 100%
mingw32.sig               96.0   B  0.00B/s 00:00 [#####################] 100%
mingw64                  265.2 KiB   796K/s 00:00 [#####################] 100%
mingw64.sig               96.0   B  0.00B/s 00:00 [#####################] 100%
msys                     136.0 KiB   387K/s 00:00 [#####################] 100%
msys.sig                  96.0   B  0.00B/s 00:00 [#####################] 100%
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
Packages (5) filesystem-2016.04-1  gzip-1.7-1
msys2-launcher-git-<IP_ADDRESS>0c495-1
msys2-runtime-<IP_ADDRESS>73.1439def-1
msys2-runtime-devel-<IP_ADDRESS>73.1439def-1
Total Download Size:    5.74 MiB
Total Installed Size:  28.23 MiB
Net Upgrade Size:       0.33 MiB
:: Proceed with installation? [Y/n] y
:: Retrieving packages ...
filesystem-2016.04-...    31.1 KiB  1941K/s 00:00 [#####################] 100%
msys2-runtime-2.5.0...     2.2 MiB   753K/s 00:03 [#####################] 100%
gzip-1.7-1-i686           92.4 KiB   863K/s 00:00 [#####################] 100%
msys2-launcher-git-...    25.0 KiB  2.03M/s 00:00 [#####################] 100%
msys2-runtime-devel...     3.4 MiB   843K/s 00:04 [#####################] 100%
(5/5) checking keys in keyring                     [#####################] 100%
(5/5) checking package integrity                   [#####################] 100%
(5/5) loading package files                        [#####################] 100%
(5/5) checking for file conflicts                  [#####################] 100%
(5/5) checking available disk space                [#####################] 100%
warning: could not get file information for mingw32.exe
warning: could not get file information for mingw32.ini
warning: could not get file information for mingw64.exe
warning: could not get file information for mingw64.ini
warning: could not get file information for msys2.exe
warning: could not get file information for msys2.ini
:: Processing package changes...
(1/5) upgrading filesystem                         [#####################] 100%
error: cannot remove /usr/bin/msys-2.0.dll (Permission denied)
(2/5) upgrading msys2-runtime                      [#####################] 100%
warning: warning given when extracting /usr/bin/msys-2.0.dll (Could not unlink)
(3/5) upgrading gzip                               [#####################] 100%
(4/5) upgrading msys2-launcher-git                 [#####################] 100%
(5/5) upgrading msys2-runtime-devel                [#####################] 100%
... we could not asses the importance of the "warnings" following the line "(5/5)".
... The Warning and Error following the line :: Processing package changes...
(i) It is not clear why MSys2 has "Permission denied" for removing msys-2.0.dll.  Since there are detach issues with mintty, it is possible that some other process has locked/use of the dir, since it "failed to detach" earlier.
c) So, performed a complete uninstall/reinstall, just in case.
All of the same issues arose, had to use cmd.exe etc to get to a working Shell etc.  Then, after all the initial steps, and getting to running pacman -Syuu on this occasion produced:
Administrator@art-64 MSYS ~
$ pacman -Syuu
:: Synchronizing package databases...
mingw32 is up to date
mingw64 is up to date
msys is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
Packages (25) coreutils-8.25-1  crypt-1.3-1  curl-7.47.1-2  file-5.25-1
filesystem-2016.04-1  gcc-libs-5.3.0-3  gettext-0.19.7-3
gmp-6.1.0-2  gnupg-1.4.20-1  grep-2.22-3  gzip-1.7-1
heimdal-libs-1.5.3-9  libasprintf-0.19.7-3  libcrypt-1.3-1
libcurl-7.47.1-2  libexpat-2.1.1-1  libgettextpo-0.19.7-3
libintl-0.19.7-3  libopenssl-1.0.2.g-1  mintty-1~2.2.3-1
mpfr-3.1.4-1  msys2-launcher-git-<IP_ADDRESS>0c495-1
ncurses-6.0.20160220-1  openssl-1.0.2.g-1  rebase-4.4.2-1
Total Download Size:   12.01 MiB
Total Installed Size:  68.02 MiB
Net Upgrade Size:       2.10 MiB
:: Proceed with installation? [Y/n] y
:: Retrieving packages ...
gmp-6.1.0-2-i686         353.9 KiB   975K/s 00:00 [#####################] 100%
gcc-libs-5.3.0-3-i686    840.2 KiB   977K/s 00:01 [#####################] 100%
libintl-0.19.7-3-i686     25.9 KiB  2.30M/s 00:00 [#####################] 100%
coreutils-8.25-1-i686      2.2 MiB   944K/s 00:02 [#####################] 100%
libcrypt-1.3-1-i686       12.3 KiB  1756K/s 00:00 [#####################] 100%
crypt-1.3-1-i686          12.5 KiB  2.43M/s 00:00 [#####################] 100%
libopenssl-1.0.2.g-...   809.0 KiB   925K/s 00:01 [#####################] 100%
ncurses-6.0.2016022...  1140.6 KiB   946K/s 00:01 [#####################] 100%
heimdal-libs-1.5.3-...   621.5 KiB   901K/s 00:01 [#####################] 100%
openssl-1.0.2.g-1-i686  1325.9 KiB   911K/s 00:01 [#####################] 100%
gzip-1.7-1-i686           92.4 KiB   962K/s 00:00 [#####################] 100%
libexpat-2.1.1-1-i686     57.2 KiB  2.15M/s 00:00 [#####################] 100%
libcurl-7.47.1-2-i686    193.7 KiB   940K/s 00:00 [#####################] 100%
curl-7.47.1-2-i686       594.6 KiB   921K/s 00:01 [#####################] 100%
file-5.25-1-i686         399.3 KiB   976K/s 00:00 [#####################] 100%
filesystem-2016.04-...    31.1 KiB  2.02M/s 00:00 [#####################] 100%
libgettextpo-0.19.7...   114.1 KiB   943K/s 00:00 [#####################] 100%
libasprintf-0.19.7-...    11.5 KiB  2.82M/s 00:00 [#####################] 100%
gettext-0.19.7-3-i686   1529.0 KiB   931K/s 00:02 [#####################] 100%
gnupg-1.4.20-1-i686     1013.8 KiB   947K/s 00:01 [#####################] 100%
grep-2.22-3-i686         228.9 KiB   809K/s 00:00 [#####################] 100%
mintty-1~2.2.3-1-i686    144.6 KiB   861K/s 00:00 [#####################] 100%
mpfr-3.1.4-1-i686        239.7 KiB   936K/s 00:00 [#####################] 100%
msys2-launcher-git-...    25.0 KiB  2.03M/s 00:00 [#####################] 100%
rebase-4.4.2-1-i686      242.2 KiB   859K/s 00:00 [#####################] 100%
(25/25) checking keys in keyring                   [#####################] 100%
(25/25) checking package integrity                 [#####################] 100%
(25/25) loading package files                      [#####################] 100%
(25/25) checking for file conflicts                [#####################] 100%
(25/25) checking available disk space              [#####################] 100%
warning: could not get file information for mingw32/
warning: could not get file information for mingw32/bin/
warning: could not get file information for mingw32/etc/
warning: could not get file information for mingw32/include/
warning: could not get file information for mingw32/lib/
warning: could not get file information for mingw32/share/
warning: could not get file information for mingw64/
warning: could not get file information for mingw64/bin/
warning: could not get file information for mingw64/etc/
warning: could not get file information for mingw64/include/
warning: could not get file information for mingw64/lib/
warning: could not get file information for mingw64/share/
warning: could not get file information for opt/
warning: could not get file information for mingw32.exe
warning: could not get file information for mingw32.ini
warning: could not get file information for mingw64.exe
warning: could not get file information for mingw64.ini
warning: could not get file information for msys2.exe
warning: could not get file information for msys2.ini
warning: could not get file information for autorebasebase1st.bat
:: Processing package changes...
( 1/25) upgrading gmp                              [#####################] 100%
( 2/25) upgrading gcc-libs                         [#####################] 100%
( 3/25) upgrading libintl                          [#####################] 100%
( 4/25) upgrading coreutils                        [#####################] 100%
( 5/25) upgrading libcrypt                         [#####################] 100%
( 6/25) upgrading crypt                            [#####################] 100%
( 7/25) upgrading libopenssl                       [#####################] 100%
( 8/25) upgrading ncurses                          [#####################] 100%
( 9/25) upgrading heimdal-libs                     [#####################] 100%
(10/25) upgrading openssl                          [#####################] 100%
(11/25) upgrading gzip                             [#####################] 100%
(12/25) upgrading libexpat                         [#####################] 100%
(13/25) upgrading libcurl                          [#####################] 100%
(14/25) upgrading curl                             [#####################] 100%
(15/25) upgrading file                             [#####################] 100%
(16/25) upgrading filesystem                       [#####################] 100%
(17/25) upgrading libgettextpo                     [#####################] 100%
(18/25) upgrading libasprintf                      [#####################] 100%
(19/25) upgrading gettext                          [#####################] 100%
(20/25) upgrading gnupg                            [#####################] 100%
gpg: WARNING: standard input reopened
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/documentation/faqs.html for more information
gpg: /etc/pacman.d/gnupg/trustdb.gpg: trustdb created
gpg: no ultimately trusted keys found
gpg: WARNING: standard input reopened
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/documentation/faqs.html for more information
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/documentation/faqs.html for more information
gpg: Generating pacman keyring master key...
gpg: skipping control `%no-protection' ()
.+++++
..........+++++
gpg: key 1C028B00 marked as ultimately trusted
gpg: Done
==> Updating trust database...
gpg: WARNING: standard input reopened
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/documentation/faqs.html for more information
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
==> Appending keys from msys2.gpg...
gpg: WARNING: standard input reopened
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/documentation/faqs.html for more information
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
==> Locally signing trusted keys in keyring...
-> Locally signing key D55E7A6D7CE9BA1587C0ACACF40D263ECA25678A...
-> Locally signing key 123D4D51A1793859C2BE916BBBE514E53E0D0813...
-> Locally signing key B91BCF3303284BF90CC043CA9F418C233E652008...
-> Locally signing key 9DD0D4217D75A33B896159E6DA7EF2ABAEEA755C...
==> Importing owner trust values...
gpg: WARNING: standard input reopened
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/documentation/faqs.html for more information
gpg: setting ownertrust to 4
gpg: setting ownertrust to 4
gpg: setting ownertrust to 4
gpg: inserting ownertrust of 4
==> Updating trust database...
gpg: WARNING: standard input reopened
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/documentation/faqs.html for more information
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   4  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   4  signed:   3  trust: 0-, 0q, 0n, 4m, 0f, 0u
gpg: depth: 2  valid:   3  signed:   0  trust: 3-, 0q, 0n, 0m, 0f, 0u
(21/25) upgrading grep                             [#####################] 100%
error: cannot remove /usr/bin/mintty.exe (Permission denied)
(22/25) upgrading mintty                           [#####################] 100%
warning: warning given when extracting /usr/bin/mintty.exe (Could not unlink)
(23/25) upgrading mpfr                             [#####################] 100%
(24/25) upgrading msys2-launcher-git               [#####################] 100%
(25/25) upgrading rebase                           [#####################] 100%
... we have no idea why the second clean install's first use of -Syuu produces a different log/process compared to the earlier install, and why there are so many more items.
... the warnings and errors are interesting.  Amongst other things, note that pacman could not update mintty (c.f. the earlier install where the Errors did not include mintty).  We are guessing that since we did not reboot the machine between re-install of MSys2, services.exe kept a connection to mintty, and so the second reinstall was already starting "wrong footed" wrt mintty.
... no idea what all the "insecure memory" business is.
Nevertheless, it is possible to use MSys2/32 on WinXP64, save for the issues mentioned.  It is possible that we will find additional issues with additional test.
In the mean time, we have successfully used (the adjusted) MSys2/32 to install the usual compiler toolchain, GTK3, Glade, etc.
We have at this point, only limited test for running/using the MSys2/32 installed toolchain etc, since there is another MingW-64 installation (not MSys2) on the same machine, and various env vars will need to be reset to point to the MSys2 dir's, which we cannot do for a little while yet for reasons beyond this discussion.  Still, and though it's early days, at least it appears that the c and Fortran compilers are working.
Moving forward:  Any suggestion for tests/fixes for
(i) the "cannot detach mintty" errors
(ii) that on the very first launch of the shell, it "freezes" after update-core, requiring TaskMan intervention
would be appreciated.
Cheers
DrO

About update-core it's pretty normal that shell will freeze after using it. There should be warning saying you have to force close shell. Also update-core is removed after updating pacman since pacman -Syuu has taken it's job.

(A) Many thanks for that, its good know that

... and YES, it would be very helpful if ONE of the lines at the end of the update-core process EXPLICITLY stated that you may not be able Close the shell by normal means, and that TaskMan may be required, and also TaskMan for bash.exe, etc.

Though, it does not seem to address the mintty detach issue with WinXP64/MSys2-32

(B) Now, for some good news, in addition to MSys2-32 working from above, we now have MSys2-64 working on WinXP64, sort of.

The solution, such as it is, requires editing etc/pacman  pacman.conf.  The edit is:

SigLevel = Never                                               # DrO, use this for GPGME Error/curropt database etc
#SigLevel    = Required DatabaseOptional       # DrO, turned off to obviate GPGME etc errors
... CRUCIALLY, we had performed a similar test previously based on link relating to GPGME errors, but there the instructions were simply to comment out/turn-off the SigLevel.
In fact, that is not enough, one MUST explicitly set SigLever = Never.
Following that, no more GPGME errors, and update-core/pacman -Syuu etc work as expected, though complaining about the "security".
If after update/-Syuu, the SigLevel is returned to "normal/original", then the GPGME/corrupt database errors return.
For the time being, we are leaving SigLevel = Never.
So, now the questions are:
a) How safe/advisable is it to run MSys2 with SigLevel = Never????
b) How to fix this, so that it works with the normal SigLevel?

The Shells are launched via short-cuts using the "cmd" approach, as discussed in the parallel test to get MSys2-32 to work on WinXP64.  However, the default WinXP64 environment has the same cmd.exe in both System32 and SysWow, and they are both 32-bit.

We found that with MSys2-64, we had better results using a 64-bit version of cmd.exe.  In our case, it is part of the AMD service pack.  Presumably, other chip vendors may supply such as well.
Cheers
DrO

To my last comment: After you update msys using update-core there is warning and you should be able to see it (shows on win 7 and 10).

There is no explicit message inside the Shell stating that extra ordinary effort will be required.  Though there are quire a few messages about "use Close"/"red [x]" etc.  So adding one more line should not be too difficult.
Yes, on Win7 there is dialogue that pops ups, with a "close anyway".  On WinXP64, there is dialogue that indicates "some things are still running", but that's about it.  Thereafter, the user is on their own to discover that they must enter TaskMan and start whittling the appropriate frozen bits.   Not sure if this happens on XP32, as have not tested there.
In any case, I wonder if anyone has any thoughts on the deeper issues from above.  For example, on WinXP64, amongst other things, we must run with
SigLevel = Never
... otherwise the shell just spews  GPGME/currupt database errors, and nothing can be installed.
So,

how advisable/safe is it run with "Never" ?

how to fix the system so that the normal SigLevel settings don't cause those errors?

Many thanks

Thank you for the SigLevel = Never tip !


InputEventMouseButton: Use exact match for actions with modifiers

Fixes #52776.
Also cosmetic/dead code cleanup.

See the issue for some discussion, I'm wary that this might have been limited on purpose due to some use cases where taking modifiers into account would not be wanted.
I'm also not sure if/how action_match and is_match should differ or produce similar results. If they should always be the same, maybe some more refactoring is in order.

I'm also not sure if/how action_match and is_match should differ or produce similar results. If they should always be the same, maybe some more refactoring is in order.

Uh... yeah I think it is. I've also noticed that if you do get_action_strength, get_action_raw_strength or is_action_pressed/released with exact_match=true you won't get values back from those methods...
https://github.com/godotengine/godot/blob/d67e2f3e0f00c4a78552fabf38dfe816bdeeefe9/core/input/input_map.cpp#L134-L136
See how if exact match is true, none of the p_pressed, p_strength, etc are passed values. Anyway, I digress...

Ok so I think this needs to be documented in-code since action_match is not exposed to GDScript and thus is not in the public doco. The intention is that action_match allows more modifiers to be pressed than required. For example, if you have an action with Alt + C, pressing Shift + Alt + C will still trigger it, but pressing only C will not. This is so, for example, in games you can press Shift to sprint while also pressing W to move, and the W action is still picked up even though you are not just pressing W.
is_match does a similar check, but if exact_match is false, then modifiers are ignored. If exact_match is true, then the modifiers must be exactly as described in the InputEvent, i.e. if it needs an Alt modifier, then pressing Alt and only Alt will return true in that method. This is documented in the documentation, however it may be worthwhile to explain this stuff in-code too.

So, summarising this, (including my digression at the start):

I think action_match needs to be changed to have the p_exact_match parameter so that the values of pressed and strength can be returned in _find_event even if exact is true. action_match could then call is_match internally to do the "exact match" check.
action_match needs to be better documented in code
I am not sure if these changes will be ok, because action_match will fail if an extra modifier is pressed. For example, pressing Shift + Alt + LMB will be rejected for an action which only requires Alt + LMB, which is not what is desired from action_match, as explained above. However, I think this is resolved if my first point in this list is implemented.

I kind of forgot the details about this and I don't really have much time to work on it, so if someone wants to pick it up from there, feel free to :)

I think this has been superseded by #54173. The linked bug report is fixed in 3.5.


Updating to take care of nginx and deprecation

keygen HTML tag is deprecated, so this is a best effort at replacement via a couple of submodules and edits. Also, I included a config for nginx so that it will work on both Apache and nginx, with letsencrypt

Edited and accepted on the other branch (https://github.com/scriptjunkie/EasyAuth/commit/486e0ea37d862f7700586df48329fc96765af70d)