Add oci_push label to support running push script on host

Could you please provide the rationale behind this change? I thought we fixed oci_push for good.
I'd like to get @EdSchouten thoughts on this.

I don't think a change along these lines is necessary. Are you by any chance trying to do something like this?
bazel run --platforms=//platform/of/the/resulting/image //the/push/target

If so, that's invalid. --platforms should in this case correspond to the platform on which the push target is being run. Namely, the host platform. If you want to push an image intended for another platform, please use platform_transition_filegroup():
https://github.com/buildbarn/bb-storage/blob/master/tools/container.bzl#L37-L41

My workflow builds the image for Linux (target) and pushes the image to a docker repo, all the while running on my macOS laptop (host). Before the latest release, things worked fine. Afterwards, the push script was built for target instead of host. So I patched it back to transition to host platform in my repo, and thought others could benefit from the flexibility.
I'm using toolchains llvm as extra toolchains, and setting platforms to Linux. If possible I would not want to build a multi-arch image and keep the existing workflow.
Would this make a case for the flag addition? Or it would fall under your proposed file transition group?

If possible I would not want to build a multi-arch image and keep the existing workflow.

There's no need to build a multi-arch image. The code I linked is just an example of how to do such a transition. Whether you end up using oci_image_index() is completely your choice.
Not that I'm in any way an owner of rules_oci, I would vote against an addition like this. Sure, Bazel's overall handling of platforms could sure use a bit more love. But as it stands, this change ends up using platforms incorrectly.
If you do a bazel build //oci/push/target, you are not building a container image. You are building a tool that is capable of pushing a container image. Even though you typically want to run this tool on the same system as where you run Bazel, this is by no means a requirement.
If all you're looking for is a way where you can have a single push target, but still want to have the freedom to specify the platform of the image on the command line, you'd better use a string_flag() or something.

Let me show the relevant code involved. I believe I am using platforms flag correctly, setting it as the cross-compilation target platform. Upon re-examining the error, it may be an issue with the binary compatibility of yq.
With the patch, the push succeeds, and the web app runs fine on the linux-amd64 server, so I know the image is correctly targeting linux-amd64.
If I comment out the single_version_override applying the patch, this is the new error in 1.8.0:
~/Projects/l3> bazel run //prod/versor:push --config=prod; fly deploy --config=prod/versor/fly.toml                                                                                2024-07-20 12:06:38 PM
INFO: Invocation ID: fe78459f-d3e8-4561-b2f6-36cc760a52f3
WARNING: Build options --compilation_mode, --platforms, and --strip have changed, discarding analysis cache (this can be expensive, see https://bazel.build/advanced/performance/iteration-speed).
INFO: Analyzed target //prod/versor:push (632 packages loaded, 43258 targets configured).
INFO: Found 1 target...
Target //prod/versor:push up-to-date:
  bazel-bin/prod/versor/push_push.sh
INFO: Elapsed time: 37.914s, Critical Path: 32.05s
INFO: 838 processes: 23 disk cache hit, 737 internal, 76 darwin-sandbox, 2 local.
INFO: Build completed successfully, 838 total actions
INFO: Running command line: bazel-bin/prod/versor/push_push.sh
/private/var/tmp/_bazel_lev1ty/de89f262b469edfa61610312bc506b3e/execroot/_main/bazel-out/darwin_arm64-opt/bin/prod/versor/push_push.sh: line 47: ../aspect_bazel_lib~~toolchains~yq_linux_amd64/yq: cannot execute binary file

Code
# MODULE.bazel
bazel_dep(name = "rules_oci", version = "1.8.0")
single_version_override(module_name = "rules_oci", version = "1.8.0", patches = ["//:patches/rules_oci_1_8_0.patch"])

# patches/rules_oci_1_8_0.patch
--- oci/private/push.bzl
+++ oci/private/push.bzl
@@ -114,1 +114,1 @@
-    inputs = ["//command_line_option:platforms"],
+    inputs = ["//command_line_option:host_platform"],

--- oci/private/push.bzl
+++ oci/private/push.bzl
@@ -108,1 +108,1 @@
-            for platform in settings["//command_line_option:platforms"]
+            for platform in [settings["//command_line_option:host_platform"]]

# .bazelrc
build --extra_toolchains=@llvm_toolchain_with_sysroot//:cc-toolchain-aarch64-linux
build --extra_toolchains=@llvm_toolchain_with_sysroot//:cc-toolchain-x86_64-linux

build:release --compilation_mode=opt
build:release --strip=always

build:staging --config=release
build:staging --platforms=@toolchains_llvm//platforms:linux-aarch64

build:prod --config=release
build:prod --platforms=@toolchains_llvm//platforms:linux-x86_64

# prod/versor/BUILD.bazel
load("@rules_oci//oci:defs.bzl", "oci_image", "oci_push", "oci_tarball")
load("@rules_pkg//pkg:tar.bzl", "pkg_tar")

pkg_tar(
    name = "tar_versor",
    srcs = ["//go/cmd/versor"],
)

pkg_tar(
    name = "tar_env",
    srcs = [".env"],
)

oci_image(
    name = "image",
    base = "@distroless_static",
    entrypoint = ["/versor"],
    env = {"ENV": "/.env"},
    tars = [
        ":tar_versor",
        ":tar_env",
    ],
)

oci_tarball(
    name = "tarball",
    image = ":image",
    repo_tags = ["versor:latest"],
)

oci_push(
    name = "push",
    image = ":image",
    remote_tags = ["latest"],
    repository = "[REDACTED]",
)

Your bazelrc is missing something along the lines of:
run --platforms=@bazel_tools//tools:host_platform

Once you add that, it will end up using a copy of yq and crane for the correct platform.
Then the remaining issue is that your container image will be built for the host platform. This can be addressed by adding that platform_transition_filegroup().

Thank you I'll try that and post the code here for posterity.
Typically platform flag expresses the cross-compilation target, so setting it to host platform does seem off somewhat. If the run action defaults to host machine, the platform flag can be set to the semantically correct cross-compilation target instead of the pragmatic host platform. Can consider this a sharp edge of bazel

Typically platform flag expresses the cross-compilation target, so setting it to host platform does seem off somewhat.

If you think about it, it’s the only valid choice. You’re using Bazel to build something, so that you can run it on your local system. That in this case it happens to be a tool that pushes a container image for Linux is irrelevant. The Linux container image is just an asset that is used by the tool that does the pushing.

I see, in that perspective it makes more sense. The issue here is I want part of the dependency tree to target Linux and the rest to target local. The platform flag uniformly sets the platform for the whole dep tree, so in cases like this we would have to use transitions

Using a transition is unavoidable here. If you look at the runfiles directory for your push target, you can see it contains assets for multiple platforms. So some part of the build graph needs to make that switch.

Works perfectly with platform_transition_filegroup. Will close this PR now. The code example is below.
The command from before works without patching with single_version_override.
Code
# .bazelrc
build --extra_toolchains=@llvm_toolchain_with_sysroot//:cc-toolchain-aarch64-linux
build --extra_toolchains=@llvm_toolchain_with_sysroot//:cc-toolchain-x86_64-linux

build:prod --compilation_mode=opt
build:prod --strip=always

# prod/versor/BUILD.bazel
load("@aspect_bazel_lib//lib:transitions.bzl", "platform_transition_filegroup")
load("@rules_oci//oci:defs.bzl", "oci_image", "oci_push", "oci_tarball")
load("@rules_pkg//pkg:tar.bzl", "pkg_tar")

pkg_tar(
    name = "tar_versor",
    srcs = ["//go/cmd/versor"],
)

pkg_tar(
    name = "tar_env",
    srcs = [".env"],
)

oci_image(
    name = "image",
    base = "@distroless_static",
    entrypoint = ["/versor"],
    env = {"ENV": "/.env"},
    tars = [
        ":tar_versor",
        ":tar_env",
    ],
)

platform_transition_filegroup(
    name = "image_preprod",
    srcs = [":image"],
    target_platform = "@toolchains_llvm//platforms:linux-aarch64",
)

platform_transition_filegroup(
    name = "image_prod",
    srcs = [":image"],
    target_platform = "@toolchains_llvm//platforms:linux-x86_64",
)

oci_tarball(
    name = "tarball",
    image = ":image_preprod",
    repo_tags = ["versor:latest"],
)

oci_push(
    name = "push",
    image = ":image_prod",
    remote_tags = ["latest"],
    repository = "[REDACTED]",
)


types,consensus: Make contract finalization unilateral

Previously, a V2FileContractFinalization was a final revision of a contract, mutually agreed upon by the renter and host. However, there are scenarios in which a renter may want to unilaterally end a contract, such as when they want to leave the network entirely. This PR changes V2FileContractFinalization to be a signature: specifically, the renter's signature of the current revision, with its revision number set to MaxRevisionNumber. This addresses multiple concerns:

Clearly the renter must not be allowed to finalize a contract revision that lacks a valid host signature. The approach in this PR forces the renter to finalize the existing state of the contract, so the host is not at risk.
The host must not be allowed to finalize contracts at all, since they would be incentivized to do so as soon as they detect data loss (to avoid forfeiting their collateral). Requiring the signature to use MaxRevisionNumber prevents the host from replaying a previous renter signature.
Mutual finalization remains possible: the renter and host simply agree to submit a revision, and then the renter submits the finalization. (Currently, it's possible to do both within the same block, though not the same transaction.)

Note that finalization was originally added as a way to implement "renew and clear," back before we had an explicit V2FileContractRenewal type.


postfix: Support for LDAP / recipient verification

If using postfix as a mail gateway to a backend mail server (e.g. Exchange), it would be useful to have a recipient verification using ldap or ActiveDirectory. postfix already supports this using postfix-ldap, but the opnsense plugin currently doesn't support this extension. If this extension is available, the configuration may look like this.
main.cf:
relay_recipient_maps = ldap:/etc/postfix/ldap_relay_recipient_maps.cf
ldap_relay_recipient_maps.cf (example):
server_host = ad-01.example.com
ad-02.example.com
search_base = dc=example, dc=com
version = 3
bind_dn = CN=postfix,CN=Users,DC=example,DC=com
bind_pw = password
query_filter = (proxyAddresses=smtp:%s)
result_attribute = mail

@fichtner this would require postfix-ldap pkg, for me it's ok. Leave the decision to you :)

May I propose a more universal solution?
In my current OPNsense 20.7.1 setup, Postfix is missing an extremely vital instruction in its main.cf:
smtpd_recipient_restrictions  ->  reject_unverified_recipient
Since OPNsense is only a Postfix gateway and not the final destination, it should never, ever accept mails, which are afterwards non deliverable to it's final destination.
If the final destination is a Postfix mail server, nothing else needs to be configured.
If the final destination is Exchange 2013 or higher, you will need to:
Install AntiSpamAgents (& $env:ExchangeInstallPath\Scripts\Install-AntiSpamAgents.ps1)
Enable-TransportAgent "Recipient Filter Agent"
Get-RecipientFilterConfig | FL Enabled,RecipientValidationEnabled (Should show enabled)
Above example will use the final destination mail server also as the verification server, which should be usable for most single mail server installations.

@jassonmc: I am not really getting your point. My idea is that if the opnsense (postfix gateway) checks the recipient against the active directory or some other ldap server, the opnsense could already reject the messages without having unnecessary load on the email server behind (e.g. exchange). In my opinion it would reduce the load on the "real" mail server in case of a DDoS attack.

@jd77777777 A DDoS would then flood your AD cause of massive LDAP queries :)

@jd77777777
Exactly what I thought, when @mimugmail mentioned it.
I'd rather have my mailserver DDoSed for some time then my critical authentication infrastructure.


(WIP) fsoc solution push --subscribe

Description
Add a --subscribe flag to fsoc solution push that subscribes the tenant to the solution after it is pushed, but before it's status is checked.
Note that this will require some changes in the platform to work properly. As is, solution status in not correctly reflects after a subscription, so doing fsoc solution push --subscribe --wait will not return success.
Type of Change

[x] New Feature

Superseded by PR #117


Build on Pine Phone (ARM) fails with error: failed to select a version for the requirement aes = "^0.2"

When building on Pine Phone, I get:
[manjaro@manjaro-arm cli]$ cargo build --release
    Updating crates.io index
    Updating git repository `https://github.com/zcash/librustzcash`
error: failed to select a version for the requirement `aes = "^0.2"`
candidate versions found which didn't match: 0.8.0, 0.7.5, 0.7.4, ...
location searched: crates.io index
required by package `zcash_primitives v0.0.0 (https://github.com/zcash/librustzcash?rev=5a48d179b8434a0318e7e19dda506e245a904092#5a48d179)`
    ... which satisfies git dependency `zcash_primitives` of package `piratepaperlib v0.1.0 (/home/manjaro/piratepaperwallet/lib)`
    ... which satisfies path dependency `piratepaperlib` of package `piratepaperwallet v0.1.0 (/home/manjaro/piratepaperwallet/cli)`

How to solve this error?

Try to use this version https://github.com/PirateNetwork/piratepaperwallet/releases/tag/v0.5.0

Nice, thanks, that works! Totally forgot to check for aarch64 binaries... doh.


Add Git LFS Pull Step

We need to determine if this is needed, I believe not, because we are assuming that Git LFS is setup ahead of this operation and the initial clone step should handle this for us (if LFS fetch isn't disabled).
That being said, this might be worthwhile to try for debugging.
I would not merge this until we validate it's necessary.

Yeah this isn't going to pass because the android image doesn't have git lfs, going to close this out and folks can resurrect this if needed (but I don't think it's needed).


Fix broken tag link when tag contains space

When tag contains space, e.g. foo bar:

Hugo generates dash separated tag dir: public/tags/foo-bar/
but this theme generates a tag link with space: <base_url>/tags/foo%20bar/ link

This patch fixes the link so the it is: <base_url>/tags/foo-bar/
Note that when tag has any uppercase, Hugo will still generate tag dir with lowercase, which urlize also handles.

Hello @cliffano,
thanks you for fixing this issue. It's easy to overlook such corner-cases if you don't think about them.


Thief hotfix

About the PR

fix some sloth review tasks
Small rebalancing of the contents of the kits
Disabling structure theft. So far, this type of task is not feasible. We need some new items for this in the form of separate PR
Changelog
:cl:

tweak: Small rebalancing of the contents of the thief starters kits.
tweak: The thief will temporarily not steal structures for the time being, as this task seems too difficult.

structure theft is extremely funny so i'd like to see it return in the future, but i get disabling it for now

Yes, there are no normal ways to fulfill these goals yet. We need some way to carry them undetected, or maybe let the thief fly away on evac pods and consider the goal accomplished.
Ideas:
An item that grants invisibility to another object or character (invisibility cloak). Can be thrown over a structure or worn on its own
Bluespace Glove. Works as a ripley.

i think one potential solution would be the option to bring the structure to a predefined drop area, where it will count as 'stolen' and you simply need to hide it there. or being able to attach something to it that will mark it as 'stolen' but can be easily removed

some "Fulton" thematic will be good

fultons that start linked to a thieves den :trollface:

I'll also add a guidebook to this PR.

nah, separate pr.
this seems more time consuming than I thought


Fixes #1700: refactor the AMQP link lifecycle

This change removes some of the old link attach routing logic and attempts to clean up the link API.
The logic that used to track the exchange of Attach/Detach performatives has been simplified. The various counters and booleans maintained by the qdr_link_t structure for tracking this exchange has been reduced to a mask/flag implementation similar to Protons implementation of endpoint state.
This patch refactors the link detach adaptor API to be more like the existing AMQP connection API: there is now an explict API call to release the link instance at the end of its lifecycle.
The adaptor API is modified by separating the AMQP detach handling from the release of the link instance. The old qdr_link_detach() adaptor function has been refactored into two functions: qdr_link_detach_received() and qdr_link_close().
The qdr_link_detach_received() call is made by the AMQP adaptor when a Detach Peformative has been received by the peer. It is only used by the AMQP adaptor.
The new qdr_link_closed() API call is made by all adaptors when the link instance is destroyed. This is similar to the existing qdr_connection_closed() call but for links. It is used by all adaptors to indicate to the core that the link is no longer in use and can be cleaned up. In the case of the AMQP adaptor this call will be made after the link detach handshake has completed.
Test coverage by the test-sender AMQP client has been increased by adding a clean connection close function.

Can the qdr_link_cleanup_CT() function be called qdr_link_free_CT()
IMO, it will make its intent very clear.


Add Dokku instructions

Hey, this is good info.  How do you upload settings.json?
I'm trying this out: https://github.com/JarnoLeConte/dokku-meteor

@MichaelJCole  just added it to git.

Hey vittore, I didn't see anything about meteor settings.  Was there
another part to the PR?  I was fussing around with Docker and Dokku before
going back to Mupx.  For performance reasons, it's easier to do the build
on my machine.
Before going back, I didn't get all the way on the settings file.  I
learned Meteor loads settings from METEOR_SETTINGS environment variable or
from the file if specified, but I didn't finish.
Anyways, thanks for the buildpack!
On Sat, May 28, 2016 at 12:09 PM, vittore<EMAIL_ADDRESS>wrote:

@MichaelJCole https://github.com/MichaelJCole just added it to git.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/AdmitHub/meteor-buildpack-horse/pull/104#issuecomment-222319045,
or mute the thread
https://github.com/notifications/unsubscribe/ABb2Fr-0qBIuPLd9zLwNF_DfCwzrFrp4ks5qGHbagaJpZM4IkKCC
.

--
Michael Cole
Founder and Engineer
https://bigSmall.io

Thanks for these instructions. Rather than clutter up the README further, I've added a wiki page for usage with Dokku based on your list here, and referenced it from the README.  Would love any further edits and improvements to these instructions there, including discussion of the role of dokku-meteor etc.

Nice choice!
On Mon, May 30, 2016 at 12:34 PM, Charlie DeTar<EMAIL_ADDRESS>wrote:

Thanks for these instructions. Rather than clutter up the README further,
I've added a wiki page
https://github.com/AdmitHub/meteor-buildpack-horse/wiki/Dokku for usage
with Dokku based on your list here, and referenced it from the README.
Would love any further edits and improvements to these instructions there,
including discussion of the role of dokku-meteor etc.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/AdmitHub/meteor-buildpack-horse/pull/104#issuecomment-222532093,
or mute the thread
https://github.com/notifications/unsubscribe/ABb2FvsUGu5ParjaVPN3lsbKKR6zYVjRks5qGx-mgaJpZM4IkKCC
.

--
Michael Cole
Founder and Engineer
https://bigSmall.io

Hey guys, I updated the wiki with what I learned.  Feel free to edit,
wiki-style :-)
On Mon, May 30, 2016 at 12:40 PM, Michael Cole<EMAIL_ADDRESS>wrote:

Nice choice!
On Mon, May 30, 2016 at 12:34 PM, Charlie DeTar<EMAIL_ADDRESS>wrote:

Thanks for these instructions. Rather than clutter up the README further,
I've added a wiki page
https://github.com/AdmitHub/meteor-buildpack-horse/wiki/Dokku for
usage with Dokku based on your list here, and referenced it from the
README. Would love any further edits and improvements to these instructions
there, including discussion of the role of dokku-meteor etc.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/AdmitHub/meteor-buildpack-horse/pull/104#issuecomment-222532093,
or mute the thread
https://github.com/notifications/unsubscribe/ABb2FvsUGu5ParjaVPN3lsbKKR6zYVjRks5qGx-mgaJpZM4IkKCC
.

--
Michael Cole
Founder and Engineer
https://bigSmall.io

--
Michael Cole
Founder and Engineer
https://bigSmall.io

Hi guys,
I updated wiki page with instructions for METEOR_SETTINGS. Basically same thing stands as with ROOT_URL. You have to use dokku config:set


Not working with webpack dev-server

I'm writing Vue projects, and I use webpack to hot-build and serve pages on localhost when developing.
However it seems javascript-errors-notifier doesn't detect any error within my pages.

I guess it has something to do with webpack, since once I build and deploy the project into production, it just works.
I made a demo page to reproduce this, where you can see errors in chrome console, but the extension doesn't catch anything: (the app.js file is produced by webpack so is a bit large and hard to read)
https://niaodan2b.github.io/test-error/test.html

+1. If this can be worked with webpack-dev-server this tool will be a great addition to my project!

+1.
I'm wondering if there's something fundamentally different about the ways webpack errors are generated.
I will dig into the code but happy to hear if anyone who knows more can comment.

+1
Not working. If I compile static assets works OK.

It works with webpack. It is because it does not handle this kind of errors


Summer 2021 update - update existing databases & add GRCh38

Scope

Make snakemake run through in summer 2021, IOW: fix broken URLs
Update existing databases where available
Add support for GRCh38, use gnomAD exomes lift-over for now.
Add gnomAD chrMT variants in the same way as helixmtdb was added.

Non-Scope

No GRCh38 for ExAC or thousand genomes.
No extra databases beyond the existing ones.

To be discussed

What if a database is not available for GRCh38 any more?

Proposal from @holtgrewe: document here and skip. Mostly this will be gnomAD-SV which is also hard to lift over.

TODOs

[x] GRCh37, acmg, v2.0, exists
[ ] GRCh37, clinvar, 20200929, exists

https://github.com/bihealth/clinvar-tsv TODO: versionize / add date

[x] GRCh37, dbSNP, b155, exists
[x] GRCh37, dbVar, latest, exists

which version?

[x] GRCh37, DGV, 2020, exists
[x] GRCh37, ensembl_genes, r104, exists
[x] GRCh37, ensembl_regulatory, latest, exists
[x] GRCh37, ensembltogenesymbol, latest, exists

no change

[x] GRCh37, ensembltorefseq, latest, exists

no change

[x] GRCh37, ExAC_constraints, r0.3.1, exists

no change
no GRCh38

[x] GRCh37, ExAC, r1, exists

no change
no GRCh38

[ ] GRCh37, extra-annos, 20200704, exists

TODO: link dead

[ ] GRCh37, gnomAD_constraints, v2.1.1, exists

not for GRCh38 / gnomAD r3

[x] GRCh37, gnomAD_exomes, r2.1.1, exists
[x] GRCh37, gnomAD_genomes, r2.1.1, exists
[x] GRCh37, gnomAD_SV, v2.1, exists

not for GRCh38

[x] GRCh37, HelixMTdb, 20200327 exists
[x] GRCh37, hgmd_public, ensembl_r104, exists
[x] GRCh37, hgnc, latest, exists

any update?
TODO: also from genes
same for GRCh38 probably

[ ] GRCh37, hpo, latest, exists

broken link

[x] GRCh37, kegg, april2011, exists

no update

[x] GRCh37, knowngeneaa, latest, exists

no update

[x] GRCh37, mgi, latest, exists

no update
same for GRCh38

[x] GRCh37, mim2gene, latest, exists

no update

[x] GRCh37, MITOMAP, 20200116, exists

no update
same for GRCh38

[x] GRCh37, mtDB, latest, exists

no update
same for GRCh38

[x] GRCh37, ncbi_gene, latest, exists

no update
same for GRCh38

[x] GRCh37, refseq_genes, r105, exists
[x] GRCh37, refseqtoensembl, latest, exists
[x] GRCh37, refseqtogenesymbol, latest, exists
[ ] GRCh37, tads_hesc, dixon2012, exists

skipped

[ ] GRCh37, tads_imr90, dixon2012, exists

skipped

[x] GRCh37, thousand_genomes, phase3, exists

no change
no GRCh38

[x] GRCh37, vista, latest, exists

no change
no GRCh38

[x] GRCh38, clinvar, 20200929, exists
[x] GRCh38, dbVar, latest, exists

which version?

[x] GRCh38, DGV, 2020, exists
[x] GRCh38, gnomAD_exomes, r2.1.1, NEW (LIFTOVER)
[x] GRCh38, gnomAD_genomes, r3, NEW
[x] GRCh38, dbSNP, b155, exists

which version?

[x] GRCh38, ensembl_genes, r104, exists
[x] GRCh38, ensembl_regulatory, latest, exists
[ ] GRCh38, extra-annos, 20200704

TODO: link dead

[x] GRCh38, HelixMTdb, 20200327 exists
[x] GRCh38, hgmd_public, ensembl_r104, new
[x] GRCh38, refseq_genes, r39, exists

GRCh37, gnomAD_constraints, v2.1.1, exists: if only the pLI, o/e and so on are used in varfish and not the chromosomal positions of the genes, it should be no problem to use the GRCh37 version. Otherweise we can try a liftover.

genes.snake/hgnc.snake -> for the latest GRCh38 release (GRCh38.p13) only gff files insteadt of the gff3 files were available. However the extracted columns (1,4,5,15 or GeneID, HGNC) have the same content.

[ ] create a "input file" containing all download links  (please finde attached a file with all links used in the snake files)
pfade.txt


Version resolution inconsistency

Hi there, seeing some inconsistency on version resolution with the patch numbers.
Python seems to have patch version from 3.9.1 --> 3.9.16 and even though 3.9.1 is specified, it ends up resolving and bumping that up to the latest patch 3.9.16.
cat sample/.tool-versions
python 3.9.1

cd sample
[WARN] [python] version 3.9.16 not installed

rtx install<EMAIL_ADDRESS>⢄ Installing runtime<EMAIL_ADDRESS>

oof you're right this is a problem. Perhaps a short-term solution would be for me to not resolve if there is an exact matching version.

awesome, thanks for the quick fix


Generation of the Firebase Android resource file google-services.xml from Assets/Firebase/google-services.json failed.

Generation of the Firebase Android resource file google-services.xml from Assets/Firebase/google-services.json failed.
I couldn't reply in proper issue so i create a new.
I have been executed generate_xml_from_google_services_json.exe -i "Assets/Firebase/google-services.json" -l in a adminstrator cmdline and get the follow error: missing api-ms-win-core-path-l1-1-0.dll
Already got arround 10000 virus and suckingwares trying to fix this error, please compile generate_xml_from_google_services_json.exe independent unique file if you want someone use this SDK,
Thanks

Also now my Unity Editor don't open anymore, even with a new project, should I Format the PC ? thankyou for your great pack

Hi @isoueu
Sorry for the late reply.
May I get some more information about your situation?

Which Unity SDK version are you using?
What's the Windows version you are using?
Does this post works to fix the missing api-ms-win-core-path-l1-1-0.dll?
@chriswalz since you upvoted this, could you describe your situation as well?

Thank you,
Shawn