Pack and release extension tarball to GitHub releases and/or npm registry

Lens will allows users to install extensions from tarballs or by specifying the URL. In order to support this install mode we have to pack and release the Starboard extension.

Ideally we should perform each release on GitHub Actions runner whenever we create an annotated Git tag.

https://docs.github.com/en/free-pro-team@latest/actions/guides/publishing-nodejs-packages

I wonder if Lens extension is going to support installing directly from node registries one day. That would be quite cool.

I wonder if Lens extension is going to support installing directly from node registries one day. That would be quite cool.

Not sure if that would be node registry, but the idea is to have some kind of extensions catalog so end users could search and install what they want.

Done https://github.com/aquasecurity/starboard-lens-extension/releases/tag/v0.0.1-alpha.1


Handle Google IAP JWT tokens

Google IAP passes its JWT token through the x-goog-iap-jwt-assertion header, which doesn't follow the Authorization header format. This PR adds an option to disable treating the inspected header as being in that format, leaving the behaviour as-is by default.

See #19 for the related issue.

Also added the missing bits to verify_jwt_using_secret which are required for Google IAP JWT to function (audience verification).

Described the Google IAP JWT configuration for JupyterHub here: https://stackoverflow.com/questions/54636656/how-do-i-use-google-iap-for-authenticating-to-jupyterhub/54636657

Hey, thanks for the contribution. IAP is something we're about to get into so this is really helpful.
This looks fine to me.
I'm assuming you've integrated this with IAP as you went?

Yeah, I have this functioning on a production GKE cluster, to great effect. Enabling IAP on zero-to-jupyterhub-k8s is as simple as adding:
proxy:
    service:
      annotations:
        beta.cloud.google.com/backend-config: '{"default": "your-iap-backend"}'


Missing typescript definition for tool_calls in ChatCompletionResponseChoice

Currently, only the streaming results have definitions for function calling. However regular chat completion does return tool_calls, as  suggested in the available javascript example in this repo
ChatCompletionResponseChoice.message is missing the field tool_calls?: ToolCall[]
One strange thing however is that the example suggest that the field is toolCalls in camel case, while the result returned by await client.chat(...) seems to include tool_calls instead.

Thanks for raising an issue! It has been fixed by #72.


Schedule menu in ticket shop should consider schedule state from talk

This PR related to issue #353
Implement:

API to handle schedule state trigged by Talk system.
Remove schedule/session/speaker link set in event settings - auto set when is_show_schedule is True (triggered by Talk system.)

Summary by Sourcery
Implement an API to manage schedule state changes from the Talk system and automate the configuration of schedule-related links based on the schedule's visibility status.
New Features:

Introduce an API endpoint to handle schedule state changes triggered by the Talk system, allowing the schedule menu to reflect the current state.

Enhancements:

Automatically set schedule, session, and speaker links when 'is_show_schedule' is true, removing the need for manual configuration in event settings.

Please resolve conflicts.

Please resolve conflicts.

Hi @mariobehling,
conflict is resolved.

Merging for live testing.


Assert configuration is a subset of a template configuration

It is sometimes useful to make sure that a certain config is a subset of a given template configuration,
e.g. when passing arguments through the command line.
That way you make sure no keys are "getting lost" and the application is misconfigured.
Assuming a template conf:
foo:
  bar: True
  bar2: True

I would want something like this:
cfg = OmegaConf.create({"foo": {"bar": 100}})
cfg.assert_subset(template)
cfg = OmegaConf.create({"foo": {"bar1": 100, "bar2": 101}})
cfg.assert_subset(template). # Fails on assertion / KeyError
cfg = OmegaConf.create({"foo2": {"bar": 100, "bar2": 101}})
cfg.assert_subset(template). # Fails on assertion / KeyError

Another option would be:
OmegaConf.assert_subset(cfg, template)

I've implemented a simple recursion that takes care of DictConfig, and if you see this feature as needed I'll be happy to discuss and then PR.

Hi Assaf,
The next version of OmegaConf will support this in a better way that what you probably implemented.
Pre release nodes:
https://github.com/omry/omegaconf/releases/tag/2.0.0rc6
Intro in primary doc:
https://omegaconf.readthedocs.io/en/latest/usage.html#from-structured-config
Full docs:
https://omegaconf.readthedocs.io/en/latest/structured_config.
There is a release candidate if you want to try (currently omegaconf-2.0.0-rc16).
This version is not compatible with the stable Hydra yet (I am guessing you are using Hydra as well).
There is a version in master that introduces this support which you can try.
Check the tutorial for it here:
https://hydra.cc/docs/next/tutorials/structured_config/basic
Closing for now, but happy to continue discussing here or in the chat.


[SNI] Error on create the SNI by both PUT and POST requests

Summary
I had two problems specifically with the /SNIS/ endpoint:

error 500 for POST request when the UUID format is invalid
"created_at is required" when I try to create a new certificate using the PUT request

When I try to create a new SNI certificate by a post request, I got the following message:
$http POST :8001/snis/ name="endpoint.com" ssl_certificate_id="some-invalid-uuid-format"

HTTP/1.1 500 Internal Server Error
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Type: application/json; charset=utf-8
Date: Mon, 22 Jan 2018 11:33:02 GMT
Server: kong/0.12.1
Transfer-Encoding: chunked

{
    "message": "An unexpected error occurred"
}

If I try to create the SNI by a PUT request, it is always requiring the created_at field.
$http PUT :8001/snis/ name="endpoint.com" ssl_certificate_id="4ee6de3e-fd1f-4ce1-9fed-86424378cc93"

HTTP/1.1 400 Bad Request
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Type: application/json; charset=utf-8
Date: Mon, 22 Jan 2018 11:44:10 GMT
Server: kong/0.12.1
Transfer-Encoding: chunked

{
    "created_at": "created_at is required"
}

Steps To Reproduce

http POST :8001/snis/ name="endpoint.com" ssl_certificate_id="invalid-uuid-format" (The SSL Certification ID doesn't exist and the UUID format is invalid)
PUT :8001/snis/ name="endpoint.com" ssl_certificate_id="98bc6baa-0490-486f-95ff-372a4a512127b" (I tried with a valid and invalid ssl_certificate_id)

Additional Details & Logs
I am running the kong using Docker 17.12.0-ce.
From the logs on docker side, I got this message in the POST request:
kong-database_1   | ERROR:  invalid input syntax for uuid: "some-invalid-uuid" at character 84
kong-database_1   | STATEMENT:  INSERT INTO ssl_servers_names("name", "ssl_certificate_id") VALUES('endpoint.com', 'some-invalid-uuid') RETURNING *

There is nothing reported in the error.log file for both cases.
Kong version: 0.11.2 and 0.12.1
I've checked #2800 and #2989, but couldn't find the answer for this.

This issue is most likely gone from Kong 0.14, which moved the Certificate and SNI entities to the new DAO and the new auto-generated Admin API endpoints. Closing it and considering it resolved in 0.14. Feel free to reopen if a similar issue arises in a more recent version, of course.


Support of ARM64 does not work for UWP apps in a GitHub Actions

Describe the bug
The native .NET compiler tool nutc_driver.exe exits with a strange error that does not say the cause:
C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.net.native.compiler\2.2.8-rel-28605-00\tools\Microsoft.NetNative.targets(801,5): error : ILT0005: 'C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\runtime.win10-arm64.microsoft.net.native.compiler\2.2.8-rel-28605-00\tools\ARM64\ilc\Tools64\nutc_driver.exe @"D:\a\MY_PROJECT\obj\ARM64\Release\ilc\intermediate\MDIL\MyApp.App.rsp"' returned exit code 1
Area for Triage:

Question, Bug, or Feature?:
Bug
Virtual environments affected

[ ] macOS 10.15
[ ] Ubuntu 16.04 LTS
[ ] Ubuntu 18.04 LTS
[ ] Ubuntu 20.04 LTS
[ ] Windows Server 2016 R2
[X] Windows Server 2019

Expected behavior
No error especially from an internal tool. I suspect it is an out of memory.
Actual behavior
Our repo is private. However, the build step is quite simple:

name: Build the sideload solution
run: msbuild $env:Solution_Path /p:Platform=ARM64 /p:AppxBundle=$env:AppxBundle /p:AppxBundlePlatforms="ARM64" /p:AppxPackageDir=C:\DeployOutput /p:PackageCertificateKeyFile=$env:SigningCertificate /restore
env:
AppxBundle: Always
BuildMode: StoreUpload
Configuration: Release

Hello @ArchieCoder,
Thank you for the issue reported.
Did you try to build you code locally? Is it successful?
Do you have a chance to provide us sample repo with minimal steps to reproduce the issue?

@Darleev Thanks for the fast follow-up.
On a regular Dev Command Line prompt, it works locally. It takes so long, but it works. I can see the memory going up to 6.1 GB for the .net tooling.

Would there be a way that you could put some sort of diagnostics? I would not be surprised that it would actually work on a blank solution. It takes so much time to create a full repro.

The ARM build confirmed to success https://github.com/akv-platform/ConsoleApplication1ARM/runs/810854812?check_suite_focus=true so we need a specific project to investigate the problem.
@ArchieCoder
Is not it possible to imitate the problem with the sample project?
Do you use msbuild or visual studio workflow?
Are you aware about the ways to increase the verbosity of the build?
Have you investigated the content of logs directory in case if you use CMake ?

@Darleev @dsame I have good news! I have a repro. Last night, I created the same solution without ANY cs/xaml files, but just the minimum like icon assets, App.xaml.cs and empty Main.xaml.
1- I started the process to build the ARM64 package only -> it works. I was sad.
2- Before giving up, I said let's add the x64 package also -> The solution didn't build with the same error that I got in my real solution.
Repo: https://github.com/ArchieCoder/GTA
Compilation
Workflow (line 54): https://github.com/ArchieCoder/GTA/blob/master/.github/workflows/storebuilder.yml
In order to trigger the workflow, create and push a tag with the form <IP_ADDRESS>
Thank you and good luck

@ArchieCoder the build fails with
 Get tag0s
    DeployPath: DeployOutput
Run dawidd6/action-get-tag@v1
  env:
    SigningCertificate: Sherpany.App_TemporaryKey.pfx
    Solution_Path: EG.Sherpany.Boardroom\Sherpany.sln
    UWP_Project_Path: EG.Sherpany.Boardroom\EG.Sherpany.Boardroom.W10\Sherpany.App.csproj
    UWP_Project_Directory: EG.Sherpany.Boardroom\EG.Sherpany.Boardroom.W10
    DeployPath: DeployOutput
##[error]Not a tag ref (refs/heads/master)

https://github.com/dsame/GTA/runs/830788995?check_suite_focus=true
I tried to remove this task but the build failed with
"D:\a\GTA\GTA\EG.Sherpany.Boardroom\Sherpany.sln" (default target) (1:2) ->
"D:\a\GTA\GTA\EG.Sherpany.Boardroom\EG.Sherpany.Boardroom.W10\Sherpany.App.csproj" (default target) (4:6) ->
(_ValidateAppxManifest target) ->
  D:\a\GTA\GTA\EG.Sherpany.Boardroom\EG.Sherpany.Boardroom.W10\bin\ARM64\Release\AppxManifest.xml : error APPX0501: Validation error. error C00CE169: App manifest validation error: The app manifest must be valid as per schema: Line 10, Column 74, Reason: '' violates minLength constraint of '1'. The attribute 'Version' with value '' failed to parse.

https://github.com/dsame/GTA/runs/829589327?check_suite_focus=true

@dsame you need to create a tag on the form x.y.z.u like <IP_ADDRESS>

@ArchieCoder
So did it https://github.com/dsame/GTA/tree/<IP_ADDRESS>
Is it absolutely impossible to have a sample build that just works?

The intermediate result: the problem is not alway reproducible:

there's clear OutOfMemory exception
https://github.com/ArchieCoder/GTA/runs/844182819?check_suite_focus=true

2020-07-07T04:49:56.3214127Z   Launching 'C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\runtime.win10-arm64.microsoft.net.native.compiler\2.2.8-rel-28605-00\tools\ARM64\ilc\Tools64\nutc_driver.exe @"D:\a\GTA\GTA\EG.Sherpany.Boardroom\EG.Sherpany.Boardroom.W10\obj\ARM64\Release\ilc\intermediate\MDIL\Sherpany.App.rsp"'
2020-07-07T05:03:49.4410821Z C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.net.native.compiler\2.2.8-rel-28605-00\tools\Microsoft.NetNative.targets(801,5): error : Unhandled Exception: OutOfMemoryException. [D:\a\GTA\GTA\EG.Sherpany.Boardroom\EG.Sherpany.Boardroom.W10\Sherpany.App.csproj]

there's successful build
https://github.com/dsame/GTA/runs/844201838?check_suite_focus=true

there's a build failed with the non-explaing error ILT0005
https://github.com/ArchieCoder/GTA/runs/809936481?check_suite_focus=true

2020-06-26T05:06:51.2200175Z   C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.net.native.compiler\2.2.8-rel-28605-00\tools\Microsoft.NetNative.targets(801,5): error : ILT0005: 'C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\runtime.win10-arm64.microsoft.net.native.compiler\2.2.8-rel-28605-00\tools\ARM64\ilc\Tools64\nutc_driver.exe @"D:\a\GTA\GTA\EG.Sherpany.Boardroom\EG.Sherpany.Boardroom.W10\obj\ARM64\Release\ilc\intermediate\MDIL\Sherpany.App.rsp"' returned exit code 1 [D:\a\GTA\GTA\EG.Sherpany.Boardroom\EG.Sherpany.Boardroom.W10\Sherpany.App.csproj]

@ArchieCoder
Can you please try to add
<Use64BitCompiler>true</Use64BitCompiler>

to the PropertyGroup element of cproj files. Also it can be helpful to add -verbosity:detailed to msbuild. See this comment as a reference: https://github.com/dsame/GTA/commit/e210e664f65e0775416226544e5729a79cd194f3
Unfortunately i can not confirm this solves the issue in your environment although it worked in my builds because the problem is not always reproducible.
The next step if the build continues to fail is to comment out <Assembly Name="*Application*" Dynamic="Required All" /> from EG.Sherpany.Boardroom/App1/Properties/Default.rd.xml and EG.Sherpany.Boardroom/EG.Sherpany.Boardroom.W10/Properties/Default.rd.xml

@dsame Bad news: adding Use64BitCompiler to all projects didn't fix the issue. Good news: removing the Application + Dynamic works. However, I'm extremely stressed about changing project code to fix the issue of an internal compilation tool.
Also, having deal with .NET Native Tool issues since 2013, I find dangerous to alter Default.rd.xml when the app is working.
Do you have more info about this? Thank you for helping.

@dsame I found this thread https://github.com/dotnet/corert/issues/7408. This seems "safe".

@ArchieCoder just a thought - can you please try this action https://github.com/al-cheb/configure-pagefile-action to increase the size of swap (pagefile)?

@dsame I tried with "minimum-size: 32", but still the same error.
I tried to reach out<EMAIL_ADDRESS>mid-June and yesterday about that internal tool and no answer.

@ArchieCoder please try to use this setup
    - name: configure Pagefile
      uses<EMAIL_ADDRESS>      with:
        minimum-size: 8
        maximum-size: 16
        disk-root: "C:"

It does not work :(

@ArchieCoder , Could you please set swap?
- name: configure Pagefile
  uses<EMAIL_ADDRESS>  with:
      minimum-size: 32GB
      maximum-size: 32GB
      disk-root: "C:"

@al-cheb wow, your trick worked! Thank you a lot.
@dsame I will close the issue, but I would recommend that the the native team fixes the issue at the source or the default page file is set to 32 gb by default. Thanks for your help too.


Bug 1257819 - [GSS] (6.1.z) Rules are not populated in dropdown list in Test Scenarios in BRMS 6.1

This PR is for 6.2.x
This and 3 others depend on each other:
https://github.com/droolsjbpm/kie-wb-common/pull/159
https://github.com/droolsjbpm/drools-wb/pull/95
https://github.com/droolsjbpm/jbpm-designer/pull/97
https://github.com/droolsjbpm/jbpm-form-modeler/pull/26

Build failure not related to changes in this PR.
@psiroky, looks like this failed due to there being no tests. Is this something you can configure away?

+1 to merge.

No tests? How is that even...:) configuration fixed, build re-triggered.

6.2.x: 3676bdfc785053f039f6179b50b0e98f175e73ad


Aerogear 7692

relies on @sedroche 's PR to be merged first.
screenshot:

Pull Request Test Coverage Report for Build 67

0 of 0   changed or added relevant lines in 0 files are covered.
3 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-4.9%) to 95.082%

Files with Coverage Reduction
New Missed Lines
%

pkg/web/router.go
3
75.0%

Totals

Change from base Build 60:
-4.9%

Covered Lines:
58

Relevant Lines:
61

💛  - Coveralls


Update experimental pkg_rpm rule to use new mapping/grouping providers

This is a change built on top of #293, which is not yet ready.  The actual work involved with this change is in a91572b.

This change replaces the experimental pkg_rpm rule in pkg/experimental/rpm.bzl
rule with one that is aware of the grouping rule structure.  This will soon become the
primary pkg_rpm rule made available to users.
Changes made to the experimental/ tree include:

Usage of new providers and different paths everywhere

Restructuring of how the %files metadata is built out.  It was restructured
for clarity, and now makes use of the new rpm_filetag mapping attribute
instead of section, which was since removed.

Inputs to pkg_rpm are now specified with the srcs attribute instead of
data, to be consistent between runtime requirements and compile-time sources.

Conflicting content error detection and emission is now streamlined.

Test coverage has improved, including new analysis tests for conflict
detection, and bugs in the RPM python tests.

The old pkg_filegroup code in this same directory will be removed in a
separate change

This particular implementation of pkg_rpm has some known defects and missing features.  These are tracked in #300, and will be fixed opportunistically.

The latest force-push to a91572b is ready for review.

@aiuto Did you mean to approve this one or #293 (pkg_mklinks/pkg_filegroup)?

I meant this one. It seemed self contained in trying update the experimental parts.
The other one merits a closer look, so I didn't have time to do that quickly.

Latest force push syncs this tree with main.  Will be merging shortly.


Minor issue when using Eval target

First of all - thank you for this lib! Much needed in the Haxe community!
Did an attempt to get TrueType parsing going myself some years ago. It basically works, but just for basic tt files.
https://github.com/cambiata/HxTrueType
but your project will be much more robust than that, I'm sure.
When trying opentype.hx, I was running into a minor issue when trying out in --interp mode (Eval target):
c:\_development\opentype\.haxelib\opentype,hx/0,0,4/src/opentype/GlyphSet.hx:47: characters 3-11 : Uncaught exception Invalid operation: null + 1 caused by the uninitialized length property.
Changing the GlyphSeg.hx line 97 to public var length(default, null):Int = 0; solves the problem.
Still not possible to extract path coordinates in opentype.hx v 0.0.4, is it?
Once again, thanks, and keep up the good work!

Thanks for the kind words. I actually came across your library and a couple of others before I started on Opentype.hx, but none of them supported reading kernings from the CPOS table. But then I stumbled upon Opentype.js, that was, if not complete, then 95%ish complete.
And on top of that extensive unit tests, so I could more or less go into autopilot mode and port the test one by one until I had coverage of the needed features :-)
Anyway, I have not tried to run the code in the Interpreter, but since it should be multiplatform it should also work there of course.
Which command did you use to run it?
Regarding extraction of path coordinates, that has not been done yet.
And the sad news is that I don't have any intentions in the near future of working on Opentype.hx unfortunately.
The current state of Opentype.hx only covers what was needed to read advanceWidth & kernings from a font, since that was what we needed in project I was working on in my company.

Hi Mikkel!
Regarding Eval target, I just tried something like the Getting started example, but with the following build.hxml:
-lib opentype.hx
--main Main
--interp

Good to know your plans/non-plans! :-) Yesterday I quickly set up an Opentype.js project running in node and directly from the sourcecode (not from npm), so I can monitor exactly what happens there. Maybe I'll fork your project and try to take it some steps further regarding the paths stuff. Might result in a PR if we're lucky :-).
(Might be that @nanjizal also is interrested in joining in - he has done quite a lot of graphics stuff including adding som parts to my truetype lib.)

You shall be most welcome - contributions are appreciated.
My intention in the first place was to give something back to the Haxe community with this project, so if anyone can benefit just a tiny bit from my work, I'm very happy.


Implement Serialize instance for Text

This includes both Strict.Text and Lazy.Text

[x] Implement Serialize (Strict.Text)
[x] Implement Serialize (Lazy.Text)
[x] Add roundtripping tests
[x] Add benchmarks

Note that we need to implement the instances differently for text < 2 and text > 2. Use CPP macros to control the implementation accordingly.

See #9 and #11


WIFI-2427 Preserve certs/redirector over factory-reset (minor fix)

Signed-off-by: Rick Sommerville<EMAIL_ADDRESS>

Merged 167d282


fix(bsky): unthemed colors and switches

🔧 What does this fix? 🔧

fixed unthemed "cancel" button and icon buttons in create post modal
fixed switches

🗒 Checklist 🗒

[x] I have read and followed Catppuccin's contributing guidelines.
[x] I have updated the version appropriately in the ==UserStyle== header of the catppuccin.user.css file.

oh oop aight ill keep that in mind ^^


Forbid dependency resolution at configuration time by default

After seeing even sophisticated Gradle users stumble over this countless times, I'm convinced that dependency resolution at configuration time should be an error by default. I'm hard pressed to think of any use case for it, but if there is we could allow it with a special method like
allowingExpensiveOperations {
  configuration.files...
}

As a first step we could deprecate resolution at configuration time, pointing users at the user guide and performance guide for an explanation what configuration time is and why resolving dependencies during that phase is wrong. We could encourage them to get in touch in the forum if they think they have a use case that warrants it.
In the next major version we could then turn this into an error. Finally, if there are any good use cases for resolving at configuration time, we could create better APIs to solve those use cases. Then we could even remove the workaround method.

@oehme I think this should be reconsidered for 5.0 given that the Kotlin team messed up too: https://youtrack.jetbrains.com/issue/KT-26065.

Has this been implemented? I'm seeing a user who let me know they're seeing an error now:

java.lang.RuntimeException: Configuration 'ktlint' was resolved during configuration time.

Is there a separate issue tracking the implementation of this feature which has been completed?

I'm not aware of such a change, I suspect a plugin is doing this.

@melix Heres the issue that caused me to ask this question, apparently the Android plugin is doing this audit now.
https://github.com/JLLeitschuh/ktlint-gradle/issues/219

i reported a usage scenario that seems to require early dependency resolution to get any semblance of cleanliness in the code. it's here. or maybe there is something i haven't thought of? thanks!

I'm getting it with gradle 5.4 and AGP 3.4.0-rc2. It looks like it comes from the Android plugin:
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
	at com.android.build.gradle.internal.EarlyDependencyResolutionListener.beforeResolve(DependencyResolutionChecks.kt:74)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.gradle.configuration.internal.DefaultListenerBuildOperationDecorator$BuildOperationEmittingInvocationHandler.invoke(DefaultListenerBuildOperationDecorator.java:228)
	at com.sun.proxy.$Proxy36.beforeResolve(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
	at org.gradle.internal.event.DefaultListenerManager$ListenerDetails.dispatch(DefaultListenerManager.java:376)
	at org.gradle.internal.event.DefaultListenerManager$ListenerDetails.dispatch(DefaultListenerManager.java:358)
	at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:58)
	at org.gradle.internal.event.DefaultListenerManager$EventBroadcast$ListenerDispatch.dispatch(DefaultListenerManager.java:346)
	at org.gradle.internal.event.DefaultListenerManager$EventBroadcast$ListenerDispatch.dispatch(DefaultListenerManager.java:333)
	at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:42)
	at org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:230)
	at org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:149)
	at org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:140)
	at org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:37)
	at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
	at com.sun.proxy.$Proxy28.beforeResolve(Unknown Source)
	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.performPreResolveActions(DefaultConfiguration.java:638)```

Is it possible somehow disable it?

There's no way to disable this check from Gradle, this is done in the Android Plugin. I don't think there are a lot of use cases, if any, that require resolution at configuration time. In most cases deferring by using a closure would be enough.

I assume it is connected with usage of gradle 5.4 since the same Android plugin works fine on gradle 5.3

Note that that stacktrace is not a failure, but a warning with stacktrace logged at info, see the line number - turning --info off will lead to the warning not being generate. Sounds like we (the Android Gradle Plugin team) need to update this check for changes in Gradle 5.4, but other than the noise it should not affect the build.

Thanks, I have build failed and log is cut on CI and this last messeges, so I intepreted them as a cause but it is not.
Thank you again!

For some of my projects #9150 is the primary cause of eager dependency resolution. If that is fixed my dependency resolution is happily working at execution time. I think making this default behavior proposed here is the way to eradicate this problem even from Gradle core itself.

See https://github.com/gradle/gradle/issues/2298 is popping up in my gradle run that also has a native part done triggering cmake but I can't tell how to fix looking at it. It's a regular Android Studio made project using the 4.1.1 version. Reading the top message here doesn't tell me much as to why I am getting it.

See https://github.com/gradle/gradle/issues/2298 is popping up in my gradle run that also has a native part done triggering cmake but I can't tell how to fix looking at it. It's a regular Android Studio made project using the 4.1.1 version. Reading the top message here doesn't tell me much as to why I am getting it.

I came across this scenario today and yes the error is thrown by AGP.
Development Environment:
 IDE: Android Studio 4.1.3
 Build #AI-201.87<IP_ADDRESS>99119,
 Runtime version: 1.8.0_242-release-1644-b3-6915495 x86_64
 VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
 macOS 10.16
 AGP: 4.1.3
 Gradle Version: 6.5

Steps to replicate:

Create an Android project and implement a simple binary plugin for Android Library which has the below

 repositories {
 google()
 jcenter()
 mavenCentral()
 }

Create some (in my case 6) android library where the above binary plugin is applied through plugin{} in build.gradle.kts of
the library modules
Write a simple coroutine method inside
Run assemble task
Remove mavenCentral() from the above plugin [Just to replicate this]
Invalidate cache and Restart Android Studio
Run assemble task
kotlin couroutines dependencies are not resolved
If you then look into the logs of Run with --info

You will see
Selected primary task 'assemble' from project :
java.lang.RuntimeException: Configuration 'kotlinCompilerClasspath' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
   at com.android.build.gradle.internal.DependencyResolutionChecks$registerDependencyCheck$2$1.execute(DependencyResolutionChecks.kt:71)
   at com.android.build.gradle.internal.DependencyResolutionChecks$registerDependencyCheck$2$1.execute(DependencyResolutionChecks.kt)
   at org.gradle.configuration.internal.DefaultUserCodeApplicationContext$2.execute(DefaultUserCodeApplicationContext.java:79)
   at org.gradle.internal.event.BroadcastDispatch$ActionInvocationHandler.dispatch(BroadcastDispatch.java:95)
   at org.gradle.internal.event.BroadcastDispatch$ActionInvocationHandler.dispatch(BroadcastDispatch.java:83)
   at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:42)
   at org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:245)
   at org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:157)
   at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:58)
   at org.gradle.internal.event.BroadcastDispatch$CompositeDispatch.dispatch(BroadcastDispatch.java:346)
   at org.gradle.internal.event.BroadcastDispatch$CompositeDispatch.dispatch(BroadcastDispatch.java:249)
   at org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:141)
   at org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:37)
   at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
   at com.sun.proxy.$Proxy30.beforeResolve(Unknown Source)
   at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.performPreResolveActions(DefaultConfiguration.java:675)
   at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.access$400(DefaultConfiguration.java:142)
   at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$1.run(DefaultConfiguration.java:618)
   at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:395)
   at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:387)
   at org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:157)
   at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:242)
   at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:150)
   at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:84)
   at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
   at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.resolveGraphIfRequired(DefaultConfiguration.java:611)
   at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.lambda$resolveExclusively$4(DefaultConfiguration.java:592)
   at org.gradle.api.internal.project.DefaultProjectStateRegistry$SafeExclusiveLockImpl.withLock(DefaultProjectStateRegistry.java:289)
   at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.resolveExclusively(DefaultConfiguration.java:590)
   at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.resolveToStateOrLater(DefaultConfiguration.java:576)
   at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.access$1900(DefaultConfiguration.java:142)
   at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$ConfigurationFileCollection.getSelectedArtifacts(DefaultConfiguration.java:1251)
   at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$ConfigurationFileCollection.visitContents(DefaultConfiguration.java:1242)
   at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$ConfigurationFileCollection.getFiles(DefaultConfiguration.java:1232)
   at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.getFiles(DefaultConfiguration.java:484)
   at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration_Decorated.getFiles(Unknown Source)
   at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.resolve(DefaultConfiguration.java:474)
   at org.jetbrains.kotlin.gradle.tasks.AbstractKotlinCompileTool$computedCompilerClasspath$2.invoke(Tasks.kt:113)
   at org.jetbrains.kotlin.gradle.tasks.AbstractKotlinCompileTool$computedCompilerClasspath$2.invoke(Tasks.kt:105)
   at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)

Hope the above info helps.

I use afterEvaluate with preDebugBuild.spotlessApply in order to format my automatically code as I'm building it, and I end up getting this error. How should I replace it with a method that does not resolve deps at configuration time?

Hi, I got these warnings after upgrading AGP 7.1.2 to 7.4.1
After checking, the code that trigger this is a dependency substitution rules in our plugin, something like this:
project.configurations.configureEach {
  resolutionStrategy.dependencySubstitution {
    modulesToBeSubstituted.forEach { module ->
      substitute(module(A)).using(project(A))
    }
 }
}

And checking the AGP code to avoid this warning we need to resolve it after task graph is ready.
After wrapping the code above in taskGraph.whenReady the warning is gone and the substitution is working correctly.
Questions:

Why a dependency substitution rules in our plugin triggering a dependency resolution? We have another rules inside a gradle script (*.gradle) but it's working fine
Will there be an issue with adding a substitution rules after task graph ready?
What's the alternative in this case?

Thank you

I am getting this warning in my Android application project. How can I fix this?
$ ./gradlew clean aCcc36c3Debug --stacktrace --info

...

> Configure project :network
Evaluating project ':network' using build file 'EventFahrplan/network/build.gradle'.
Using default execution profile
Using Kotlin Gradle Plugin gradle76 variant
Task name matched 'clean'
Abbreviated task name 'aCcc36c3Debug' matched 'assembleCcc36c3Debug'
Selected primary task 'clean' from project :
Selected primary task 'aCcc36c3Debug' from project :
Configuration 'kspCcc36c3DebugKotlinProcessorClasspath' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
java.lang.RuntimeException: Configuration 'kspCcc36c3DebugKotlinProcessorClasspath' was resolved during configuration time.

After wrapping the code above in taskGraph.whenReady the warning is gone and the substitution is working correctly.

Actually, this is not true. The change introduced a subtle bug that we decided to revert the change.
For the warning message since it's annoying and making devs hard to read the console, we monkey-patched AGP to remove it.

I just upgraded to Android Studio 2022.1 patch 2 and upgraded gradle to version 7.5.1.  When I rebuilt my project in this new environment I got the following message:
Configuration 'mavenResource' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
here's the relevant portions of what my build.gradle.kts file looks like:
val mavenResource  = configurations.create("mavenResource")
dependencies {
....
mavenResource(some dependency)
}
So that is what appears to me to be what causing this message about the performance and scalability issue  that's what  got me to this discussion.  So "oehme" makes the claim that there is no reason for someone to have a configuration resolved at configuration time.  In most situations that's probably true, but there are reasons for doing that.  In my case, I add the configuration named "mavenResource".  In the dependencies block I add any number of "mavenResource" dependencies.  My project also applies a custom plugin that finds the mavenResource configuration and then copies all the files for those resolved dependencies to the projects "resources" directory.  It's a very simply handy way to add resources to my project where the resources are stored in a maven repository.   My actual dependencies are specified in a toml version file.  So if I change the version of a given resource in the toml version file, my project when rebuilt gets the right version of the resource.  I claim that's a legitimate use of a configuration time dependency resolution.  I'm taking advantage of gradle's mechanism for getting dependency from a repository, not for code library, but for resource objects. What's neat is that it only takes a couple lines of code in a custom plugin to take advantage of this.  By disabling this feature, I don't think I have such a nice elegant solution.
Also, when you put together JavaDoc documents, one often needs to add a "javaDoc" configuration so that you can add some additional dependencies for the JavaDoc task.   I believe that too, would cause this same warning.

I believe, according to the current Gradle best practices it should all be done in a lazy manner. That is, the plugin can still scan all mavenResource configuration but only declare, how these resources should be downloaded, in a form of lambdas wrapped into Providers. The plugin should also register a task, that would download the resources (i.e. execute lambdas of these Providers). Tasks, that require these resources (assembling of JARs, for example), need to be dependent on those resource downloading tasks.
As I understand it, the main motivation behind this restriction is, that you don't need to perform time-consuming operations that are not essential for the build logic itself, but only for the application code.

I have the same problem 2298 =>> , how to fix it, thanks.

One use case is that I want to quicky what jar's my classpath resolves to. Previously I could just do configurations.runtimeClasspath.files.each { printlnt(it) }. What do I do now?

The same, but wrapped in val foo by tasks.registering { doLast { ... } }?

Any Update on This Issue has it been Resolved by anone?

@mgroth0 In Gradle 7.5 the ability to use dependency resolution results as task inputs was added, which is compatible with the config cache.
https://docs.gradle.org/current/userguide/incremental_build.html#sec:task_input_using_dependency_resolution_results
There is a sample project referenced at the end of that section. Hopefully that's sufficient for your use case.

Not sure if the warning message is meant for final users (app developers) or for developers of various plugins (ie Google employees working on Android Studio)

I'm hard pressed to think of any use case for it

Just in case, a valuable and useful case for this feature is documented here:
https://developer.android.com/build/dependencies
Please just don't remove the feature documented above.

Configure project :app
Configuration 'androidApis' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'androidJdkImage' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'androidTestCompileOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'androidTestDebugCompileOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'androidTestDebugImplementation' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'androidTestDebugRuntimeOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'androidTestDebugWearApp' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'androidTestImplementation' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'androidTestReleaseCompileOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'androidTestReleaseImplementation' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'androidTestReleaseRuntimeOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'androidTestReleaseWearApp' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'androidTestRuntimeOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'androidTestUtil' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'androidTestWearApp' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'annotationProcessor' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'api' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'archives' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'compileOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'coreLibraryDesugaring' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'debugAnnotationProcessorClasspath' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'debugApi' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'debugApiElements' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'debugCompileOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'debugImplementation' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'debugReverseMetadataValues' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'debugRuntimeClasspath' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'debugRuntimeElements' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'debugRuntimeOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'debugUnitTestAnnotationProcessorClasspath' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'debugWearApp' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'debugWearBundling' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'default' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'implementation' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'lintChecks' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'lintPublish' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'releaseAnnotationProcessorClasspath' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'releaseApi' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'releaseApiElements' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'releaseCompileOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'releaseImplementation' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'releaseReverseMetadataValues' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'releaseRuntimeClasspath' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'releaseRuntimeElements' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'releaseRuntimeOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'releaseUnitTestAnnotationProcessorClasspath' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'releaseWearApp' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'releaseWearBundling' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'runtimeOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testCompileOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testDebugCompileOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testDebugImplementation' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testDebugRuntimeOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testDebugWearApp' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testFixturesApi' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testFixturesCompileOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testFixturesDebugApi' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testFixturesDebugCompileOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testFixturesDebugImplementation' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testFixturesDebugRuntimeOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testFixturesDebugWearApp' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testFixturesImplementation' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testFixturesReleaseApi' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testFixturesReleaseCompileOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testFixturesReleaseImplementation' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testFixturesReleaseRuntimeOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testFixturesReleaseWearApp' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testFixturesRuntimeOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testFixturesWearApp' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testImplementation' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testReleaseCompileOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testReleaseImplementation' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testReleaseRuntimeOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testReleaseWearApp' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testRuntimeOnly' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.
Configuration 'testWearApp' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298
Run with --info for a stacktrace.

Task :app:preBuild UP-TO-DATE
Task :app:preReleaseBuild UP-TO-DATE
Task :app:generateReleaseResValues UP-TO-DATE
Task :app:processReleaseGoogleServices UP-TO-DATE
Task :app:mapReleaseSourceSetPaths UP-TO-DATE
Task :app:generateReleaseResources UP-TO-DATE
Task :app:mergeReleaseResources UP-TO-DATE
Task :app:createReleaseCompatibleScreenManifests UP-TO-DATE
Task :app:extractDeepLinksRelease UP-TO-DATE
Task :app:processReleaseMainManifest UP-TO-DATE
Task :app:processReleaseManifest UP-TO-DATE
Task :app:processApplicationManifestReleaseForBundle UP-TO-DATE
Task :app:checkReleaseAarMetadata UP-TO-DATE
Task :app:packageReleaseResources UP-TO-DATE
Task :app:parseReleaseLocalResources UP-TO-DATE
Task :app:processReleaseManifestForPackage UP-TO-DATE
Task :app:processReleaseResources UP-TO-DATE
Task :app:bundleReleaseResources UP-TO-DATE
Task :app:mergeReleaseShaders UP-TO-DATE
Task :app:compileReleaseShaders NO-SOURCE
Task :app:generateReleaseAssets UP-TO-DATE
Task :app:mergeReleaseAssets UP-TO-DATE
Task :app:checkReleaseDuplicateClasses UP-TO-DATE
Task :app:generateReleaseBuildConfig UP-TO-DATE
Task :app:javaPreCompileRelease UP-TO-DATE
Task :app:compileReleaseJavaWithJavac UP-TO-DATE
Task :app:mergeReleaseArtProfile UP-TO-DATE
Task :app:expandReleaseArtProfileWildcards UP-TO-DATE
Task :app:extractProguardFiles UP-TO-DATE
Task :app:mergeReleaseGeneratedProguardFiles UP-TO-DATE
Task :app:processReleaseJavaRes NO-SOURCE
Task :app:mergeReleaseJavaResource UP-TO-DATE
Task :app:mergeReleaseJniLibFolders UP-TO-DATE
Task :app:mergeReleaseNativeLibs UP-TO-DATE
Task :app:stripReleaseDebugSymbols UP-TO-DATE
Task :app:writeReleaseAppMetadata UP-TO-DATE
Task :app:collectReleaseDependencies UP-TO-DATE
Task :app:configureReleaseDependencies UP-TO-DATE
Task :app:extractReleaseNativeSymbolTables UP-TO-DATE
Task :app:parseReleaseIntegrityConfig UP-TO-DATE
Task :app:validateSigningRelease UP-TO-DATE
Task :app:minifyReleaseWithR8
Task :app:buildReleasePreBundle
Task :app:compileReleaseArtProfile
Task :app:packageReleaseBundle
Task :app:signReleaseBundle
Task :app:produceReleaseBundleIdeListingFile
Task :app:createReleaseBundleListingFileRedirect UP-TO-DATE
Task :app:bundleRelease

BUILD SUCCESSFUL in 2m 9s
42 actionable tasks: 6 executed, 36 up-to-date
Build Analyzer results available

I'm still unsure why this ticket is still open, but I do get a bunch of notifications so here I am. IMO, this ticket doesn't really make much sense, especially with "modern Gradle". The idea, AFAIK, is to be able at some point to interweave configuration and execution, so that tasks which are configured and ready to execute can start while dependents are still configuring. Even if Gradle is not there yet, the configuration cache already provides improvements going in that direction. I don't think that forbidding dependency resolution at configuration time is, in that context, a good idea. It will certainly break some builds, while not being strictly necessary. I do agree however that for many builds this can be an issue, but that's an inspection which is already available for example in build scans.

I know it's late, but perhaps this comment can help some people that have the same issue.
Background
If your project is:

Using Android Gradle Plugin
Using Resolution Strategy to substitute external module dependency with a project dependency, something like this:

configurations.all {
    resolutionStrategy.dependencySubstitution {
        substitute(module("org.utils:api"))
            .using(project(":api")).because("we work with the unreleased development version")
    }
}

It does trigger long warning in the build log, because some configuration from Android Gradle Plugin is being resolved at configuration time, see here for more information.
Because using configurations.all will list all the configurations including the one from Android Gradle Plugin and implement the resolution strategy even to the configuration that doesn't even use it.
Solution
The solution is simple. If you're declaring the dependencies using implementation configuration like this:
implementation(libs.utils.api)

The fix is you only need to declare resolution strategy to implementation configuration like this:
configurations.getByName("implementation") {
    resolutionStrategy.dependencySubstitution {
        substitute(module("org.utils:api"))
            .using(project(":api")).because("we work with the unreleased development version")
    }
}

Some plugins might use detached configs to resolve internal dependencies at config time, I'm guessing this constraint won't affect resolving detached configs?


[BUG FIX] Fix the WAD script url in README

🐛 The url to get the wad script in the README.md seem to be incorrect.
I think the following command is correct :
### Get the WAD script
...
$ curl -o bin/wad https://raw.githubusercontent.com/Fingertips/WAD/master/bin/wad

Here as well
### Alternative build configuration
...
install: "curl https://raw.githubusercontent.com/Fingertips/WAD/master/bin/wad | ruby"

We've stopped using WAD because there is now arbitrary directory caching in Travis:
https://docs.travis-ci.com/user/caching/#Arbitrary-directories
I would recommend using that instead. If you do want this changed in WAD for convenience I will gladly merge a pull request.

@Manfred
Understood, thanks for the feedback.
I think merging won't be necessary :)


Debug window keeps horizontal resize cursor active, when closed

Version 1.18.0
Commit dcee2202709a4f223185514b9275aa4229841aa7
Date 2017-11-08T21:22:49.932Z
Shell 1.7.9
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64
Steps to Reproduce:

Show Debug window
Move to right
Close and you will see the cursor on the same position

@Ripper1992 I do not really see the cursor on this picture. Can you please clarify what is wrong here.
What is expected here?

@isidorn here is the video. You can see when I hide de terminal pane the width adjust cursor continues to appear.

Thanks this is fixed in latest


Added sizeInGb and sizeInBytes properties to OSDiskImage

Related issue: https://github.com/Azure/azure-sdk-for-net/issues/15705
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
If updating an existing version, please select the specific language SDKs and CLIs that must be refreshed after the swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[ ] No refresh required for updates in this PR

Contribution checklist:

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[ ] Check this box if any of the following appy to the PR so that the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review.  Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you are using OpenAPIHub to initialize the PR for adding a new version. More details, refer to the wiki.

[ ] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[ ] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

@ArcturusZhang I'm having issues with this PR and was wondering if you could advise on what changes I need to make?
The goal of the PR is to just add these properties which are being returned from the API but are not in the spec or the SDKs.
I tried adding these properties to the 2022-03-01 version and the CI pipeline complained that this is a breaking change and I need a new version.
I tried adding a new 2022-07-11 version and I had to include a lot of files which were referenced even though I haven't had to change them. Also, the CI pipeline is complaining that there should be a corresponding 2022-07-11 API version.
Is there something I'm missing? Does this really need a new API version despite the correct properties being returned already?
Thanks!

@ArcturusZhang are we able to reopen this please?


Out of date AsyncTCP dependency?

I've run into a compilation issue with #develop branch, as seen at https://travis-ci.org/kylegordon/homie-sonoff-touch/builds/312535275#L727 where it's failing with fatal error: freertos/semphr.h: No such file or directory
It's apparently a solved problem, as per https://github.com/me-no-dev/AsyncTCP/issues/2 so I was wondering if Homie has an out of date dependency?

FreeRTOS? AsyncTCP is an ESP32 library, ESPAsyncTCP is for ESP8266, you
need this one.
Le mer. 6 déc. 2017 à 18:38, Kyle Gordon<EMAIL_ADDRESS>a
écrit :

I've run into a compilation issue with #develop branch, as seen at
https://travis-ci.org/kylegordon/homie-sonoff-touch/builds/312535275#L727
where it's failing with fatal error: freertos/semphr.h: No such file or
directory
It's apparently a solved problem, as per me-no-dev/AsyncTCP#2
https://github.com/me-no-dev/AsyncTCP/issues/2 so I was wondering if
Homie has an out of date dependency?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/marvinroger/homie-esp8266/issues/444, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AA8eNY2guQG-BkfJ_xC5bJ7abA75meo2ks5s9tEjgaJpZM4Q4UD_
.

travis-ci can reproduce, see https://travis-ci.org/euphi/Homie_BareMinimum/builds/312604604 .
For this test, I created a very simple repository https://github.com/euphi/Homie_BareMinimum .
However, at my own computer, I got another error message, see #429

One strange thing is that I have a different dependency tree at home than travis-ci:
Verbose mode can be enabled via `-v, --verbose` option
Collected 31 compatible libraries
Looking for dependencies...
Library Dependency Graph
|-- <Hash> v1.0
|-- <Homie> v2.0.0
|   |-- <ArduinoJson> v5.11.2
|   |-- <AsyncMqttClient> v0.8.1
|   |   |-- <ESPAsyncTCP> v1.1.3
|   |   |   |-- <ESP8266WiFi> v1.0
|   |-- <Bounce2> v2.3
|   |-- <Ticker> v1.0
|   |-- <DNSServer> v1.1.0
|   |   |-- <ESP8266WiFi> v1.0
|   |-- <Homie> v2.0.0
|   |   |-- <ArduinoJson> v5.11.2
|   |   |-- <AsyncMqttClient> v0.8.1
|   |   |   |-- <ESPAsyncTCP> v1.1.3
|   |   |   |   |-- <ESP8266WiFi> v1.0
|   |   |-- <Bounce2> v2.3
|   |   |-- <ESP Async WebServer> v1.1.1
|   |   |   |-- <ESPAsyncTCP> v1.1.3
|   |   |   |   |-- <ESP8266WiFi> v1.0
|   |   |   |-- <ESP8266WiFi> v1.0
|   |   |   |-- <ArduinoJson> v5.11.2
|   |   |   |-- <Hash> v1.0
|   |   |-- <ESPAsyncTCP> v1.1.3
|   |   |   |-- <ESP8266WiFi> v1.0
|   |   |-- <DNSServer> v1.1.0
|   |   |   |-- <ESP8266WiFi> v1.0
|   |   |-- <ESP8266HTTPClient> v1.1
|   |   |   |-- <ESP8266WiFi> v1.0
|   |   |-- <Ticker> v1.0
|   |   |-- <ESP8266WiFi> v1.0
|   |   |-- <ESP8266mDNS>
|   |   |   |-- <ESP8266WiFi> v1.0
|   |-- <ESP8266httpUpdate> v1.1
|   |   |-- <ESP8266WiFi> v1.0
|   |   |-- <ESP8266HTTPClient> v1.1
|   |   |   |-- <ESP8266WiFi> v1.0
|   |-- <ESP8266WiFi> v1.0
|   |-- <ESP8266mDNS>
|   |   |-- <ESP8266WiFi> v1.0
|   |-- <ESP8266WebServer> v1.0
|   |   |-- <ESP8266WiFi> v1.0

Note that  v2.0.0 is listed two times - with different dependencies to lower-level libraries?!
Maybe @ivankravets  has a hint?
(version of platformio is "PlatformIO, version 3.4.1" in both cases).
I saw that the examples from Homie run fine on travis-ci. And also one of my larger projects compiles fine at home with Homie v2.0.0-beta.3 (I haven't tried the others yet).

Oh, the "larger project" is also on travis-ci - and compiles fine after upgrading Homie to latest development (==v2.0.0-beta.3): https://travis-ci.org/euphi/ESP_Homie_WS2812FX

@marvinroger I agree, it shouldn't be requiring ESP32 libraries. I'm not declaring anything other than Homie though.
If you have a look at line 578, https://travis-ci.org/kylegordon/homie-sonoff-touch/builds/312535275#L578 it seems to be bringing it in via  v1.1.1
Is this a problem that should be referred to https://github.com/me-no-dev/ESPAsyncWebServer (again) ?

Yeah, setting the ldf-mode of platformio to chain+ (instead of the default chain) fixes the problem. (see https://github.com/platformio/platformio-core/issues/1153)
Commit:
https://github.com/euphi/Homie_BareMinimum/commit/236bac778a715d94f360dada04b3512acc81a7c0
fixes the build (https://travis-ci.org/euphi/Homie_BareMinimum/builds/313215893).

So whats needed to be done here ?

Hello, I'm facing the same issue, but in can't remove the wrong lib.
First I do:
thomas@Thomas-Aspire-V5-573G:~/MEGA/Coding/plant_care/plant_care_esp8266$ pio lib uninstall AsyncTCP
Library Storage: /home/thomas/MEGA/Coding/plant_care/plant_care_esp8266/.piolibdeps
Uninstalling AsyncTCP @ 1.0.1:  [OK]
thomas@Thomas-Aspire-V5-573G:~/MEGA/Coding/plant_care/plant_care_esp8266$ pio lib uninstall AsyncTCP
Library Storage: /home/thomas/MEGA/Coding/plant_care/plant_care_esp8266/.piolibdeps
Error: Detected unknown package 'AsyncTCP @ *'

But then I get: (It just reinstalls the libraries)
/home/thomas/.local/share/JetBrains/Toolbox/apps/CLion/ch-1/173.4127.6/bin/cmake/bin/cmake --build /home/thomas/MEGA/Coding/plant_care/plant_care_esp8266/cmake-build-debug --target PLATFORMIO_BUILD -- -j 2
[Thu Dec 28 13:46:02 2017] Processing d1_mini (platform: espressif8266; lib_deps: Hash, Adafruit Unified Sensor, https://github.com/adafruit/Adafruit_BMP085_Unified.git, https://github.com/adafruit/Adafruit_Sensor.git, https://github.com/claws/BH1750.git, https://github.com/adafruit/DHT-sensor-library.git, https://github.com/me-no-dev/ESPAsyncWebServer.git, https://github.com/arduino-libraries/NTPClient.git, https://github.com/knolleary/pubsubclient.git, https://github.com/ThomasDevoogdt/SensorFacade.git; upload_speed: 115200; board: d1_mini; framework: arduino)
--------------------------------------------------------------------------------
LibraryManager: Installing id=305
Unpacking...
LibraryManager: Installing id=1826
Unpacking...
Verbose mode can be enabled via `-v, --verbose` option
Collected 38 compatible libraries
Looking for dependencies...
Library Dependency Graph
|-- <Hash> v1.0
|-- <Adafruit Unified Sensor> v1.0.2
|-- <Wire> v1.0
|-- <Ticker> v1.0
|-- <DNSServer> v1.1.0
|   |-- <ESP8266WiFi> v1.0
|-- <DHT sensor library> v1.3.0
|   |-- <Adafruit Unified Sensor> v1.0.2
|-- <ESP Async WebServer> v1.1.1
|   |-- <ESPAsyncTCP> v1.1.3
|   |   |-- <ESP8266WiFi> v1.0
|   |-- <ESP8266WiFi> v1.0
|   |-- <AsyncTCP> v1.0.1
|   |-- <Hash> v1.0
|-- <PubSubClient> v2.6
|-- <Adafruit BMP085 Unified> v1.0.0
|   |-- <Wire> v1.0
|   |-- <Adafruit Unified Sensor> v1.0.2
|-- <BH1750>
|   |-- <Wire> v1.0
|-- <ESP8266WiFi> v1.0
|-- <SensorFacade> v1.0
|-- <NTPClient> v3.1.0
Archiving .pioenvs/d1_mini/lib/libESPAsyncTCP.a
Compiling .pioenvs/d1_mini/lib/AsyncTCP_ID1826/AsyncTCP.o
Compiling .pioenvs/d1_mini/lib/ESP Async WebServer/AsyncWebSocket.o
Compiling .pioenvs/d1_mini/lib/ESP Async WebServer/SPIFFSEditor.o
Indexing .pioenvs/d1_mini/lib/libESPAsyncTCP.a
In file included from .piolibdeps/AsyncTCP_ID1826/src/AsyncTCP.cpp:24:0:
.piolibdeps/AsyncTCP_ID1826/src/AsyncTCP.h:28:29: fatal error: freertos/semphr.h: No such file or directory
#include "freertos/semphr.h"
^
compilation terminated.
*** [.pioenvs/d1_mini/lib/AsyncTCP_ID1826/AsyncTCP.o] Error 1
========================== [ERROR] Took 2.40 seconds ==========================
CMakeFiles/PLATFORMIO_BUILD.dir/build.make:57: recept voor doel 'CMakeFiles/PLATFORMIO_BUILD' is mislukt
make[3]: *** [CMakeFiles/PLATFORMIO_BUILD] Fout 1
CMakeFiles/Makefile2:67: recept voor doel 'CMakeFiles/PLATFORMIO_BUILD.dir/all' is mislukt
make[2]: *** [CMakeFiles/PLATFORMIO_BUILD.dir/all] Fout 2
CMakeFiles/Makefile2:79: recept voor doel 'CMakeFiles/PLATFORMIO_BUILD.dir/rule' is mislukt
make[1]: *** [CMakeFiles/PLATFORMIO_BUILD.dir/rule] Fout 2
Makefile:118: recept voor doel 'PLATFORMIO_BUILD' is mislukt
make: *** [PLATFORMIO_BUILD] Fout 2

@ThomasDevoogdt do you use the latest PIO Core 3.5.0?
pio --version
pio upgrade

I have the newest version of PIO. First I deleted the .pioenvs completely, and all the wrong libs in .piolibdeps. Next I tried again and got new errors. This post helped me: c2d4c16. I moved ESPAsyncTCP and ESP Async WebServer to the lib folder, so it won't update any more.

I tried to compile https://github.com/euphi/Homie_BareMinimum again, with a fresh checkout, and it seems to fail. Using PlatformIO 3.5.0 here.
git clone https://github.com/euphi/Homie_BareMinimum
cd Homie_BareMinimum
pio run

However, if you run pio lib update prior to pio run, it seems to work.
I don't know why pio run brings in ESPAsyncTCP 1.0.1, but the update seems to get 1.1.3 instead.
After 1.1.3 is installed, it will compile as expected.

I don't know why pio run brings in ESPAsyncTCP 1.0.1, but the update seems to get 1.1.3 instead.

Because

https://github.com/marvinroger/homie-esp8266/blob/develop/library.json#L29
https://github.com/marvinroger/async-mqtt-client/blob/master/library.json#L21

Please contact @marvinroger and ask them to resolve all issues with dependencies.

yep i think the issue is that async-mqtt-client needs updating which should fix homie's sub dependencies


"Unable to make progress running work." error when adding entry task to execution plan in 7.5 rc 1

Adding an entry task to the execution plan no longer works in Gradle 7.5-rc1.
Expected Behavior

Build to run successfully and include the added task.
Current Behavior

We add a bootstrap task that updates the developer local environment to each build (IDE and command line) to ensure our developer environments are always up to date. This is done by adding an entry task to the execution plan.
gradle.taskGraph.whenReady {
    withGroovyBuilder {
        val executionPlan: ExecutionPlan = getTypedProperty("executionPlan")
        executionPlan.addEntryTasks(listOf(taskProvider.get()))
        executionPlan.determineExecutionPlan()
    }
}

In Gradle 7.5-rc1, this no longer works. We get the following error.
Unable to make progress running work. The following items are queued for execution but none of them can be started: |
-- | --
  | - Queued nodes for : |
  | - :bootstrap (state=SHOULD_RUN, dependencies=NOT_COMPLETE, group=task group 1, successors=[])

Context

We are unable to upgrade to Gradle 7.5-rc1.
Steps to Reproduce

Clone https://github.com/jlvs-chirp/gradle-issue-reproducer. Run ./gradlew build. It should fail with the above error.
Change the Gradle version from 7.5-rc1 to 7.4.2 with the following diff. Run ./gradlew build again. It should pass.
diff --git a/gradle/wrapper/gradle-wrapper.properties b/gradle/wrapper/gradle-wrapper.properties
index fcfb29d..aa991fc 100644
--- a/gradle/wrapper/gradle-wrapper.properties
+++ b/gradle/wrapper/gradle-wrapper.properties
@@ -1,5 +1,5 @@
 distributionBase=GRADLE_USER_HOME
 distributionPath=wrapper/dists
-distributionUrl=https\://services.gradle.org/distributions/gradle-7.5-rc-1-bin.zip
+distributionUrl=https\://services.gradle.org/distributions/gradle-7.4.2-bin.zip
 zipStoreBase=GRADLE_USER_HOME
 zipStorePath=wrapper/dists

Your Environment

Build scan URL:
https://scans.gradle.com/s/m6naiyvnvcray

This is related to #20480

Suggestion to use StartParameter mentioned in comment works.


feat: Add newtype parameter attribute modifier

This adds a new parameter attribute modifier newtype. This enables code like this:
struct Baz(Vec<u32>);

impl Baz {
    delegate! {
        to self.0 {
            fn extend(&mut self, #[newtype] other: Baz);
        }
    }
}

which will generate the following code:
#[inline]
fn extend(&mut self, other: Baz) {
    self.0.extend(other.0);
}

This new modifier enables access to the inner value of a newtype struct.

Oh, I just realized I should have adjusted the changelog as well. Let me know if this PR will move forward, and if so, I can make a changelog entry.

Hi, thanks for the PR! Various argument and expression modifiers keep cropping up. I wonder if we should instead do some generic syntax for modifying the argument, like fn foo(&self, #[expr(0)] bar: Bar, #[expr(as_ref())] bar2: Bar), that would be simply appended after the dot (.).
But for now I think that adding one more modifier is fine. This PR looks fine, if you would be so kind and update the changelog and also README (there are examples of existing argument modifiers), that would be great!

Yeah, I was wondering the same. I wasn't quite sure if there is a policy around adding those modifiers. That's why I decided to use the existing ones as a blueprint. But having a generic modifier sounds like a nice idea. We should probably validate the input, so that we narrow the possibility of generating invalid Rust code.
I will update the changelog and README immediately.

This PR should now be ready to go.

Thank you! Since there was a merge commit, I took the liberty of rebasing the PR.

Hey, just a quick question: When do you plan to release the changes introduced in this PR?

I created a new release with this changes, and a few other ones.

Thanks a lot @Kobzol!
I just noticed there are probably some git tags in this repo you did not create intentionally and might consider to remove again :sweat_smile:

Yeah I also noticed them :laughing: git tag allows creating tags too easily. Removed them, thanks :+1:


Update AUTHORS.rst (Re-trying of #1155)

This is another PR similar to #1155 but re-trying with the current master branch.

Just a tip, you can rebase your branch next time off the latest master.
git checkout master
git pull
git checkout patch-1
git rebase master
git push --force

If you get conflicts that you aren't sure how to resolve, you can do git rebase --abort, and if all else fails, you can get reset --hard origin/patch-1 to force your branch to be in sync with what is on github.
There's very likely a more concise way to do that, but that's the explicit way.


How to edit files?

How to edit files?
thank you

Download file from server.
Edit it by any own editor.
Upload it to server.

I've created updated version of tinyfilemanager with advanced edit feature, have look -
tinyfilemanager

@prasathmani Great! Added link to README.

@anephew Please use tinyfilemanager


⚠ Bofrost.lu has degraded performance

In ceb0eeb, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1085 ms

Resolved: Bofrost.lu performance has improved in 03eef2a.


can someone help me configure an api?

I have this error in the api in the ex of the OSL-client, since the OSL-WEB runs completely without errors, could someone help me solve this?, I already configured and reconfigured everything 3 times and I cannot run it anymore.

Hi @overkido
Do you have an image or the error line ?

Hi @overkido Do you have an image or the error line ?

I see you're using V1.0.0, you should download the latest version v1.1.0, it fixes this error.
Link last version

I put v1.1 but the problem continues.

What is the IP address of the PC on which you launched OSL-Web?

Apparently it's the DNS resolution that's having a problem.
What is the result of the "ipconfig" command in cmd ?

Apparently it's the DNS resolution that's having a problem. What is the result of the "ipconfig" command in cmd ?

For view 4 it's normal, it's only active during the 3min timer of the champ select when you're in spectator mode (at the end).
The whole inGame part is under development, there's only an overlay to display teams/scores/..., no display of score like tower, kill, items, level, ... for the moment.
But V1.2.0, when released, will have these features (expected late June - early July).
If you say that the champ select works, does that mean that OSL-client and OSL-Web communicate well ? Do you have the display of banns and picks ?

If you say that the champ select works, does that mean that OSL-client and OSL-Web communicate well ? Do you have the display of banns and picks ?

I solved the problem I think kkkk, I solved it by modifying the ip as you said, I put the same ip that opens in OSL Web, as you can see in the image below OSL Web it searches the IP alone here no hey why, I put the ip of the machine and it gave an error so I left the ip that it opens alone and put the same ip in the Client and the error stopped.

view 4 error in picks and bans is this one

This display only works when you're watching the champ select.
When players start their game and the champ select is finished, you have to wait 3 minutes before you can enter the game.
It's during this waiting phase that view 4 displays the following information.
As far as I'm concerned, view 4 displays information correctly when the field selection phase is in "Game_Starting" mode.


Fix typo

Q
A

Is bugfix?
✔

New feature?
❌

Breaks BC?
❌

Fixed issues
comma-separated list of tickets # fixed by the PR, if any

👍


Few changes to compose

Add simple tests
Add .dask property
Don't use partial if avoidable
Visualize method
Replace UUIDs with tokens, try to be consistent (could use help)

I cherry-picked most of these locally. Closing.

Thanks!  Requesting update to #408 when you get a chance

On this workload https://github.com/mrocklin/dask-crossval
The current branch in jcrist/compose produces this graph

While the old branch in mrocklin/compose produces this graph

From speaking with machine learning people I think that the older version in mrocklin/compose is correct.

hmmmm, the only difference is key naming. Must be something with that.


Delayed rendering in Nuxt.js - is there a way to not rerender on the client side?

Hi,
I'm having trouble with content in the markdown component rendering after other content in a nuxtjs app.
The issue likely stems from the component rerendering the content on the client side even though it is already rendered on the server side.
Is there a way for the component to not clear and rerender if it is already rendered? Maybe something about the context or what lifecycle hook it depends on?
All the best,
Em

see answer provided here: https://github.com/miaolz123/vue-markdown/issues/116#issuecomment-601696059


Control reinitializing of the proof's setUp function

Resolves #282
This PR adds the ability to skip the reinitalization of the setUp() function even though the --reinit flag was passed.
Users can pass --skip-setup-reinit flag to selectively skip the setUp()  proof being initialized.
This ability can be handled in a couple of different ways. This PR implements it by directly using the test's version when creating setup proofs and create jumps in the versions of the setup proofs. When a proof with a missing setup-id proof is called the latest setup proof that is smaller than current proof's id is used.
An alternative approach may be to relate setup functions with test functions by adding test function name to proof name such as instead of ContractName.setUp() we may use ContractName.testName.setUp() which will increase the footprint of proofs.
A more relaxed implementation can break the id relation between test proofs and respected setup functions and always using the latest version of the setUp() proof.

This implementation seems reasonable to me. I wouldn't tie test names to their respective setups, because it'd be more efficient to allow for tests sharing the same setUp(). But I'm on the fence between this implementation and just using the latest setUp() proof — since setUp is shared between functions, maybe the user would expect the second command to use the latest version of setUp, since he knows it was reinitialized in the first command:
kontrol prove --match-test testA --reinit
kontrol prove --match-test testB --skip-setup-reinit --reinit

I'd also like to ask for opinion from @nwatson22, who implemented the logic for proof versioning, and @anvacaru.

Thanks for addressing this issue @ovatman! This implementation seems very reasonable to me. I wouldn't tie test names to their respective setups, because it'd be more efficient to allow for tests sharing the same setUp(). But I'm on the fence between this implementation and just using the latest setUp() proof — since setUp is shared between functions, maybe the user would expect the second command to use the latest version of setUp, since he knows it was reinitialized in the first command:
kontrol prove --match-test testA --reinit
kontrol prove --match-test testB --skip-setup-reinit --reinit

I'd also like to ask for opinion from @nwatson22, who implemented the logic for proof versioning, and @anvacaru.

@ovatman @palinatolmach I agree using the latest proof version of the setup method before the version of the corresponding main method is maybe not ideal, since I don't really think of the version as being consistent across proofs. I would probably agree that using the latest version of setUp is the way to go, although I could still see situations where that would cause confusion. Do you you think would be better to, instead of having the --skip-setup-reinit option, to have an option that specifies the exact setup version to use?

@ovatman @nwatson22 Yes, I agree, having something like --setup-version sounds good to me.


Transfer to live agent.

Is it possible to transfer the call to a other live agent when a specific intent is triggert?

Yes, have a look at the simwood branch.  Here is where I look at the returned intent to see if a call transfer is requested:
https://github.com/davehorton/drachtio-dialogflow-phone-gateway/blob/c088a99a134b838ee1c6c3c92a92503a3ced9926/lib/models/intent.js#L55
You can do something like that, modify the conditions to your needs.  Return the agent number to transfer to in a custom payload


Document how to build a custom image

While Ignition allows to download files/binaries from a remote location and store them somewhere (except /usr), this download phase can be avoided if the files are provided as part of a custom image.
We should publish how to modify the image and how to install a modified image with flatcar-install. Decide which image types to use because some cases like PXE images may be more involved.

[x] Create document on how to build custom images
[ ] Add documentation on using flatcar-install to update an existing installation with the image created

We're 50% there: https://kinvolk.io/docs/flatcar-container-linux/latest/reference/developer-guides/sdk-modifying-flatcar/
We now need to add documentation to https://github.com/kinvolk/flatcar-docs/tree/main/docs/reference/developer-guides on how to host that image and use flatcar-install to update existing installations.
Updated the issue accordingly to reflect progress.

I think the last remaining items is done here: https://www.flatcar.org/docs/latest/installing/bare-metal/installing-to-disk/. @pothos OK to close this issue ?

The item I wanted to address is now done with
https://www.flatcar.org/docs/latest/installing/customizing-the-image/customize-the-image/
(this wasn't about building from source but customizing a release image).
The follow up about using it with flatcar-install is a minor issue and it's half documented as @tormath1 showed.
Yes, ok to close.


Ensure we clean up asgi fetch_data_in task on cancellation MOD-3537

Superficially, this should prevent the Task was destroyed but it is pending! warnings that get printed frequently for asgi apps shutting down.
In addition this would also remove some unnecessary gcpc streams from zombie fetch_data_in tasks running in asgi containers with cancelled inputs (specifically for inputs that get cancelled at the same time that they are scheduled to receive their first asgi payload)

@prbot approve


NullreferenceException in WaveIn.cs RaiseDataAvailible

Sometimes Naudio stops working when I record something, raising a NullreferenceException in WaveIn's RaiseDataAvailible function becuase it does not check wether the passed Argument is null. To fix this one only needs to add a null check, as I did in the pull request.

not sure exactly what you mean here. buffer has already been checked for null before RaiseDataAvailable is called. Also, which pull request are you referring to?


Using foreign key relationships for view

Hi,
I'm trying to create a view and query it using postgREST but when I do it seems that all FK relationships are not there (fair enough). Is there a way to tell postgREST to look at the original table's FKs? Is there anyway to get around this?
The message I see is the following:
{
details: "no relation between <table> and <my_view>",
message: "could not find foreign keys between these entities"
}

Thank you!
Matias

@matias-piin please post the "CREATE" statements of all the tables and view related to this request and also the url you are trying to request.

Thanks for the quick reply, sorry it took so long to get back to you but im running into a problem while trying to simplify and reproduce this issue. I'm trying to create a simple case using a book and author table as this but I can't even get the basic relationships (without even a view) working now. Could you take a look and see if I'm doing something wrong? Thank you!
SQL Query:
CREATE TABLE book
(
book_id serial primary key,
name varchar(255)
);

CREATE TABLE author
(
author_id serial primary key,
book_id serial not null references book(book_id),
name varchar(255)
);

INSERT INTO book VALUES (1, 'My Book');
INSERT INTO author VALUES (1, 1, 'John Cook');

GRANT ALL ON TABLE book TO webapp;
GRANT ALL ON TABLE author TO webapp;

In this case if I use the following query: /book?book_id=eq.1&select=book_id,name,author{*}
I get this result:
{
details: "no relation between author and book",
message: "could not find foreign keys between these entities"
}

I created your schema locally and it worked for me actually. Can you tell me the command line arguments you used when starting postgrest?

@begriffs Thanks so much for your reply. I actually had not restarted my docker service for postgREST after creating my view and that ended up being the problem. It is now working as intended :)
On a small side note, if I have a column that contains JSON (geoJSON specifically) can I have postgREST treat this as JSON and not return it as just a string?
Thanks for all the help!

That's right, PostgREST loads table relationships on startup because it's kind of a slow query. Might be nice to have it listen for SIGHUP or and reload the relationships to avoid any downtime from a restart. Well that's another issue.
For your other question try casting the column type like this
/foo?select=bar::json

Let me know if that works.

Makes sense, I guess since I could query the table without restarting I was just assuming that postgREST was picking up all my changes.
The casting worked great!
Thanks for all the help!!! I'm really liking this tool :)

Awesome!
Don't forget to join the project chat room if you haven't already. Lots of helpful people there. https://gitter.im/begriffs/postgrest


Core dumped when computing the geodesic distance of a mesh of 2323 vertices

🐛 Bug
I get a core dumped error when trying to compute the geodesic distance of a mesh of 2323 vertices
To Reproduce
I have created a colab notebook with the piece of code to reproduce the error. In colab the error is not displayed(it just crash the notebook), however, if you run the same piece of code locally you will be able to see the details of the error. In this link you will find the notebook and the mesh used for the testing.
malloc(): corrupted top size
Aborted (core dumped)

Expected behavior
Be able to compute the geodesic distance matrix over a mesh.
Environment

OS: 20
Python version: 3.8.10
PyTorch version:  1.9.0
CUDA/cuDNN version: 11.1/ 8.0.5
GCC version: 9.3
Any other relevant information: I have been using the last version of gdist installed from here and from the pip repositories. In addition I have tried to do the same that is explained in the documentation: pip install cython && pip install gdist

Thanks for letting me know. For geodesic distance computation, we make use of the gdist package. I'm not sure why the geodesic distance computation fails for this particular mesh, so I think it's best to ask for advice from the official authors of the package.

Hmm, I'll try to prepare an script using directly their API and then I will create an issue in their repository.

I have created a small test with the gdist API and opened an issue in the official repository.