Add currencies/exchanges

Introduce the ability to hold securities denominated in multiple currencies but broker should still register performance and hold cash in a single currency (so this should primarily impact things like quote and holdings, not cash balances with broker).
Can also introduce the concept of multiple exchanges. This may be required because the above change would require the ability to get a quote across multiple asset types. And differences in currencies would generally imply different exchanges. However, this is really an implementation detail of the data source and the broker so may not be a productive use of time.

Closed with - https://github.com/calumrussell/alator/tree/v0.2.0.
Currencies is not happening because it isn't a priority on downstream packages. Would add unnecessary complexity.


Helm chart for system upgrade controller version 0.2.1 missing

The helm chart for system-upgrade-controller version 0.2.1 is missing from the helm repo:
$ helm search repo nimbolus/system-upgrade-controller --versions
NAME                                    CHART VERSION   APP VERSION     DESCRIPTION
nimbolus/system-upgrade-controller      0.3.0           v0.11.0         Kubernetes-native upgrade controller (for nodes)
nimbolus/system-upgrade-controller      0.2.1           v0.9.1          Kubernetes-native upgrade controller (for nodes)
nimbolus/system-upgrade-controller      0.2.0           v0.9.1          Kubernetes-native upgrade controller (for nodes)
nimbolus/system-upgrade-controller      0.1.0           v0.8.1          Kubernetes-native upgrade controller (for nodes)

$ helm pull nimbolus/system-upgrade-controller --version 0.2.1
Error: failed to fetch https://github.com/nimbolus/helm-charts/releases/download/system-upgrade-controller-0.2.1/system-upgrade-controller-0.2.1.tgz : 404 Not Found

Other versions are available:
$ helm pull nimbolus/system-upgrade-controller --version 0.3.0
$ helm pull nimbolus/system-upgrade-controller --version 0.2.0
$

We can upgrade to the new version 0.3.0, but the missing version is still problematic for us, because

It breaks anyone trying to install our current stable release of our software (which uses 0.2.1).
It will break our tests (automated upgrade testing) that we do as part of releasing our software -- in particular, when releasing a new version that would include 0.3.0.

It would be much appreciated if you could restore the availability of 0.2.1! Thanks :).

Sorry, my fault. I removed it by accident. The release should now be available again. Does it work for you, @ariep ?

Yes, seems fine now again, thanks a lot!


heroku pg:pull ignoring PGPORT when calling createdb

I have run this command a thousand times and it worked until some days ago.
I run a local potsgres server on port 5444.
(venv-development) Alain-MBP:backend alain$ echo $PGPORT
5444
(venv-development) Alain-MBP:backend alain$ heroku pg:pull DATABASE_URL local-development/db/ --app app-name
heroku pg:pull DATABASE_URL local-development/db/ --app app-name
heroku-cli: Pulling postgresql-transparent-31571 ---> local-development/db/
createdb: could not connect to database template1: could not connect to server: Connection refused
	Is the server running on host "localhost" (::1) and accepting
	TCP/IP connections on port 5432?
could not connect to server: Connection refused
	Is the server running on host "localhost" (<IP_ADDRESS>) and accepting
	TCP/IP connections on port 5432?
make: *** [db-sync-production] Error 1

When creating the db, port 5432 is used instead.
(venv-development) Alain-MBP:backend alain$ heroku --version
heroku-toolbelt/3.43.16 (x86_64-darwin10.8.0) ruby/1.9.3
heroku-cli/5.5.8-df05424 (darwin-amd64) go1.7.4
=== Installed Plugins
<EMAIL_ADDRESS>heroku-redis-cli
heroku-repo
<EMAIL_ADDRESS>

@ Alain1405 I just shipped a new version (5.5.10) you can get by running heroku update.  Please let me know if that fixes this bug.

Thanks @ransombriggs , that definitely fixed it partially. Now the PGPORT env variable is honored.
However I now get, at the end of the procedure:
psql: server does not support SSL, but SSL was required
 ▸    WARNING: Extensions in newly created target database differ from existing source database.
 ▸    Target extensions:
 ▸
 ▸    Source extensions:
 ▸    extname
 ▸    ---------
 ▸    plpgsql
 ▸    (1 row)
 ▸
 ▸
 ▸    HINT: You should review output to ensure that any errors
 ▸    ignored are acceptable - entire tables may have been missed, where a dependency
 ▸    could not be resolved. You may need to to install a postgresql-contrib package
 ▸    and retry.
heroku-cli: Pulling complete.

I don't understand if the SSL message and the extension message are related. For sure after all pg_dums and pg_restores the local db is not in place. I'm figuring out how to debug it.


Variable length of UTF-8 (#2035)

According to Unicode 1.1 Appendices F. FSS-UTF (https://www.unicode.org/versions/Unicode1.1.0/appF.pdf), variable-width is 1-6 bytes.

@veawor : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@veawor - Thanks for the detail!

#sign-off


Trim down dependencies

The archiver library imports over 250k lines of code, which we can
replicate in ~25 lines of stdlib. Additionally, we have had issues with
CVE is downstream dependencies, etc.
A little copying is better than a lot of dependency.

/retest


Updated the profile and pattern lab repos

Summary
Updated profile and pattern lab repositories for 11/19/2020 launch

DAmn Jordan! Too Quick


Leaking mounted netns

After killing daemon with -9 with running contianer and starting again I see records in mounts:
nsfs on /var/run/docker/netns/44ba3ad8c973 type nsfs (rw)

and they never disappear. I don't remember where we finished last time, but for other resources as graphdriver mounts we cleaning all up on daemon start. Also if I start container and then remove it - netns disappear, but if just remove stopped - it will be there forever.

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

This is still an issue.

@LK4D4 @thaJeztah should this be in 1.10 ?

@vdemeester not sure, it's not a bug/regression that's introduced in 1.9. We probably should give it some attention though.

This is fixed.


Allow converters to return Promises

Is your feature request related to a problem? Please describe.
I have some data that needs to be processed with async APIs when read or written to the database. I'd like to put the processing in a converter to ensure it's done consistently, but I can't because converters can't be async.
In this case the processing is compression/decompression. Without async converters I'm forced to choose between doing the processing at every read and write or tying up the main thread during compression.
Describe the solution you'd like
Converters should have an interface that allows for async methods:
  export interface FirestoreDataConverter<T> {
    toFirestore(modelObject: WithFieldValue<T>): DocumentData | Promise<DocumentData>;

    toFirestore(
      modelObject: PartialWithFieldValue<T>,
      options: SetOptions
    ): DocumentData | Promise<DocumentData>;

    fromFirestore(snapshot: QueryDocumentSnapshot): T | Promise<T>;
  }

We would need a new async method for reading data from snapshots and the existing .data() method would have to throw if an async converter is used:
    // Throws if the converter returns a Promise
    data(): T | undefined;
    dataAsync(): T | Promise<T> | undefined;

DocumentReference write methods set() and update() would need to support Promise fields, but they are already async.
Transaction write methods aren't async, but are obviously performing async work without blocking already.
Describe alternatives you've considered
Not using FirestoreDataConverters.

Hi @justinfagnani
After discussing with the team, we feel while this request has some merit, we are hesitant to add more API surface(dataAsync) so we could support this one feature. There might be a way to do it without adding dataAsync, but we did not have time to explore.
I'd put this in our backlog, and we might revisit this in the future. In the meantime, I believe you have reasonable workaround to get what you want.
Also, personally, I feel your use case is no longer standard deserialization, and it probably makes some sense that you will do something different to make it clear.
Thanks

Sounds reasonable, thanks!

Also, personally, I feel your use case is no longer standard deserialization, and it probably makes some sense that you will do something different to make it clear.

I would push back on this a little bit. The only thing "non-standard" in terms of the APIs involved is that my deserialization is much better if async. Lots of other operations could be async and the JS ecosystem is moving to more and more prevasive async operations. Since the db calls themselves are async already, it seems pretty natural to fold in conversion into the existing async calls.


Check if restic repository exists before init

cf: https://github.com/restic/restic/issues/1690#issuecomment-377009992

Fixed by #157


bugfix - REALTIME clock should be used to print human readable date/time

str_now was wrong because MONOTONIC clock (since boot) were used. basically it used to show year 1970...

@mstanichenko, comments on this?

The whole story starts with commit 78d8c618193707d28fc0c0c0263591b3b2071d59
It seems that we are trying to solve issues that arise because of it rather than fixing initial approach.
self->now is not supposed to represent absolute time. For some reason, we assume that it really is and unreasonably  call TIMESPEC_TO_TIMEVAL()
We can have two different functions: the one updates fix session internal clock (self->now) the other is responsible for absolute time string representation. fix_session_time_update may call either of them or both.
Does it sound reasonable?

@mstanichenko yes it's indeed my commit that introduced a bug sorry about that.
yes we can do two functions instead of one i.e. fix_session_monotonic_time_update and fix_session_realtime_update? for me it'd be even better because I don't use self->now anyway. just let me know your preferences for fix_session_time_update.
if you've a lot of sessions and updating all the clocks at the same time calling gettime takes long.

yes it's indeed my commit that introduced a bug sorry about that

No worries about that :)

yes we can do two functions instead of one i.e.

Agreed

just let me know your preferences for fix_session_time_update.

I believe we should allow a user explicitly call fix_session_monotonic_time_update or fix_session_realtime_update. fix_session_time_update can by default update both counters.

if you've a lot of sessions and updating all the clocks at the same time calling gettime takes long

Yes of course that makes sense


fix update of inherited documents on findAndUpdate [#971]

Fix for error from #971 ticket. When looking for particular document, DocumentPersist use $in to query particular type of documents, that are inherited in "SINGLE_COLLECTION" way. It works great in case of looking for a file, but has no influence on document creation on upsert update. Added condition, which change "$in" into simple equation, if there is only one discriminator value.

Bumping this for consideration in a 1.0.x patch release.

Sorry for such huge delay. I've changed tests class name. Also moved brackets, so this clases matches PSR-2.

@slawus welcome back! Would you be willing to work on @jmikola's remark? https://github.com/doctrine/mongodb-odm/pull/972#discussion_r34840957

Definitely I would like to help, unfortunately I can't guarantee that I will find free time to do it :/ So feel free to help! :)

@slawus I've included your commit in #1319 - thank you for fixing this part!

Great!


[ZEPPELIN-3241] fix NPE when restarting Interpreter

What is this PR for?
We often (but not always) face an NPE when restarting Spark interpreter. Our Spark interpreter run in scoped mode per note. The restart then is not possible, only restart of whole zeppelin daemon helps out.
This PR fixes this NPE.
What type of PR is it?
Bug Fix
Todos
What is the Jira issue?
https://issues.apache.org/jira/browse/ZEPPELIN-3241
How should this be tested?

manual

Screenshots (if appropriate)
Questions:

Does the licenses files need update? no
Is there breaking changes for older versions? no
Does this needs documentation? no

LGTM


Add Blisk.app Letest

[x] Checked there aren’t open pull requests for the same cask.
[x] Checked there aren’t closed issues where that cask was already refused.
[x] When naming the cask, followed the token reference.
[x] Commit message includes cask’s name.
[x] brew cask audit --download {{cask_file}} is error-free.
[ ] brew cask style --fix {{cask_file}} left no offenses.
bliskcloudstorage.blob.core.windows.net does not match blisk.io
[x] brew cask install {{cask_file}} worked successfully.
[x] brew cask uninstall {{cask_file}} worked successfully.

@victorpopkov : added ;) Thanks I was not aware of this procedure


[BUG] Conflict with Porting Lib

The issue I'm facing is an incompatibility with Porting Lib by Fabricators of Create, the cause is map rendering.
The issue on the Porting Lib github (with stacktrace and info, etc.):
https://github.com/Fabricators-of-Create/Porting-Lib/issues/33#issue-1553656327

Apparently already fixed!


updates for Rails 8.0

Updates for Rails 8.0
Tests run after updating sqlite gem in Gemfile.lock:
$ bin/test
DEPRECATION WARNING: `to_time` will always preserve the full timezone rather than offset of the receiver in Rails 8.1. To opt in to the new behavior, set `config.active_support.to_time_preserves_timezone = :zone`. (called from <top (required)> at /workspaces/devise-uncommon_password/test/dummy/config/environment.rb:5)
DEPRECATION WARNING: `to_time` will always preserve the full timezone rather than offset of the receiver in Rails 8.1. To opt in to the new behavior, set `config.active_support.to_time_preserves_timezone = :zone`. (called from <top (required)> at /workspaces/devise-uncommon_password/test/dummy/config/environment.rb:5)
Run options: --seed 62839

# Running:

.......

Finished in 1.477656s, 4.7372 runs/s, 139.4100 assertions/s.
7 runs, 206 assertions, 0 failures, 0 errors, 0 skips

I did not change it in the gemspec, so older versions still work.
(@HCLarsen What are your thoughts about (new) automated tests based on Github Workflows instead of Travis? Maybe using https://github.com/makandra/gemika or something similar? If you think it's a good idea, I could add a PR.)

@MichaelWhi I'm not familiar with Github workflows, but Travis cancelled their free options, so this repo has actually been without a CI for a while. I'd be interested to see how that works.


LightningModule needs to be imported from pl

What does this PR do?
I couldn't run the code, because of a minor typo.  I replaced LightningModule by pl.LightningModule

Fixes #<issue_number>
Before submitting

[ ] Was this discussed/approved via a GitHub issue? (not for typos and docs)
[x ] Did you read the contributor guideline, Pull Request section?
[x ] Did you make sure your PR does only one thing, instead of bundling different changes together?
[x ] Did you make sure to update the documentation with your changes? (if necessary)
[ ] Did you write any new necessary tests? (not for typos and docs)
[x ] Did you verify new and existing tests pass locally with your changes?
[ ] Did you update the CHANGELOG? (not for typos, docs, test updates, or internal minor changes/refactorings)

PR review
Anyone in the community is free to review the PR once the tests have passed.
Before you start reviewing make sure you have read Review guidelines. In short, see the following bullet-list:

[x ] Is this pull request ready for review? (if not, please submit in draft mode)
[ x] Check that all items from Before submitting are resolved
[x ] Make sure the title is self-explanatory and the description concisely explains the PR
[ ] Add labels and milestones (and optionally projects) to the PR so it can be classified

Did you have fun?
Make sure you had fun coding 🙃

just LightningModule is used in most of the places in the docs since there are imported here globally: https://github.com/PyTorchLightning/pytorch-lightning/blob/741c452551780e110938c8635db496682784be07/docs/source/conf.py#L375-L392
for the doctest.

just LightningModule is used in most of the places in the docs since there are imported here globally:

This does not matter here because the notebook instructs to import Lightning as pl right before


How to handle disconnects correctly?

Hello,
Whenever I restart my SQL Server, my Node script immediately errors out.  Which event should I be handling that I am not?
Cheers
Christopher
events.js:72
throw er; // Unhandled 'error' event
^
ConnectionError: Failed to connect to <IP_ADDRESS>:undefined - read ECONNRESET
at Connection.socketError (C:\jobs\node_modules\mssql\node_modules\tedious\l
ib\connection.js:746:26)
at Socket. (C:\jobs\node_modules\mssql\node_modules\tedious\lib\c
onnection.js:3:59)
at Socket.emit (events.js:95:17)
at net.js:440:14
at process._tickCallback (node.js:419:13)

You should listen for those errors on connection object.
connection.on('error', function(err) {
    // ...
});

If using the global connection, what would be the best way to handle this event? I don't see an obvious way to access the global connection object so I can attach an error handler like you have shown above.

Yes - it seems like those events are not being fired on the global connection?

You can listen for events on global connections.
var sql = require('mssql');
sql.on('error', function(err) { console.error(err.message) });

I get ECONNRESET on SQL Azure once every day or two. It seems like this is normal behavior for SQL Azure that needs to be handled smoothly.
What is unclear to me is if anything needs to be done other than logging the error like in the above code. Will the connection pool dispose of this connection and reconnect once the SQL Server becomes available again, or should I be closing the pool and restarting it manually each time this error is thrown?

Connection health check is built-in so you don't have to do any extra work on this. Once the dead connection is discovered, it is immediately replaced with a new one.

That's great. However, I would highly recommend adding to the documentation and the examples the fact that you should always be listening for connection error events (in addition to request errors). It's not documented at all as far as I can see. And if you don't, then whenever a connection is reset it will emit the error and if there is no listener (and no domain listener as a backup) it will crash the application as an uncaught error. This was causing me some serious grief with random crashes as a new user of the library.

I have updated the docs and the examples. Thanks.

From what I can tell the docs for the global connection are incorrect - per your given example above, you should be listening directly on module, not on the connection.

You're right, corrected. Thanks.

@patriksimek  When db connection is disconnected, I want to return response as timeout or something like that.
I am using this function(sql.on('error', function(err) { console.error(err.message) });) but can't return response, getting error on console 'Can't set headers after they are sent' .
Looking forward to your response.

@mubashirrbaig I am also facing same issue. When server load is less at that time it happens. Looks like connection is closed after idle time by azure


Fix #756: Fix part of #814; basic benchmarking

Using https://pytest-benchmark.readthedocs.io/en/latest/ to pinpoint the performance issue
Closes #756
Refs #198
This shows significant improvement when getting contiguous copies of a kind="sig"buffer, but doesn't seem to fix the main part of #814, unfortunately.
Contributor Checklist:

[x] I have added or updated my entry in the creators.json file
[x] I have added a changelog entry for my contribution
[x] I have added/updated documentation for all user-facing changes
[x] I have added/updated test cases

Ok, if CI passes this should be ready for review!

Nice! I'll have a look, and I'll also base my work for #798 on this branch to get some practical experience. That's probably worth more than just code review

It seems that changing conftest.py has broken the ipyparallel test.

It seems that changing conftest.py has broken the ipyparallel test.

Awesomeeee! :frowning_face: Looks like it would break any dist tests that use an object from the conftest file, as cloudpickle needs to be able to import the conftest file on the destination host. Also seems like I left the --pdb in the Dockerfile command:, so it stops running tests after the first failure

Recording full data is disabled

So this means that we still get a trend over time (and across machine types), but only from the aggregated statistics, right?

Recording full data is disabled

So this means that we still get a trend over time (and across machine types), but only from the aggregated statistics, right?

Yes, exactly. The full data is not useful for the intended purpose anyway.

It seems that changing conftest.py has broken the ipyparallel test.

Awesomeeee! ☹ Looks like it would break any dist tests that use an object from the conftest file, as cloudpickle needs to be able to import the conftest file on the destination host. Also seems like I left the --pdb in the Dockerfile command:, so it stops running tests after the first failure

Trying to debug this locally I ran into limitations of my machine. It takes ages, literally. The last change didn't fix it, unfortunately. @sk1p could you perhaps have a look?

could you perhaps have a look?

Sure thing, I'll have a look tomorrow!

Trying to debug this locally I ran into limitations of my machine. It takes ages, literally. The last change didn't fix it

I could reproduce this, and I noticed that the docs need updates, too. Can I push my changes into this branch?

@sk1p Thx for fixing this, and it was OK to push into the branch.   :-D

Yep, I figured :grinning: I could not reproduce the old issue with the latest distributed version (running everything in Python 3.6 containers, as my system doesn't have 3.6 anymore). I updated the pinned distributed version to ensure we get the latest version and I'm now working on the new and exciting error!

I think this should be basically ready to merge now, after CI finishes.  Many many thanks for your help @sk1p :-) Merging!


Number of scenarios within one tf-example file

Hi,
I just want to clarify that is there only one scenario within one tf-example file for waymo_open_dataset_motion_v_1_2_0 if the type of the file is tf-example?
Appreciate your help!

Hi,
Each file contains many scenarios in tfrecord format stored as serialized tensorflow example protocol buffer objects.
Please let me know if you have further questions.

Hi,
Thanks for the help, I recommend to change the motion tutorial since it loads only one single scenario from the parsed tf.record file, which is a little bit confusing.
Thanks!

Thank you for your feedback!

I am unable to run any .tf record using the following part of the code-in-motion tutorial can you help please:
part of code:
Create Dataset.
dataset = tf.data.TFRecordDataset(FILENAME, compression_type='')
data = next(dataset.as_numpy_iterator())
parsed = tf.io.parse_single_example(data, features_description)
error:
InvalidArgumentError                      Traceback (most recent call last)
 in <cell line: 44>()
42
43 # Print the available features in the first example
---> 44 for example in parsed_dataset.take(1):  # Taking just one example for demonstration
45     available_features = [key for key, value in example.items() if value.numpy() is not None]
46     print("Available features:")
3 frames
/usr/local/lib/python3.10/dist-packages/tensorflow/python/framework/ops.py in raise_from_not_ok_status(e, name)
7213 def raise_from_not_ok_status(e, name):
7214   e.message += (" name: " + name if name is not None else "")
-> 7215   raise core._status_to_exception(e) from None  # pylint: disable=protected-access
7216
7217
InvalidArgumentError: {{function_node _wrapped__IteratorGetNext_output_types_20_device/job:localhost/replica:0/task:0/device:CPU:0}}
Feature: roadgraph_samples/dir (data type: string) is required but could not be found.
[[{{node ParseSingleExample/ParseExample/ParseExampleV2}}]] [Op:IteratorGetNext]
the roadgraph_samples/dir was available among the features, I tested it for all versions of the .tf motion dataset. Also when I eliminate that feature, another feature turns into an error


[GOBBLIN-1078] Coordination between task cancel and initialization in Helix Task

Dear Gobblin maintainers,
Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!
JIRA

https://issues.apache.org/jira/browse/GOBBLIN-1078

Description
The task cancel and task.run is called in different thread from helix side, which introduced problems when:

Task get cancelled for some reasons from Helix side, therefore calling SingleTask#cancel
However, TaskAttempt object within SingleTask has not been initialized, therefore it didn't pass the non-null checking and only prints a log. After that, the run method in different thread start to run and never get cancelled.

This sequence could result in violation of helix quota in each participant: While helix believe there's no partition assigned to a participant and assign a new partition, the previous not-yet-cancelled partition is still running.
We added a barrier in cancel method to ensure cancel is blocked if taskAttempt object is not yet being initialized. Added unit test to simulate the sequence as well.
Tests

[ ] My PR adds the following unit tests OR does not need testing for this extremely good reason:

Commits

[ ] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

@ZihanLi58  Please take a look whenever you have time, thanks !

Codecov Report

Merging #2919 into master will increase coverage by 41.35%.
The diff coverage is 78.94%.

@@              Coverage Diff              @@
##             master    #2919       +/-   ##
=============================================
+ Coverage      4.12%   45.48%   +41.35%
- Complexity      750     9110     +8360
=============================================
  Files          1936     1936
  Lines         73046    73058       +12
  Branches       8046     8050        +4
=============================================
+ Hits           3016    33229    +30213
+ Misses        69710    36772    -32938
- Partials        320     3057     +2737

Impacted Files
Coverage Δ
Complexity Δ

...a/org/apache/gobblin/cluster/GobblinHelixTask.java
77.61% <ø> (+77.61%)
6.00 <0.00> (+6.00)

...in/java/org/apache/gobblin/cluster/SingleTask.java
84.84% <78.94%> (+84.84%)
13.00 <5.00> (+13.00)

...gobblin/service/monitoring/JobStatusRetriever.java
0.00% <0.00%> (ø)
2.00% <0.00%> (+2.00%)

...ata/management/copy/hive/HivePartitionFileSet.java
0.95% <0.00%> (+0.95%)
1.00% <0.00%> (+1.00%)

...ain/java/org/apache/gobblin/runtime/TaskState.java
81.97% <0.00%> (+1.16%)
32.00% <0.00%> (ø%)

...pache/gobblin/runtime/GobblinMultiTaskAttempt.java
57.32% <0.00%> (+1.25%)
28.00% <0.00%> (+2.00%)

...ava/org/apache/gobblin/runtime/MultiConverter.java
83.60% <0.00%> (+1.63%)
9.00% <0.00%> (+1.00%)

...rg/apache/gobblin/runtime/FsDatasetStateStore.java
73.80% <0.00%> (+1.78%)
35.00% <0.00%> (+1.00%)

.../java/org/apache/gobblin/runtime/TaskExecutor.java
45.35% <0.00%> (+2.73%)
9.00% <0.00%> (+1.00%)

...org/apache/gobblin/yarn/GobblinYarnTaskRunner.java
2.98% <0.00%> (+2.98%)
1.00% <0.00%> (+1.00%)

... and 1112 more

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 7a328f9...751e0a1. Read the comment docs.

@autumnust - On thinking more about the synchronization problem between GobblinMultiTaskAttempt#run() and cancel() methods, I think the following strategy might work. You can create a countdownLatch object that is shared between the run() and cancel() threads. When a cancel() is invoked, the countDownLatch is incremented. The cancel() may proceed to perform other actions but before it returns, it blocks until this latch is down to 0. The run() thread on the other hand, detects that the latch has been incremented, cancels the tasks submitted to the task executor, decrements the latch and returns. This should solve the synchronization issues between the threads without needing a lock/condition variable.

Codecov Report

Merging #2919 into master will decrease coverage by 32.18%.
The diff coverage is 33.33%.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2747b8d...6434220. Read the comment docs.


when creating a seller, remove asking for the royalty recipient, as it's in contradiction with ERC-2981, and how Opensea now works

When creating a seller, it is asked the royalty recipient address
This address will be set in the voucher contract metadata.
However neihter Opensea, nor the ERC-2981, still consider the voucher metadata.
Instead, an on-chain method of the voucher contract is called.
Doing so, the royalty recipient will always be the seller treasury account (at the time the data is fetched by Opensea, as we know they don't update this info in the future)

https://docs.google.com/document/d/1oqgaEQsyke7mf2DL1B6xy5dFV7fxSqGoxbQCxteFo1o


cose-envelope: merge changes from main

The cose-envelope branch is not in a state where meaningful changes can be made without first merging with all changes from main. This PR is doing that and also aligns the COSE spec to the JWS spec (mostly sections and header parameters). I am fully aware that the header parameter labels may still change, but let's handle that in follow-up PRs.
Note: I suggest reviewers look at what the post-merge result would look like when comparing with main (instead of merging into cose-envelope):
https://github.com/notaryproject/notaryproject/compare/main...letmaik:letmaik/cose-envelope-patches

Merging as this is resolving the baseline, and this branch will still go through PR review before merging.
Any specific questions or concerns, please PR into this branch, and/or provide feedback on #148


correct some spelling mistakes

Has been lurking as a patch in the Debian source package. Much better to have it applied upstream!

Thank you so much :D


Change a protected VM to a different Replication Policy

Can the replication policy assigned to a protected VM be changed to a different policy after replication is enabled?  I see an question/answer for updating the replication policy, but I don't see anything about changing the VM to a different replication policy.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: ee1b5526-edb7-fa2f-a6f4-de75c5fd39a3
Version Independent ID: d1815c07-d020-8d86-75cf-a193e32bba03
Content: Common questions about Azure VM disaster recovery with Azure Site Recovery - Azure Site Recovery
Content Source: articles/site-recovery/azure-to-azure-common-questions.md
Service: site-recovery
GitHub Login: @sideeksh
Microsoft Alias: v-ssenthilna

Since this channel is for driving improvements towards MS Docs, could you provide the URL of the specific documentation that your feedback is applicable to? That way, we are able to make sure your feedback is addressed by the right team.
The best place for specific answers about implementations are going to be the Microsoft Q&A and Stack Overflow forums. We actively look through posts in the forums, and will do our best to get you going in the right direction!

Sorry, I thought the comment was linked to the article I was reading.  Here is a link:  https://docs.microsoft.com/en-us/azure/site-recovery/azure-to-azure-common-questions#can-i-change-the-replication-policy-after-replication-is-enabled
This answers the question can the settings of the replication policy be changed.  I am asking if the policy assigned to a VM can be changed to another policy and if so, how?

The policy is associated with the Recovery Services vault. It can be updated with your preferred values for app-consistent recovery points, duration of retention of recovery points but cannot be changed once associated.

@sideeksh  - Thank you for providing your insights.
@eddypuck - I hope @sideeksh has answered your question.
At this moment, since there is no doc update required, we will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Allow limited user to edit their own password

@zacharyrankin, when a user with a "Limited" access role submits the form to save their own password, they get a message that says "Not Authorized". This PR fixes the issue by redirecting back to the edit profile page instead of the restricted list users page.

Ping @zacharyrankin. Please 🙏

Nice, thanks @lightster


Add Jenkins

@mohhef Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.


Move codespell configuration to pyproject.toml

The action does not yet support the TOML configuration: https://github.com/codespell-project/actions-codespell/pull/60

outdated.


Warn users when they leave the playground without saving a variant

issue #340 : Warn users if they attempt to navigate outside of the playground with an unsaved configuration.

@bekossy why did you close this?

@bekossy why did you close this?

I noticed a slight bug in the code and I am working on it


Cross-compiling for Windows with Mono on Linux with mingw-w64-gcc

Godot version:
master (https://github.com/godotengine/godot/commit/3db1d400458853bfa33c4605c819d368c11e4a57)
OS/device including version:
Arch Linux x86_64
Issue description:
I compiled mono from source for linux and windows using this documentation: https://www.mono-project.com/docs/compiling-mono/windows/#detailed-build-instructions
./autogen.sh --prefix='/opt/mingw-mono' --host=x86_64-w64-mingw32 --disable-boehm
make -j8
sudo make install

Important: I cross-compiled it on Linux using mingw and didn't use Windows / Cygwin
For Linux I also have mono, msbuild, nuget and pkg-config installed.
The path for the compiled mono dirs are /opt/mono and /opt/mingw-mono
While compiling for Linux works with
# Build temporary binary
scons p=x11 tools=yes module_mono_enabled=yes mono_glue=no use_llvm=yes use_lld=yes use_thinlto=yes mono_prefix='/opt/mono' -j 8

# Generate glue sources
bin/godot.x11.tools.64.llvm.mono --generate-mono-glue modules/mono/glue
echo 'Linux'
scons p=x11 bits=64 target=release_debug tools=yes use_llvm=yes use_lld=yes use_thinlto=yes module_mono_enabled=yes -j 8

I get an error using p=windows on Linux
scons p=windows tools=yes module_mono_enabled=yes mono_glue=no use_lto=yes mono_prefix='/opt/mingw-mono' -j 8

Is cross-compiling mono with mingw on Linux supported? Do I need Visual Studio instead?
(If it's not supported it could be labeled as a feature request or docs could be improved by mentioning state of mono support in https://docs.godotengine.org/en/latest/development/compiling/compiling_for_windows.html#cross-compiling-for-windows-from-other-operating-systems)
Steps to reproduce:
Output:
[user@archlinux godot]$ scons p=windows tools=yes module_mono_enabled=yes mono_glue=no use_lto=yes mono_prefix='/opt/mingw-mono' -j 8
scons: Reading SConscript files ...

scons: warning: EnsureSConsVersion is ignored for development version
File "/run/media/user/user/git/godot/SConstruct", line 3, in <module>
Configuring for Windows: target=debug, bits=default
Using Mingw
Checking for `thread_local` support... supported
Found Mono root directory: /opt/mingw-mono
RuntimeError: Could not find mono library in: /opt/mingw-mono/lib:
  File "/run/media/user/user/git/godot/SConstruct", line 517:
    SConscript("modules/SCsub")
  File "/usr/lib/python3.7/site-packages/SCons/Script/SConscript.py", line 668:
    return method(*args, **kw)
  File "/usr/lib/python3.7/site-packages/SCons/Script/SConscript.py", line 605:
    return _SConscript(self.fs, *files, **subst_kw)
  File "/usr/lib/python3.7/site-packages/SCons/Script/SConscript.py", line 286:
    exec(compile(scriptdata, scriptname, 'exec'), call_stack[-1].globals)
  File "/run/media/user/user/git/godot/modules/SCsub", line 17:
    SConscript(x + "/SCsub")
  File "/usr/lib/python3.7/site-packages/SCons/Script/SConscript.py", line 668:
    return method(*args, **kw)
  File "/usr/lib/python3.7/site-packages/SCons/Script/SConscript.py", line 605:
    return _SConscript(self.fs, *files, **subst_kw)
  File "/usr/lib/python3.7/site-packages/SCons/Script/SConscript.py", line 286:
    exec(compile(scriptdata, scriptname, 'exec'), call_stack[-1].globals)
  File "/run/media/user/user/git/godot/modules/mono/SCsub", line 39:
    mono_configure.configure(env, env_mono)
  File "/run/media/user/user/git/godot/modules/mono/build_scripts/mono_configure.py", line 122:
    raise RuntimeError('Could not find mono library in: ' + mono_lib_path)
[user@archlinux godot]$

Official Mono builds for Windows are actually cross-compiled from Linux, so it's possible. I'm not very familiar with the way it's done yet, but here's the Dockerfile used to generate the container: https://github.com/godotengine/build-containers/blob/master/Dockerfile.windows
As you can see, the native Linux mono binaries are actually used in place of the mingw generated ones for some reason. (I didn't write it, @hpvb did.)

I tried ./configure --prefix=/root/dependencies/mono-64 --host=x86_64-w64-mingw32 --disable-boehm --disable-mcs-build --disable-executables from the dockerfile and also some other combinations and the build either fails or is missing some .lib files, even after copying files and using symlinks.
ls output from https://www.mono-project.com/download/stable/#download-win install using wine-staging:
[user@archlinux lib]$ ls
ironpython               mono-2.0-sgen.lib    MonoPosixHelper.pdb
ironruby                 mono-2.0-sgen.pdb    mono-source-libs
libmono-static-sgen.lib  monodoc              pkgconfig
mono                     MonoPosixHelper.lib  xsp
[user@archlinux lib]$

ls output from cross-compiled mono using mingw-w64 from https://github.com/mono/mono.git:
[user@archlinux lib]$ ls
libMonoPosixHelper.a      libmonosgen-2.0.a      mono
libMonoPosixHelper.dll.a  libmonosgen-2.0.dll.a  pkgconfig
libMonoPosixHelper.la     libmonosgen-2.0.la
[user@archlinux lib]$

When cross-compiling for Windows with Mono on Linux, it only works with the wine windows install.
Found a similar issue, don't know if discussion should be there or still in this issue:
https://github.com/godotengine/godot/issues/22104

I was able to build Godot alpha 4569f5ec82 with Mono for win32/64 on Ubuntu 19.04 without wine.
First I had previously set up these compiling environments, each of which had their own dependencies, which are described in the docs:

Linux/64
Windows 64 and 32
Linux/64 with mono

To set up linux/mono I did not compile it myself. I followed these instructions, which just meant adding mono's ubuntu repository and installing apt install mono-devel.
https://www.mono-project.com/download/stable/
I now have:
mono-devel <IP_ADDRESS>-0xamarin3+ubuntu1804b1
gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1)
mingw-w64 6.0.0-3

and can build all of the above environments.
From here, I found that scons was looking for MonoPosixHelper.dll. I mostly followed the docker file linked by @akien-mga.
https://github.com/godotengine/build-containers/blob/master/Dockerfile.windows
Specifically, I downloaded the <IP_ADDRESS> source tarball to match what was already on my system, then followed this section. Except I had the install directory in my home directory instead of /root. I also linked libMonoPosixHelper.dll instead of copying it. Finally, I ran one command at a time, instead of all at once with the &&s.
 ./configure --prefix=/root/dependencies/mono-64 --host=x86_64-w64-mingw32 --disable-boehm --disable-mcs-build --disable-executables && \
    echo '#define HAVE_STRUCT_SOCKADDR_IN6 1' >> config.h && \
    make -j && \
    make install && \
    make distclean && \
    cp /root/dependencies/mono-64/bin/libMonoPosixHelper.dll /root/dependencies/mono-64/bin/MonoPosixHelper.dll && \
    rm -f /root/dependencies/mono-64/bin/mono /root/dependencies/mono-64/bin/mono-sgen && \
    ln -s /usr/bin/mono /root/dependencies/mono-64/bin/mono && \
    ln -s /usr/bin/mono-sgen /root/dependencies/mono-64/bin/mono-sgen && \
    ln -sf /usr/lib/mono/* /root/dependencies/mono-64/lib/mono || /bin/true && \
    cp -rvp /etc/mono /root/dependencies/mono-64/etc && \
    ./configure --prefix=/root/dependencies/mono-32 --host=i686-w64-mingw32 --disable-boehm --disable-mcs-build --disable-executables && \
    echo '#define HAVE_STRUCT_SOCKADDR_IN6 1' >> config.h && \
    make -j && \
    make install && \
    make distclean && \
    cp /root/dependencies/mono-32/bin/libMonoPosixHelper.dll /root/dependencies/mono-32/bin/MonoPosixHelper.dll && \
    rm -f /root/dependencies/mono-32/bin/mono /root/dependencies/mono-32/bin/mono-sgen && \
    ln -s /usr/bin/mono /root/dependencies/mono-32/bin/mono && \
    ln -s /usr/bin/mono-sgen /root/dependencies/mono-32/bin/mono-sgen && \
    ln -sf /usr/lib/mono/* /root/dependencies/mono-32/lib/mono || /bin/true && \
    cp -rvp /etc/mono /root/dependencies/mono-32/etc && \
    rm -rf /root/mono-${mono_version}

Next, instead of the MONO32_PREFIX which are deprecated, I ran commands like these to compile the editor:
scons -j12 p=windows bits=64 tools=yes target=release_debug module_mono_enabled=yes mono_static=yes mono_glue=yes copy_mono_root=yes mono_prefix=/home/cory/dependencies/mono-64
or for 32-bit and a template:
scons -j12 p=windows bits=32 tools=no target=release debug_symbols=no module_mono_enabled=yes mono_static=yes mono_glue=yes mono_prefix=/home/cory/dependencies/mono-32
I only generated the mono glue module once before my linux/mono compile and there was no issue using it for both linux and windows compilation. Everything compiled and linked fine. I haven't actually run the binaries in windows.... Once I package them up properly, I'll confirm that and update.

Update: the windows binaries crash upon load with either Mono 6.4.0 or <IP_ADDRESS> and don't report errors, so I'm not sure what to do next.
I installed mono 6.4.0 on my windows system and I can run v3.2 beta 1 fine, but my custom build loads the project screen then quits.  The mono_log file complains on and on about System.native. Here's a sample:
DllImport error loading library 'D:\Data\godot-releases\mono\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5\System.Native': 'The system cannot find the file specified.
'. (in domain Mono, info)
DllImport error loading library 'D:\Data\godot-releases\mono\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5\System.Native.dll': 'The system cannot find the file specified.
'. (in domain Mono, info)
DllImport error loading library 'D:\Data\godot-releases\mono\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5\System.Native.dll': 'The system cannot find the file specified.
'. (in domain Mono, info)
DllImport error loading library 'System.Native': 'The system cannot find the file specified.
'. (in domain Mono, info)
DllImport error loading library 'System.Native.dll': 'The system cannot find the file specified.
'. (in domain Mono, info)

I noticed the blog for beta1 said it was built with Mono <IP_ADDRESS>. So on both windows and ubuntu I downgraded using the mono-project packages. The stock ubuntu packages don't work as they don't include msbuild and xbuild doesn't work. After that I rebuilt the mono dependencies with the steps in my last post (updated above) and it built just fine. Again the linux version works with mono 5 or 6..
In windows the binary loads the project screen, then quits.  My custom build mono log:
Config attempting to parse: 'D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/etc\mono\config'. (in domain Mono, info)
Image addref mscorlib[0000022A4C80A420] (asmctx DEFAULT) -> D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5/mscorlib.dll[0000022A4C944A70]: 2 (in domain Mono, info)
Prepared to set up assembly 'mscorlib' (D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5/mscorlib.dll) (in domain Mono, info)
AOT: image 'D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5/mscorlib.dll.dll' not found: The system cannot find the file specified.
 (in domain Mono, info)
AOT: image 'D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/aot-cache/amd64/mscorlib.dll.dll' not found: The system cannot find the path specified.
 (in domain Mono, info)
Assembly mscorlib[0000022A4C80A420] added to domain GodotEngine.RootDomain, ref_count=1 (in domain Mono, info)
Assembly mscorlib[0000022A4C80A420] added to domain GodotEngine.Domain.Scripts, ref_count=2 (in domain Mono, info)
Image addref GodotSharp[0000022A4C809DF0] (asmctx DEFAULT) -> D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Api/Debug/GodotSharp.dll[0000022A4C9D6430]: 3 (in domain Mono, info)
Prepared to set up assembly 'GodotSharp' (D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Api/Debug/GodotSharp.dll) (in domain Mono, info)
Assembly GodotSharp[0000022A4C809DF0] added to domain GodotEngine.Domain.Scripts, ref_count=1 (in domain Mono, info)
Loading reference 0 of D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Api/Debug/GodotSharp.dll asmctx DEFAULT, looking for mscorlib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089 (in domain Mono, info)
Config attempting to parse: ''. (in domain Mono, info)
Assembly Ref addref GodotSharp[0000022A4C809DF0] -> mscorlib[0000022A4C80A420]: 3 (in domain Mono, info)
Image addref GodotSharpEditor[0000022A4C809E80] (asmctx DEFAULT) -> D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Api/Debug/GodotSharpEditor.dll[0000022A4CAF82D0]: 3 (in domain Mono, info)
Prepared to set up assembly 'GodotSharpEditor' (D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Api/Debug/GodotSharpEditor.dll) (in domain Mono, info)
Assembly GodotSharpEditor[0000022A4C809E80] added to domain GodotEngine.Domain.Scripts, ref_count=1 (in domain Mono, info)
Loading reference 0 of D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Api/Debug/GodotSharpEditor.dll asmctx DEFAULT, looking for mscorlib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089 (in domain Mono, info)
Assembly Ref addref GodotSharpEditor[0000022A4C809E80] -> mscorlib[0000022A4C80A420]: 4 (in domain Mono, info)
Loading reference 2 of D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Api/Debug/GodotSharp.dll asmctx DEFAULT, looking for System, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089 (in domain Mono, info)
Image addref System[0000022A4C80A5D0] (asmctx DEFAULT) -> D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5/System.dll[0000022A4CAFBA40]: 2 (in domain Mono, info)
Prepared to set up assembly 'System' (D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5/System.dll) (in domain Mono, info)
Assembly System[0000022A4C80A5D0] added to domain GodotEngine.Domain.Scripts, ref_count=1 (in domain Mono, info)
Assembly Ref addref GodotSharp[0000022A4C809DF0] -> System[0000022A4C80A5D0]: 2 (in domain Mono, info)
Loading reference 0 of D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5/System.dll asmctx DEFAULT, looking for mscorlib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089 (in domain Mono, info)
Assembly Ref addref System[0000022A4C80A5D0] -> mscorlib[0000022A4C80A420]: 5 (in domain Mono, info)
Loading reference 2 of D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5/System.dll asmctx DEFAULT, looking for System.Configuration, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a (in domain Mono, info)
Image addref System.Configuration[0000022A4C80AA50] (asmctx DEFAULT) -> D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5/System.Configuration.dll[0000022A4CB002A0]: 2 (in domain Mono, info)
Prepared to set up assembly 'System.Configuration' (D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5/System.Configuration.dll) (in domain Mono, info)
Assembly System.Configuration[0000022A4C80AA50] added to domain GodotEngine.Domain.Scripts, ref_count=1 (in domain Mono, info)
Assembly Ref addref System[0000022A4C80A5D0] -> System.Configuration[0000022A4C80AA50]: 2 (in domain Mono, info)
Loading reference 0 of D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5/System.Configuration.dll asmctx DEFAULT, looking for mscorlib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089 (in domain Mono, info)
Assembly Ref addref System.Configuration[0000022A4C80AA50] -> mscorlib[0000022A4C80A420]: 6 (in domain Mono, info)
Loading reference 2 of D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5/System.Configuration.dll asmctx DEFAULT, looking for System, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089 (in domain Mono, info)
Assembly Ref addref System.Configuration[0000022A4C80AA50] -> System[0000022A4C80A5D0]: 3 (in domain Mono, info)
Loading reference 1 of D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5/System.Configuration.dll asmctx DEFAULT, looking for System.Xml, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089 (in domain Mono, info)
Image addref System.Xml[0000022A4C80A780] (asmctx DEFAULT) -> D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5/System.Xml.dll[0000022A4CC06100]: 2 (in domain Mono, info)
Prepared to set up assembly 'System.Xml' (D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5/System.Xml.dll) (in domain Mono, info)
Assembly System.Xml[0000022A4C80A780] added to domain GodotEngine.Domain.Scripts, ref_count=1 (in domain Mono, info)
Assembly Ref addref System.Configuration[0000022A4C80AA50] -> System.Xml[0000022A4C80A780]: 2 (in domain Mono, info)
Loading reference 0 of D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5/System.Xml.dll asmctx DEFAULT, looking for mscorlib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089 (in domain Mono, info)
Assembly Ref addref System.Xml[0000022A4C80A780] -> mscorlib[0000022A4C80A420]: 7 (in domain Mono, info)
Loading reference 2 of D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5/System.Xml.dll asmctx DEFAULT, looking for System, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089 (in domain Mono, info)
Assembly Ref addref System.Xml[0000022A4C80A780] -> System[0000022A4C80A5D0]: 4 (in domain Mono, info)
DllImport attempting to load: 'advapi32.dll'. (in domain Mono, info)
DllImport error loading library 'D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5\advapi32.dll': 'The system cannot find the file specified.
'. (in domain Mono, info)
DllImport error loading library 'D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5\advapi32.dll': 'The system cannot find the file specified.
'. (in domain Mono, info)
DllImport loaded library 'advapi32.dll'. (in domain Mono, info)
DllImport searching in: 'advapi32.dll' ('advapi32.dll'). (in domain Mono, info)
Searching for 'RegOpenKeyEx'. (in domain Mono, info)
Probing 'RegOpenKeyExW'. (in domain Mono, info)
Found as 'RegOpenKeyExW'. (in domain Mono, info)
Image addref Mono.Security[0000022A4C808A40] (asmctx DEFAULT) -> D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5/Mono.Security.dll[0000022A4CAFF1C0]: 2 (in domain Mono, info)
Prepared to set up assembly 'Mono.Security' (D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5/Mono.Security.dll) (in domain Mono, info)
Assembly Mono.Security[0000022A4C808A40] added to domain GodotEngine.Domain.Scripts, ref_count=1 (in domain Mono, info)
Loading reference 0 of D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5/Mono.Security.dll asmctx DEFAULT, looking for mscorlib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089 (in domain Mono, info)
Assembly Ref addref Mono.Security[0000022A4C808A40] -> mscorlib[0000022A4C80A420]: 8 (in domain Mono, info)
Loading reference 3 of D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib/mono/4.5/System.dll asmctx DEFAULT, looking for System.Xml, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089 (in domain Mono, info)
Assembly Ref addref System[0000022A4C80A5D0] -> System.Xml[0000022A4C80A780]: 3 (in domain Mono, info)
Image addref GodotTools[0000022A4C809BB0] (asmctx DEFAULT) -> D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Tools/GodotTools.dll[0000022A5D60A320]: 2 (in domain Mono, info)
Prepared to set up assembly 'GodotTools' (D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Tools/GodotTools.dll) (in domain Mono, info)
Assembly GodotTools[0000022A4C809BB0] added to domain GodotEngine.Domain.Scripts, ref_count=1 (in domain Mono, info)
Image addref GodotTools.ProjectEditor[0000022A4C808EC0] (asmctx DEFAULT) -> D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Tools/GodotTools.ProjectEditor.dll[0000022A5D49F270]: 2 (in domain Mono, info)
Prepared to set up assembly 'GodotTools.ProjectEditor' (D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Tools/GodotTools.ProjectEditor.dll) (in domain Mono, info)
Assembly GodotTools.ProjectEditor[0000022A4C808EC0] added to domain GodotEngine.Domain.Scripts, ref_count=1 (in domain Mono, info)
Assembly Loader probing location: 'D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib\UnnamedProject.dll'. (in domain Mono, info)
Assembly Loader probing location: 'D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64\GodotSharp\Mono\lib\mono\4.5\/Facades\UnnamedProject.dll'. (in domain Mono, info)
Assembly Loader probing location: 'D:\gd\godot-releases\mono-518\Godot_v3.2+4569f5ec82_mono_win64/GodotSharp/Mono/lib\UnnamedProject.exe'. (in domain Mono, info)

The log from beta1:
This file is identical except for the addresses and the name of the executable file, until the end of my build, so I don't include it below. Then beta1 continues on with this, so basically my build does not log any reason why it crashed, except that it does so at the point, between looking for UnnamedProject.exe in lib and then in facades.
Assembly Loader probing location: 'D:\gd\godot-releases\Godot_v3.2-beta1_mono_win64\GodotSharp\Mono\lib\mono\4.5\/Facades\UnnamedProject.exe'. (in domain Mono, info)
Loading reference 1 of D:\gd\godot-releases\Godot_v3.2-beta1_mono_win64/GodotSharp/Api/Debug/GodotSharp.dll asmctx DEFAULT, looking for System.Core, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089 (in domain Mono, info)
Image addref System.Core[0000000023B74930] (asmctx DEFAULT) -> D:\gd\godot-releases\Godot_v3.2-beta1_mono_win64/GodotSharp/Mono/lib/mono/4.5/System.Core.dll[000000002418A8C0]: 2 (in domain Mono, info)
Prepared to set up assembly 'System.Core' (D:\gd\godot-releases\Godot_v3.2-beta1_mono_win64/GodotSharp/Mono/lib/mono/4.5/System.Core.dll) (in domain Mono, info)
Assembly System.Core[0000000023B74930] added to domain GodotEngine.Domain.Scripts, ref_count=1 (in domain Mono, info)
Assembly Ref addref GodotSharp[00000000123C05E0] -> System.Core[0000000023B74930]: 2 (in domain Mono, info)
Loading reference 0 of D:\gd\godot-releases\Godot_v3.2-beta1_mono_win64/GodotSharp/Mono/lib/mono/4.5/System.Core.dll asmctx DEFAULT, looking for mscorlib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089 (in domain Mono, info)
Assembly Ref addref System.Core[0000000023B74930] -> mscorlib[00000000123C04C0]: 9 (in domain Mono, info)
GC_MAJOR: (user request) time 20.79ms, stw 20.93ms los size: 1024K in use: 64K (in domain Mono, info)
GC_MAJOR_SWEEP: major size: 1088K in use: 194K (in domain Mono, info)
GC_MAJOR: (user request) time 0.86ms, stw 1.00ms los size: 1024K in use: 64K (in domain Mono, info)
GC_MAJOR_SWEEP: major size: 1088K in use: 194K (in domain Mono, info)
GC_MAJOR: (user request) time 0.88ms, stw 1.13ms los size: 1024K in use: 64K (in domain Mono, info)
GC_MAJOR_SWEEP: major size: 1088K in use: 195K (in domain Mono, info)
GC_MINOR: (user request) time 1.15ms, stw 1.33ms promoted 0K major size: 1088K in use: 195K los size: 1024K in use: 64K (in domain Mono, info)
Unloading domain GodotEngine.Domain.Scripts[0000000012516CC0], assembly mscorlib[00000000123C04C0], ref_count=9 (in domain Mono, info)
Unloading domain GodotEngine.Domain.Scripts[0000000012516CC0], assembly GodotSharp[00000000123C05E0], ref_count=1 (in domain Mono, info)
Unloading assembly GodotSharp [00000000123C05E0]. (in domain Mono, info)
Unloading image data-00000000125752F0 [000000001263A170]. (in domain Mono, info)
Unloading image D:\gd\godot-releases\Godot_v3.2-beta1_mono_win64/GodotSharp/Api/Debug/GodotSharp.dll [0000000012561820]. (in domain Mono, info)
Unloading domain GodotEngine.Domain.Scripts[0000000012516CC0], assembly GodotSharpEditor[00000000123C0550], ref_count=1 (in domain Mono, info)
Unloading assembly GodotSharpEditor [00000000123C0550]. (in domain Mono, info)
Unloading image data-000000001266B420 [00000000126701A0]. (in domain Mono, info)
Unloading image D:\gd\godot-releases\Godot_v3.2-beta1_mono_win64/GodotSharp/Api/Debug/GodotSharpEditor.dll [0000000012662CD0]. (in domain Mono, info)
Unloading domain GodotEngine.Domain.Scripts[0000000012516CC0], assembly System[00000000123C1480], ref_count=3 (in domain Mono, info)
Unloading domain GodotEngine.Domain.Scripts[0000000012516CC0], assembly System.Configuration[00000000123C0AF0], ref_count=2 (in domain Mono, info)
Unloading domain GodotEngine.Domain.Scripts[0000000012516CC0], assembly System.Xml[00000000123C0A60], ref_count=3 (in domain Mono, info)
Unloading domain GodotEngine.Domain.Scripts[0000000012516CC0], assembly Mono.Security[00000000123C1750], ref_count=1 (in domain Mono, info)
Unloading assembly Mono.Security [00000000123C1750]. (in domain Mono, info)
Unloading image D:\gd\godot-releases\Godot_v3.2-beta1_mono_win64/GodotSharp/Mono/lib/mono/4.5/Mono.Security.dll [000000001266A3E0]. (in domain Mono, info)
Unloading domain GodotEngine.Domain.Scripts[0000000012516CC0], assembly GodotTools[00000000123C1900], ref_count=1 (in domain Mono, info)
Unloading assembly GodotTools [00000000123C1900]. (in domain Mono, info)
Unloading image D:\gd\godot-releases\Godot_v3.2-beta1_mono_win64/GodotSharp/Tools/GodotTools.dll [0000000012867AF0]. (in domain Mono, info)
Unloading domain GodotEngine.Domain.Scripts[0000000012516CC0], assembly GodotTools.ProjectEditor[00000000123C1A20], ref_count=1 (in domain Mono, info)
Unloading assembly GodotTools.ProjectEditor [00000000123C1A20]. (in domain Mono, info)
Unloading image D:\gd\godot-releases\Godot_v3.2-beta1_mono_win64/GodotSharp/Tools/GodotTools.ProjectEditor.dll [000000001278AB20]. (in domain Mono, info)
Unloading domain GodotEngine.Domain.Scripts[0000000012516CC0], assembly System.Core[0000000023B74930], ref_count=1 (in domain Mono, info)
Unloading assembly System.Core [0000000023B74930]. (in domain Mono, info)
Unloading image D:\gd\godot-releases\Godot_v3.2-beta1_mono_win64/GodotSharp/Mono/lib/mono/4.5/System.Core.dll [000000002418A8C0]. (in domain Mono, info)
GC_MAJOR: (user request) time 0.12ms, stw 0.27ms los size: 0K in use: 0K (in domain Mono, info)
GC_MAJOR_SWEEP: major size: 240K in use: 2K (in domain Mono, info)
GC_MAJOR: (user request) time 0.09ms, stw 0.21ms los size: 0K in use: 0K (in domain Mono, info)
GC_MAJOR_SWEEP: major size: 240K in use: 2K (in domain Mono, info)
Unloading domain GodotEngine.RootDomain[000000001249B050], assembly mscorlib[00000000123C04C0], ref_count=4 (in domain Mono, info)
Assembly image 'D:\gd\godot-releases\Godot_v3.2-beta1_mono_win64/GodotSharp/Mono/lib/mono/4.5/System.dll' still loaded at shutdown. (in domain Mono, info)
Assembly image 'D:\gd\godot-releases\Godot_v3.2-beta1_mono_win64/GodotSharp/Mono/lib/mono/4.5/System.Configuration.dll' still loaded at shutdown. (in domain Mono, info)
Assembly image 'D:\gd\godot-releases\Godot_v3.2-beta1_mono_win64/GodotSharp/Mono/lib/mono/4.5/mscorlib.dll' still loaded at shutdown. (in domain Mono, info)
Assembly image 'D:\gd\godot-releases\Godot_v3.2-beta1_mono_win64/GodotSharp/Mono/lib/mono/4.5/System.Xml.dll' still loaded at shutdown. (in domain Mono, info)

As far as differences with the GodotSharp directory, beta1 has these extra files (same with my mono6.4. version):
GodotSharp/Mono/lib/mono/4.5/Mono.Profiler.Log.dll
GodotSharp/Mono/lib/mono/4.5/Mono.Security.Win32.dll
GodotSharp/Mono/lib/mono/4.5/nunit-console-runner.dll
GodotSharp/Mono/lib/mono/4.5/nunit.core.dll
GodotSharp/Mono/lib/mono/4.5/nunit.core.extensions.dll
GodotSharp/Mono/lib/mono/4.5/nunit.core.interfaces.dll
GodotSharp/Mono/lib/mono/4.5/nunit.framework.dll
GodotSharp/Mono/lib/mono/4.5/nunit.framework.extensions.dll
GodotSharp/Mono/lib/mono/4.5/nunit.mocks.dll
GodotSharp/Mono/lib/mono/4.5/nunit.util.dll

Any other ideas of what can be done now?

I discovered the it leaves a dump file when crashing in %appdata%/local/crashdumps. Opening the debug file in the msvc debugger it reports:
Exception code: 0xC0000005
Exception information: The thread tried to read from or write to a virtual address for which it does not have the appropriate access.

I have scripts in the godot-mono-builds repo that can be used to compile the mono runtime. The desktop one is not fully tested yet though but it may work.
Regarding the error OP mentioned, I think it's because we have hard-coded .lib as the library extension: https://github.com/godotengine/godot/blob/01e24447a593ef592b3988194f9bd7a8cad2613c/modules/mono/build_scripts/mono_configure.py#L119
MinGW's libraries use the .a extension (keep in mind you will need to build Godot with MinGW as well). Not sure if replacing the hard-coded extension is enough to fix this or if some other changes may be necessary.
That being said, that block of code is for dynamic linking Mono. Static linking with mono_static=yes probably works already. Did you try that?

@neikeq That repository says it doesn't support compiling for macos or windows. But this issue is for cross compiling for windows.
@LinuxUserGD I can now cross-compile for mono/windows AND have the binaries work in windows. Since the journey above was fruitless, I decided to use the official build docker and it finally works for me. Here's how:

Install podman or docker. I used the podman on ubuntu.

Clone the build-container repo https://github.com/godotengine/build-containers

Run ./build.sh <IP_ADDRESS> or manually step through the script. You really only need through the line that calls Docker.windows for this issue.

Once that docker is built, run it and mount your godot source into it.

$ podman images
REPOSITORY                  TAG        IMAGE ID       CREATED          SIZE
localhost/godot-windows     latest     d09e4cd53ef4   35 minutes ago   3.36 GB
localhost/godot-mono-glue   latest     a17140829795   7 hours ago      1.4 GB
localhost/godot-mono        <IP_ADDRESS>   3936dd848bee   7 hours ago      1.16 GB
localhost/godot-export      latest     0fe6bed537eb   8 hours ago      691 MB
localhost/godot-fedora      latest     4efc1eb22ff9   8 hours ago      255 MB
docker.io/library/fedora    30         89d6d6a7d521   13 days ago      255 MB

$ podman run -it --rm  -v /home/cory/gd/godot:/root/godot godot-windows /usr/bin/bash

# (godot-windows refers to the localhost/godot-windows podman images above)

[root@a117e628763d ~]# cd godot
[root@a117e628763d godot]# scons -j12 p=windows bits=64 tools=yes target=release_debug module_mono_enabled=yes mono_static=yes mono_glue=yes copy_mono_root=yes mono_prefix=/root/dependencies/mono-64

You can access your build in the godot/bin directory either inside the docker shell or in your regular shell. I bundled the GodotSharp directory with my executable, transferred to windows and the 64-bit binary worked fine on win64. The website says the official 32-bit mono doesn't work on win64, and I confirmed mine crashes upon load as well.

See this issue for reference:
https://github.com/godotengine/build-containers/issues/9
Thanks for the help @akien-mga. How about if we add something like these notes to the docker repo readme so people who are new to dockers don't have to figure it all out from scratch as I did?

@neikeq That repository says it doesn't support compiling for macos or windows. But this issue is for cross compiling for windows.

Cross-compiling for macOS is not supported, but cross-compiling for Windows is. What is not supported is building on Windows itself, although cygwin probably works.
There's an example there for Windows (assuming you have the mingw-w64 package):
export MONO_SOURCE_ROOT=$HOME/git/mono

# Build the runtimes for 32-bit and 64-bit Windows.
./desktop.py windows configure --target=i686 --target=x86_64 --mxe-prefix=/usr
./desktop.py windows make --target=i686 --target=x86_64 --mxe-prefix=/usr

@neikeq With https://github.com/godotengine/godot-mono-builds --mxe-prefix seems to be not an accepted parameter so it didn't work for me
On mono itself (without using docker) it often showed me _chk_fail but now with git clone --recursive https://github.com/mono/mono.git and ./autogen.sh --prefix=/root/dependencies/mono-64 --host=x86_64-w64-mingw32 --disable-boehm --disable-mcs-build it worked for me even without the fixes in https://github.com/godotengine/build-containers/blob/master/files/mono-build-win32.sh
But still running scons p=windows tools=yes module_mono_enabled=yes mono_glue=no mono_static=yes copy_mono_root=yes mono_prefix='/run/media/user/user/git/mono/dependencies/mono-64' -j 8 gives me this error:
[100%] Ranlib Library         ==> modules/libmodules.windows.tools.64.a
[100%] Linking Program        ==> bin/godot.windows.tools.64.mono.exe
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: core/libcore.windows.tools.64.a(zutil.windows.tools.64.o): in function `zlibVersion':
/run/media/user/user/git/godot/thirdparty/zlib/zutil.c:28: multiple definition of `zlibVersion'; /run/media/user/user/git/mono/dependencies/mono-64/lib/libmonosgen-2.0.a(zutil.o):/run/media/user/compile/git/mono/mono/zlib/zutil.c:30: first defined here
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: core/libcore.windows.tools.64.a(zutil.windows.tools.64.o): in function `zlibCompileFlags':
/run/media/user/user/git/godot/thirdparty/zlib/zutil.c:33: multiple definition of `zlibCompileFlags'; /run/media/user/user/git/mono/dependencies/mono-64/lib/libmonosgen-2.0.a(zutil.o):/run/media/user/compile/git/mono/mono/zlib/zutil.c:113: first defined here
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: core/libcore.windows.tools.64.a(zutil.windows.tools.64.o): in function `zError':
/run/media/user/user/git/godot/thirdparty/zlib/zutil.c:135: multiple definition of `zError'; /run/media/user/user/git/mono/dependencies/mono-64/lib/libmonosgen-2.0.a(zutil.o):/run/media/user/compile/git/mono/mono/zlib/zutil.c:136: first defined here
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: core/libcore.windows.tools.64.a(zutil.windows.tools.64.o): in function `zcalloc':
/run/media/user/user/git/godot/thirdparty/zlib/zutil.c:309: multiple definition of `zcalloc'; /run/media/user/user/git/mono/dependencies/mono-64/lib/libmonosgen-2.0.a(zutil.o):/run/media/user/compile/git/mono/mono/zlib/zutil.c:311: first defined here
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: core/libcore.windows.tools.64.a(zutil.windows.tools.64.o): in function `zcfree':
/run/media/user/user/git/godot/thirdparty/zlib/zutil.c:318: multiple definition of `zcfree'; /run/media/user/user/git/mono/dependencies/mono-64/lib/libmonosgen-2.0.a(zutil.o):/run/media/user/compile/git/mono/mono/zlib/zutil.c:318: first defined here
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: core/libcore.windows.tools.64.a(zutil.windows.tools.64.o):zutil.c:(.rdata+0x80): multiple definition of `z_errmsg'; /run/media/user/user/git/mono/dependencies/mono-64/lib/libmonosgen-2.0.a(zutil.o):zutil.c:(.rdata+0x80): first defined here
collect2: error: ld returned 1 exit status
scons: *** [bin/godot.windows.tools.64.mono.exe] Error 1
scons: building terminated because of errors.

and with builtin_zlib=no:
[100%] Ranlib Library         ==> core/libcore.windows.tools.64.a
[100%] Linking Program        ==> bin/godot.windows.tools.64.mono.exe
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: drivers/libdrivers.windows.tools.64.a(pngwrite.windows.tools.64.o): in function `png_write_destroy':
/run/media/user/user/git/godot/thirdparty/libpng/pngwrite.c:954: undefined reference to `deflateEnd'
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: drivers/libdrivers.windows.tools.64.a(pngwutil.windows.tools.64.o): in function `png_deflate_claim':
/run/media/user/user/git/godot/thirdparty/libpng/pngwutil.c:395: undefined reference to `deflateEnd'
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /run/media/user/user/git/godot/thirdparty/libpng/pngwutil.c:413: undefined reference to `deflateReset'
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /run/media/user/user/git/godot/thirdparty/libpng/pngwutil.c:417: undefined reference to `deflateInit2_'
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: drivers/libdrivers.windows.tools.64.a(pngwutil.windows.tools.64.o): in function `png_text_compress':
/run/media/user/user/git/godot/thirdparty/libpng/pngwutil.c:580: undefined reference to `deflate'
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: drivers/libdrivers.windows.tools.64.a(pngwutil.windows.tools.64.o): in function `png_compress_IDAT':
/run/media/user/user/git/godot/thirdparty/libpng/pngwutil.c:986: undefined reference to `deflate'
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: editor/libeditor.windows.tools.64.a(export.windows.tools.64.o): in function `AppxPackager::add_file(String, unsigned char const*, unsigned long long, int, int, bool)':
/run/media/user/user/git/godot/platform/uwp/export/export.cpp:494: undefined reference to `deflateInit2_'
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /run/media/user/user/git/godot/platform/uwp/export/export.cpp:519: undefined reference to `deflate'
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /run/media/user/user/git/godot/platform/uwp/export/export.cpp:552: undefined reference to `deflate'
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /run/media/user/user/git/godot/platform/uwp/export/export.cpp:560: undefined reference to `deflateEnd'
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: core/libcore.windows.tools.64.a(zip.windows.tools.64.o): in function `zipOpenNewFileInZip4_64':
/run/media/user/user/git/godot/thirdparty/minizip/zip.c:1225: undefined reference to `deflateInit2_'
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: core/libcore.windows.tools.64.a(zip.windows.tools.64.o): in function `zipWriteInFileInZip':
/run/media/user/user/git/godot/thirdparty/minizip/zip.c:1477: undefined reference to `deflate'
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: core/libcore.windows.tools.64.a(zip.windows.tools.64.o): in function `zipCloseFileInZipRaw64':
/run/media/user/user/git/godot/thirdparty/minizip/zip.c:1547: undefined reference to `deflate'
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /run/media/user/user/git/godot/thirdparty/minizip/zip.c:1589: undefined reference to `deflateEnd'
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: core/libcore.windows.tools.64.a(compression.windows.tools.64.o): in function `Compression::compress(unsigned char*, unsigned char const*, int, Compression::Mode)':
/run/media/user/user/git/godot/core/io/compression.cpp:67: undefined reference to `deflateInit2_'
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /run/media/user/user/git/godot/core/io/compression.cpp:72: undefined reference to `deflateBound'
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /run/media/user/user/git/godot/core/io/compression.cpp:76: undefined reference to `deflate'
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /run/media/user/user/git/godot/core/io/compression.cpp:78: undefined reference to `deflateEnd'
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: core/libcore.windows.tools.64.a(compression.windows.tools.64.o): in function `Compression::get_max_compressed_buffer_size(int, Compression::Mode)':
/run/media/user/user/git/godot/core/io/compression.cpp:119: undefined reference to `deflateInit2_'
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /run/media/user/user/git/godot/core/io/compression.cpp:122: undefined reference to `deflateBound'
/usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /run/media/user/user/git/godot/core/io/compression.cpp:123: undefined reference to `deflateEnd'
collect2: error: ld returned 1 exit status
scons: *** [bin/godot.windows.tools.64.mono.exe] Error 1
scons: building terminated because of errors.

Same issue when copying mono from docker root into godot folder with cp -R and then compiling under Arch Linux. Using native zlib (mingw-w64-zlib aur package) and compiling without builtin in mono gives me a similar error.
Only compiling from docker with podman run -it --rm  -v /home/cory/gd/godot:/root/godot [docker id] /usr/bin/bash worked for me (it's still a bit more complicated as each switch from using docker-windows and compiling for native linux requires to delete godot cache with git clean -x -q -f).
Using official mono with mingw worked for me previously but now godot can't find mono libs (only static mingw ones). @akien-mga mentioned that it would require Cygwin or MSYS2 installed in wine but I have no idea how a correct setup should look like.
ls output from cross-compiled mono using mingw-w64 from https://github.com/mono/mono.git, folder /lib looks a bit better now (I didn't add symbolic links):
[user@archlinux lib]$ ls
libmono-2.0.a      libMonoPosixHelper.a      libmonosgen-2.0.a      mono
libmono-2.0.dll.a  libMonoPosixHelper.dll.a  libmonosgen-2.0.dll.a  pkgconfig
libmono-2.0.la     libMonoPosixHelper.la     libmonosgen-2.0.la
[user@archlinux lib]$

Ok, I see, thanks for these informations.

The docker approach didn't work for me unfortunately, but I think I've stumbled something else, see godotengine/build-containers#74, any hints appreciated!


[BUG] VM Cloud Config initial failed without any errors

Describe the bug
When Creating VM with customized cloud config as below, the cloud-init will failed without any errors.
# cloud-config
password: password
chpasswd: { expire: False }
sshpwauth: True
package_update: true
packages:
  - qemu-guest-agent
runcmd:
  - - systemctl
    - enable
    - --now
    - qemu-guest-agent.service

To Reproduce
Steps to reproduce the behavior:

Install Harvester with any nodes
Create Image for VM creation
Create VM with the cloud config above
Start the VM and login via Web VNC
User should able to login with the password

Expected behavior
Cloud config should be applied.
Environment:

Harvester ISO version: v1.0-3b6ab0d1-head and master-a926a44e-head
Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630): qemu/KVM 3 nodes

Additional context

@lanfon72   I don't think it's a mistake because what you're typing is #cloud-config,   We should say that the old version is the one that is wrong, because when the user types # cloud-config, but I change it to #cloud-config, it doesn't make sense.
cc @guangbochen

Yeah I think it was a mistake. (cloud-init docs asks user to use #cloud-config, but in our test cases, it be written as # cloud-config and worked.)
I think in the case, if we don't want to patch it anymore, at least we should notify users in somewhere that it should be #cloud-config not # cloud-config. (and I will update our test cases)

Just need to make sure the doc, e2e tests, and v1.0.3 release notes will cover this change should be sufficient enough, thanks.

Fixed via merged PR https://github.com/harvester/docs/pull/176
Deployed and verified as fixed.