Adapt the heartbeat checker to the configuration.

the configuration. In case a heartbeat less than 20 seconds the client could raise missing heart beat. In some case could disconnect the client

I experienced some disconnections due to heartbeat without reconnection, I didn't think it was given by this.

That is my fault.  I interpreted the missing heartbeat as a correct closure, but it is not.
We need to do the same I did here: https://github.com/rabbitmq/rabbitmq-stream-dotnet-client/pull/394
maybe in another PR


Is it possible to inlcude another file from markdown file via plugin?

Something like this:
file a.md:
this is a.md
#include "b.md"

file b.md:
this is b.md

And produce:
this is a.md
this is b.md

No.
I don't know why you would want this, but chances are using some templating system (at the html level) will solve your issue here.

If you need async file load, here is generic advice https://github.com/markdown-it/markdown-it/blob/master/docs/development.md#i-need-async-rule-how-to-do-it.
In general - yes, it's possible, but nobody yet did it and we have no plans to write such plugin ourself.

@hh9527 I think my plugin can be what you are looking for https://github.com/camelaissani/markdown-it-include

@camelaissani unfortunately your plugin doesn't work in browser environment.


Estimator.create_predictor triggers RuntimeError with DeepAREstimator

Description
When trying to adapt the custom callback as described at https://ts.gluon.ai/master/tutorials/mxnet_models/trainer_callbacks.html to DeepAREstimator, I get a RuntimeError.
I guess this is not exactly a bug, as there must be additional steps to have DeepAREstimator properly initialized so that create_predictor is happy, but I can't figure out what those are.
To Reproduce
The following gist features a reproducible example (up to refreshing wrt recent API evolutions): https://gist.github.com/pbruneau/51a57ab799bb95651cbaa58d1d6e9bb6. As it is, with the SimpleFeedForwardEstimator block, it runs as expected. But commenting it out, and uncommenting the DeepAREstimator block, one gets a RuntimeError.
Error message or code output
Traceback (most recent call last):
  File "create_predictor_error.py", line 167, in <module>
    predictor = estimator.create_predictor(transformation=transformation, trained_network=training_network)
  File "/opt/conda/envs/rapids/lib/python3.7/site-packages/gluonts/model/deepar/_estimator.py", line 483, in create_predictor
    copy_parameters(trained_network, prediction_network)
  File "/opt/conda/envs/rapids/lib/python3.7/site-packages/gluonts/mx/util.py", line 115, in copy_parameters
    net_source.save_parameters(model_dir_path)
  File "/opt/conda/envs/rapids/lib/python3.7/site-packages/mxnet/gluon/block.py", line 449, in save_parameters
    arg_dict = {key: val._reduce() for key, val in params.items()}
  File "/opt/conda/envs/rapids/lib/python3.7/site-packages/mxnet/gluon/block.py", line 449, in <dictcomp>
    arg_dict = {key: val._reduce() for key, val in params.items()}
  File "/opt/conda/envs/rapids/lib/python3.7/site-packages/mxnet/gluon/parameter.py", line 391, in _reduce
    block = self.list_data()
  File "/opt/conda/envs/rapids/lib/python3.7/site-packages/mxnet/gluon/parameter.py", line 589, in list_data
    return self._check_and_get(self._data, list)
  File "/opt/conda/envs/rapids/lib/python3.7/site-packages/mxnet/gluon/parameter.py", line 241, in _check_and_get
    "nested child Blocks"%(self.name))
RuntimeError: Parameter 'deepartrainingnetwork0_None_distr_mu_weight' has not been initialized. Note that you should initialize parameters and create Trainer with Block.collect_params() instead of Block.params because the later does not include Parameters of nested child Blocks

Environment

Operating system: Ubuntu 18.04
Python version: 3.7.10
GluonTS version: 0.8.1
MXNet version: 1.8.0
CUDA version: 11.0

In the meantime I found a way (see https://gist.github.com/pbruneau/04c0dce4bdfb66ffac3f554f1b98c706)
Basically:

Now I'm passing in the estimator at callback instantiation
I'm using the create_predictor() of the resulting self.estimator along with the training_network obtained along the on_epoch_end call to create the predictor used in the callback

I have the impression it works as expected, but I'm waiting for the feedback from someone knowledgeable of the gluonts internals, as my way may interfere with those internals.

This worked for me as well.

This also works for me. It makes sense to pass estimator to the call back initiation.


Pugged ArgumentsDict into RANS2P_IB

Mandatory Checklist
Please ensure that the following criteria are met:

[ ] Title of pull request describes the changes/features
[ ] Request at least 2 reviewers
[ ] If new files are being added, the files are no larger than 100kB. Post the file sizes.
[ ] Code coverage did not decrease. If this is a bug fix, a test should cover that bug fix. If a new feature is added, a test should be made to cover that feature.
[ ] New features have appropriate documentation strings (readable by sphinx)
[ ] Contributor has read and agreed with CONTRIBUTING.md and has added themselves to CONTRIBUTORS.md

As a general rule of thumb, try to follow PEP8 guidelines.
Description

The method calculateForce and calculateVelocityAverage are never called in the Python file.


System.ArgumentNullException.ThrowIfNull(...); is not available for .NET Framework or .NET Standard

Since .NET Framework is still (unfortunately) supported, this functionality is needed.
In my case, I'm writing a source generator that supports .NET Standard 2.0 and this cannot be used.

Please try v0.27.0-rc.57
It also handles CS8370

Error CS8370 : Feature 'nullable reference types' is not available in C# 7.3. Please use language version 8.0 or greater.

Thanks for all the work (seems like a lot).
Unfortunately this didn't fix it, ArgumentNullException.ThrowIfNull still gets generated.
You can actually try uncommenting these two lines in my project and removing the generated code to see what's going on.

It works. Try to restart your IDE.

You're right, It does work.

v0.27.0 was released.
Also struct union type generation for netstandard2.0 was fixed.


format private def nicely

private def foo
end

currently formats as
private(
  def foo
  end
)

we should format it the first way

@phiggins @sgrif would one of you two like to take this one?

I can't build the project locally, so I'll likely be focusing any open source time on that for the near future.

A method definition immediately preceded by private should get special formatting, or is this any method call on the same line as and immediately preceding a method definition gets special formatting? I don't know how common of a pattern this is (I'm not sure I've ever seen it in code), but you could do something like this as well:
pete@hexagon:~/projects/rubyfmt$ cat example.rb
class Foo
  private

  def foo_private
    :foo_private
  end

  public def foo_public
    :foo_public
  end
end

p Foo.new.foo_public
pete@hexagon:~/projects/rubyfmt$ ruby example.rb
:foo_public

I'd actually argue against fixing this, or fixing it by changing the method definition to be the more standard form in Ruby. This is a super uncommon pattern (mostly only ever seen in code bases ported from Java in my experience), and I'm not sure it makes sense for a "one right unconfigurable way to format code" formatter to do this. Ideally we'd just group the method definitions up by visibility, but if there's code executing between the method definitions that could technically change the semantics
If we insist on special casing this, I think the rule for the special formatting should be "any call to a method named public, private, or protected, taking a single argument" (This would change public(:foo) to public :foo as well, which I think we should do if we're changing public def foo; end as well)

I think I'd actually like the rule to be: any method call where it has exactly one argument, which is a def or defs (e.g. def self.foo), we format it like this.
Because of e.g. the memoist thing: https://github.com/penelopezone/rubyfmt/blob/trunk/fixtures/small/memoist_actual.rb#L4

I have a WIP branch here that almost works but there's a trailing newline after the method def that I can't get rid of, e.g.:
class Foo
  private def bar
    42
  end

end


Can you please upload an image to docker hub

Building from your dockerfile in the latest docker toolkit fails because of this [https://github.com/docker/docker/issues/18180] issue.

don't worry - i was able to upgrade my boot2docker iso.


Dashboard does not URL encode router or service names

I have a router named fabric:/FooBar/Blah@file. It has invalid URL characters in it. Slashes, etc. Traefik is perfectly happy dealing with this router. It is in a healthy state. Works great.
However, the dashboard UI links to an incorrect URL: http://localhost:19188/dashboard/#/http/routers/fabric:/FooBar/Blah@file. The slashes and colon messes it up. If I manually encode the URL, the dashboard page comes back correctly. However, it fails then to call some APIs for the same reason.
Service and Router names should be URL encoded by the dashboard frontend before issuing requests or generating links.
This occurs in version 2.2.0.

Hi! I'm Træfiker :robot: the bot in charge of communication regulation.
Thanks for your interest in Traefik!
Issue templates help us help you by providing all necessary information.
Please edit your issue and use the available templates:

Feature request
Bug report

And remember: each time someone ignores the template, a cute little bunny dies.

#SaveTheCuteBunny :heart: :rabbit: :heart:

Hi! I'm Træfiker :robot: the bot in charge of tidying up the issues.
I have to close this one because of its lack of activity :disappointed:
Feel free to re-open it or join our Community Forum.


feat(ui): FLUX in linear UI

Summary
Adds support in linear UI for using FLUX as a main model for text-to-image, image-to-image, inpainting, and outpainting.
Does NOT include: LoRA support, controlnet support, IP adapter support, or upscaling. This means the only available layers on the canvas included in this PR are inpainting and raster layers. Support for the rest will be in subsequent PRs as the back-end is built out.
Related Issues / Discussions

QA Instructions
Options for FLUX generation settings:

Merge Plan

Checklist

[ ] The PR has a short but descriptive title, suitable for a changelog
[ ] Tests added / updated (if applicable)
[ ] Documentation added / updated (if applicable)

The node user interface is not quite self-explanatory for basic users, it would be great if FLUX models could be used like all the other models via the basic ‘text to image’ user interface. Is this a big challenge to adapt Invoke AI to make this possible or can we expect such a functionality to be available in the future?

The node user interface is not quite self-explanatory for basic users, it would be great if FLUX models could be used like all the other models via the basic ‘text to image’ user interface. Is this a big challenge to adapt Invoke AI to make this possible or can we expect such a functionality to be available in the future?

That is what this PR is doing 👍

When switching to Flux from SDXL, bounding box can get put into a state that is whack/breaks - It's also strange to have the bounding box change sizes when canvas mode is selected.


Send access_token in header instead of query problem

Sending access token in query param returns status 401 for me.
https://stackoverflow.com/questions/31751441/linkedin-verify-oauth2-access-token-on-server-sidehttps://stackoverflow.com/questions/28094926/linkedin-oauth2-unable-to-verify-access-token
Sending in header works for me.
Note: I am using an access token acquired from mobile SDK

Coverage decreased (-12.2%) to 87.828% when pulling 6d49f4fd295efacaffde9c477c886976ae9f7a2d on freework-gmbh:master into ceb63460b8b45b7e00766ae3a4c3e361d76c6ffc on emorikawa:master.

Coverage decreased (-12.5%) to 87.453% when pulling 8025beabffadd6d69c265a839d805ad37e75b16b on freework-gmbh:master into ceb63460b8b45b7e00766ae3a4c3e361d76c6ffc on emorikawa:master.

Coverage decreased (-12.2%) to 87.828% when pulling 9f9a48b36208e11481cc368b5ceca51b8178f27d on freework-gmbh:master into ceb63460b8b45b7e00766ae3a4c3e361d76c6ffc on emorikawa:master.

Coverage decreased (-12.2%) to 87.828% when pulling 876206861d5005a2a654530f3888b1a4d121ecb8 on freework-gmbh:master into ceb63460b8b45b7e00766ae3a4c3e361d76c6ffc on emorikawa:master.


Fix: A workaround to avoid AccessViolationException

Resolved / Related Issues

[X] Were these changes approved in an issue or discussion with the project maintainers? In order to prevent extra work, feature requests and changes to the codebase must be approved before the pull request will be reviewed. This prevents extra work for the contributors and maintainers.
Closes #12078

Validation
How did you test these changes?

[X] Did you build the app and test your changes?
[ ] Did you check for accessibility? You can use Accessibility Insights for this.
[ ] Did you remove any strings from the en-us resource file?

[ ] Did you search the solution to see if the string is still being used?

[ ] Did you implement any design changes to an existing feature?

[ ] Was this change approved?

[ ] Are there any other steps that were used to validate these changes?

Thank you!


render of "term" failed:

render of "term" failed: "zzo/layouts/_default/rss.xml:86:19": execute of template failed: template: _default/rss.xml:86:19: executing "_default/rss.xml" at <.>: range can't iterate over draft

I can't help you with this information


Update output for bulk executor changes

Under JC 1.2 we now support bulk executor api. This change updates the output documentation page.

@chetanmsft : Thanks for your contribution! The author, @mamccrea, has been notified to review your proposed change.

#sign-off

@rjagiewich : Thanks for your contribution! The author, @mamccrea, has been notified to review your proposed change.

@rjagiewich - can we please revert these changes?


pip install failed on Ubuntu 22.04.2 LTS / Debian 12.0

Since the 0.1.10 release I'm having installs failing when running pip3 install. Initial failures were on a Ubuntu 22.04.2 LTS box, with Python 3.10.6 / pip3 23.1.2 installed within a venv configuration. I've since replicated it on Debian 12 with Python 3.11.2 and Kali 2023.2 also with Python 3.11.2 / pip3 23.0.1. The build will fail both within a venv as well as with an user install with the following trace:
$ python3 -m venv test
$ source test/bin/activate

┌──(test)
└─$ pip3 install binary2strings
Collecting binary2strings
  Downloading binary2strings-0.1.10.tar.gz (9.3 kB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Installing backend dependencies ... done
  Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: binary2strings
  Building wheel for binary2strings (pyproject.toml) ... error
  error: subprocess-exited-with-error

  × Building wheel for binary2strings (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [14 lines of output]
      running bdist_wheel
      running build
      running build_ext
      x86_64-linux-gnu-gcc -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -fPIC -I/home/rokkr/Scripts/test-binary-strings/test/include -I/usr/include/python3.11 -c flagcheck.cpp -o flagcheck.o -std=c++17
      building 'binary2strings' extension
      creating build
      creating build/temp.linux-x86_64-cpython-311
      creating build/temp.linux-x86_64-cpython-311/src
      x86_64-linux-gnu-gcc -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -fPIC -DVERSION_INFO=0.1.10 -Isrc -I/tmp/pip-build-env-fv5_42_5/overlay/lib/python3.11/site-packages/pybind11/include -I/home/rokkr/Scripts/test-binary-strings/test/include -I/usr/include/python3.11 -c src/binary2strings.cpp -o build/temp.linux-x86_64-cpython-311/src/binary2strings.o -std=c++17 -fvisibility=hidden -g0
      src/binary2strings.cpp:1:10: fatal error: binary2strings.hpp: No such file or directory
          1 | #include "binary2strings.hpp"
            |          ^~~~~~~~~~~~~~~~~~~~
      compilation terminated.
      error: command '/usr/bin/x86_64-linux-gnu-gcc' failed with exit code 1
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for binary2strings
Failed to build binary2strings
ERROR: Could not build wheels for binary2strings, which is required to install pyproject.toml-based projects

Thanks, working on it.

I had some time to do a little more digging. The root cause seems to be that the source tarball pip install tries to pull from is missing the .hpp files.
I tested building the release manually with python3 setup.py sdist and in my first test this package was then installed successfully and contained all the files needed in the /src directory. Python 3.112, setuptools 66.1.1, and pybind11 2.11.1 were on that system.
On a different VM I tried to replicate the process, but that time generating the release didn't include the .hpp files in the src. For that I had Python 3.10.6, setuptools 67.8.0, and pybind11 2.1.1. Trying to use Python3.11 on that machine still resulted in not copying over the .hpp files, so I may be missing some useful information about the configurations for you.

I suspect is it the change I made to setup.py here:
https://github.com/glmcdona/binary2strings/commit/2c812c2deda5b9540328c0b06e9d99041840b18a
I removed that line of code because a warning message indicated that headers was unrecognized, but maybe it actually was being used. I'll rebuild with reverting that change to see if that fixes it.

That didn't fix the issue, looking at it closer now.

Fixed. Had to add a MANIFEST.in to include the .hpp files in the distribution. ChatGPT-4 was a lifesaver here, pointed out the issue right away <3.

Confirming that fixed it in my builds as well, thanks!


Missing start script

We need a package.json script to start the application locally.

nvm for a SDK it does not make sense 👍🏻


Create uninstall script

Hello, it would be nice to have an uninstall script to automate the uninstall process specified here: https://github.com/jmorganca/ollama/blob/main/docs/linux.md#uninstall adding a PR to this issue with something i made that I'd like to contribute.
Happy Holidays! :)

It would be very nice to be able to upgrade ollama without removing all of the pulled models.  Thanks.

Please, and make it work for Mac as well, I don't see any instructions on how to uninstall on Macs in the docs at the moment!
Trying to do a clean uninstall to re-install it later, but it's not trivial how to do it considering it deals with services, docker, etc.

Hello, it would be nice to have an uninstall script to automate the uninstall process specified here: https://github.com/jmorganca/ollama/blob/main/docs/linux.md#uninstall adding a PR to this issue with something i made that I'd like to contribute.
Happy Holidays! :)

Is there a similar solution for windows? seems like some files remain forever

+1 . IMO its unacceptable that ollama does not have clear documentation on a) dependencies it installs b) clean uninstallation and something that should be prioritized.
@jmorganca , requested the same in discord a few weeks ago.

https://github.com/ollama/ollama/blob/main/docs/linux.md also seems to fail to mention that Ollama leaves a huge amount of storage (i.e. ~8gigs) in /usr/local/lib/ollama/. Shouldn't that be mentioned in the uninstall instructions...?


Is it possible to synchronize via Windows with SyncFTP?

Hi I have several devices under Mac I have got SyncFTP running. Now I wanted to set it up on Windows. But here I get error messages.  What do I have to do to be able to synchronize with SFTP under Windows?

What errors are you receiving? I tested on Mac and Windows Obsidian versions so there's a chance it's the SFTP config.

Also are they both pointing to the same SFTP?

@rtulke Just wanted to follow up with this issue.

Sorry for late response  here a screenshot

Yes both connections windows/Mac with same credentials and connection settings

i have same message

Thanks for your plugin.
I have the same issue.

(The connection and uploading with filezilla works,)

Having the same problem, except I'm running Arch linux.

Error: connect->getConnection: Timed out while waiting for handshake
Failed to connect to SFTP: TypeERror: fileObjects not iterable
Does this mean my credentials are correct, or not?

To y'all, it's a bug, and there's a lot in his code, he will not fix it i think


[Questions] stat not found

Is this originally right?

It's look like that there is typo error in STAT, STATUS, STATE.
Originally, STATUS means server status, and STATE means voice client state (ex queue, playing source, options).
I will fix it, thanks for reporting.

Okay, thank for @kijk2869


Add Country Gangrel clan variant

@oraum Is there any way to get linebreaks into the clan description? \n doesn't seem to work.

@oraum Is there any way to get linebreaks into the clan description? \n doesn't seem to work.

should work now with latest master version


Build error on Android with NS 4.1

NS Core project - using 4.1.
Getting the following error during build
`Unable to apply changes on device: emulator-5554. Error is: Failed to build plugin nativescript-google-maps-sdk :
Error: Command ./gradlew failed with exit code 1 Error output:
FAILURE: Build failed with an exception.

What went wrong:
Could not resolve all files for configuration ':releaseCompileClasspath'.

Could not find common.jar (android.arch.core:common:1.0.0).
Searched in the following locations:
https://jcenter.bintray.com/android/arch/core/common/1.0.0/common-1.0.0.jar

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

Get more help at https://help.gradle.org

BUILD FAILED in 1s
`
I created a new folder structure
./app/App_Resources/Android/src/main/res/values and added the xml file there with the api key.
In the above, I had the create the src/main/res/values folder - wasn't there before.
I also added the meta entry to AndroidManifest.xml file.
The demo program seems to store the xml file in Android/src/main/assets folder - not sure which is correct.
Also getting this error message
No manifest found in /Users/asrock/Documents/test/app/App_Resources/Android/src/main/AndroidManifest.xml

No...but I did find out that NS 4 or 4.1 and above - the folder structure below Android is different.
so I have app/App_Resources/Android/src/main/res and have all the drawables etc there.
in Android/src/main have AndroidManifest.xml

This is how mine is structured as well.  When I followed the install for NativeScript > 4, the cp command created the Android/src/.... file. I moved my AndroidManifest.xml in there. It didn't change the error. -- i just dont see the "couldnt find manifest" error pop up before the "FAILURE"
I thought I could use some react answers to help, and found people adding this to their build.gradle. SO i added it to my Android/app.gradle. No dice.
maven {
  url "https://maven.google.com"
}

^mine. I have NS 4+. hm.

I think you need to move all your drawables under res also.
Basically only 2 items under src/main should be AndroidManifest.xml and res folder.
The url it's looking for
https://jcenter.bintray.com/android/arch/core/common/1.0.0/common-1.0.0.jar
Seems to be unavailable when I check using a browser.
So maybe they're doing some maintenance or something.

The folder /1.0.0 contains a .pom file instead of a .jar file.
Folder /1.1.1 does contain a common-1.1.1.jar file.
I believe a .pom file is a maven makefile...
Hopefully someone in the know will chime in...I'm stumped.

me, too. did you try changing the .pom to .jar?
I tried adding the maven to platform/Android/build.gradle, too-- and I read on SO that doing this updates the play-services versions-- so I tried manually updating those from 11.2.0 to 11.3.0:
project.ext {
googlePlayServicesVersion = "11.3.0"
}
no dice

I believe google-play-services version numbers are a single number - right now 49 is the latest.
I've got 46 installed because 49 has other dependencies.

no, it's three. It actually appears they just released 15.0.0
https://developers.google.com/android/guides/releases

When I go here: https://jcenter.bintray.com/ ... looking for  https://jcenter.bintray.com/android/arch/core/common/1.0.0/common-1.0.0.jar... I come up empty handed.
Where can we change the url listed above? I think if we find WHERE the common.jar file is...and change the code that points the plugin to the wrong url listed above...we'll be set.
or not. Oh, debugging, how I love you.

In the sdk manager - it says version 46.
Do you know what that equates to in the other version system.
Are you using version 49??
I doubt that'll fix it - but I'll try it.

I just reverted my tns version to 3.4.2....and it works for me now.

This plugin doesn't seem to be compatible with<EMAIL_ADDRESS>- works with<EMAIL_ADDRESS>Of course 4.1.2 critical bug in web view.
I guess back to 3.4.3.
One step forward - two steps back.

For what it's worth, I'm seeing the same error.  I've tried updating all the items in the SDK manager, but no luck.

Hmm, this plugin works just fine on my other laptop with 4.2.* tns-android, but has this error on another one with a fresh setup. Probably due to some issue with the SDK or Play Services version. Maybe this info helps diagnose.

@FranciZ did you mean tns-android 4.1.2.
Would you mind posting a screenshot of your android sdk manager -showing the installed modules.

tns-android version:
"tns-android": {
      "version": "4.2.0-2018-06-06-01"
    }

That 4.2.0 version - is that android@next  or android@rc
I believe 4.1.2 is the latest official release.

Happens also to me.
@FranciZ - I did it, the error still happening on my side...
The weird issue is that on other Mac that configured the same as mine with the same project it doesn't happens.

I tried<EMAIL_ADDRESS>- same error message.

I've read that if you use maven your play version gets updated. As such, while using 4.1,  I tried several play service versions (I manage this in my app.gradle file)-- Is there a different way to test play services versions?
I hope the thread at least helps some folks.

+1
@dapriett - any ideas here?

I know it builds on<EMAIL_ADDRESS>and fails with<EMAIL_ADDRESS>- so that should narrow it down - whoever is responsible for tns-android. It doesn't seems to be an issue with this plugin but with tns-android.
I'll take this bug report over there.

So, how can I fix this?
 tns info
✔ Getting NativeScript components versions information...
⚠ Update available for component nativescript. Your current version is 4.0.0 and the latest available version is 4.1.0.
⚠ Update available for component tns-core-modules. Your current version is 4.0.0 and the latest available version is 4.1.0.
⚠ Update available for component tns-android. Your current version is 4.0.1 and the latest available version is 4.1.2.

You should not be running into this problem with your version.
I believe you can install 4.0.1 of NS, TNS-CORE and ANDROID and this plug-in will be built successfully.
I just did it this morning.

Same problem here in a brand new Sidekick project on NS 4.1. As soon as I added nativescript-google-maps-sdk plugin, the project stopped building.

sorry but it's happening, I did a tns update and re ran the script and this is the full output.
Successfully prepared plugin tns-core-modules-widgets for android.
Unable to apply changes on device: emulator-5554. Error is: Failed to build plugin nativescript-google-maps-sdk :
Error: Command ./gradlew failed with exit code 1 Error output:

FAILURE: Build failed with an exception.

* What went wrong:
Could not resolve all files for configuration ':releaseCompileClasspath'.
> Could not find runtime.jar (android.arch.lifecycle:runtime:1.0.0).
  Searched in the following locations:
      https://jcenter.bintray.com/android/arch/lifecycle/runtime/1.0.0/runtime-1.0.0.jar
> Could not find common.jar (android.arch.core:common:1.0.0).
  Searched in the following locations:
      https://jcenter.bintray.com/android/arch/core/common/1.0.0/common-1.0.0.jar

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 1m 17s
.
Executing after-watch hook from /home/hackerunet/Projects/flamingo-ice/hooks/after-watch/nativescript-dev-sass.js
Stopping nativescript-dev-sass watcher

Updated the environment already
✔ Getting NativeScript components versions information...
✔ Component nativescript has 4.1.0 version and is up to date.
✔ Component tns-core-modules has 4.1.0 version and is up to date.
⚠ Update available for component tns-android. Your current version is 4.0.1 and the latest available version is 4.1.2.
✖ Component tns-ios is not installed.

Please read my earlier comments - it DOES happen with 4.1.0 but doesn't with 4.0.1

@erjdriver ok, downgrading then... again.

Looks like NS 4.1 is going to a new folder structure - but it seems to be compatible.
I would recommend 4.0.x only if your app does NOT use webview - 4.1.2 I think fixes a critical bug that's not in 4.0.x.
If your app uses webview - I would downgrade to<EMAIL_ADDRESS>

Just downgraded to 4.0.1 I'm not using webview at all, and still failed.
Successfully prepared plugin tns-core-modules-widgets for android.
Unable to apply changes on device: emulator-5554. Error is: Failed to build plugin nativescript-google-maps-sdk :
Error: Command ./gradlew failed with exit code 1 Error output:

FAILURE: Build failed with an exception.

* What went wrong:
Could not resolve all files for configuration ':releaseCompileClasspath'.
> Could not find common.jar (android.arch.core:common:1.0.0).
  Searched in the following locations:
      https://jcenter.bintray.com/android/arch/core/common/1.0.0/common-1.0.0.jar

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

* Get more help at https://help.gradle.org

BUILD FAILED in 1s

I think the plugin would got obsolete because main dependencies repositories maybe doesn't longer exists or it should be updated, the jcenter.bintray.com common-1.0.0.jar doesn't exist, so maybe we need to map this repository to another resource. how can I achieve that?

@erjdriver This is the current repository where the missing file is, https://mvnrepository.com/artifact/android.arch.core/common/1.1.0 so how can I update the plugin to look in that place instead of it's current resources?

@hackerunet is right, to get common-1.0.0.jar the plugin should no longer point to jcenter

To avoid some possible confusion and possibly help, I'll chime in that I'm not experiencing this issue on an older project after migrating it to 4.1.0, because I don't believe that project was converted to the new directory structure some of you are mentioning.
tns --version 4.1.0
"nativescript-google-maps-sdk": "^2.6.0"
dir structure under app/App_Resources/Android for project that was created before 4.1.0
.
├── AndroidManifest.xml
├── app.gradle
├── drawable-hdpi
│   ├── animals.png
│   ├── background.png
│   ├── icon.png
│   └── logo.png
├── drawable-ldpi
│   ├── animals.png
│   ├── background.png
│   ├── icon.png
│   └── logo.png
├── drawable-mdpi
│   ├── animals.png
│   ├── background.png
│   ├── icon.png
│   └── logo.png
├── drawable-nodpi
│   ├── animals.png
│   └── splash_screen.xml
├── drawable-xhdpi
│   ├── animals.png
│   ├── background.png
│   ├── icon.png
│   └── logo.png
├── drawable-xxhdpi
│   ├── animals.png
│   ├── background.png
│   ├── icon.png
│   └── logo.png
├── drawable-xxxhdpi
│   ├── animals.png
│   ├── background.png
│   ├── icon.png
│   └── logo.png
├── values
│   ├── colors.xml
│   ├── nativescript_google_maps_api.xml
│   └── styles.xml
└── values-v21
    ├── colors.xml
    └── styles.xml

Then in AndroidManifest.xml I have:
<meta-data
            android:name="com.google.android.geo.API_KEY"
            android:value="@string/nativescript_google_maps_api_key" />

and in nativescript_google_maps_api.xml
<?xml version="1.0" encoding="utf-8"?>
<resources>
     <string name="nativescript_google_maps_api_key">mike</string>
</resources>

However when I create a new project under 4.1.0 I do see this new directory structure:
.
├── app.gradle
└── src
    └── main
        ├── AndroidManifest.xml
        └── res
            ├── drawable-hdpi
            │   ├── background.png
            │   ├── icon.png
            │   └── logo.png
            ├── drawable-ldpi
            │   ├── background.png
            │   ├── icon.png
            │   └── logo.png
            ├── drawable-mdpi
            │   ├── background.png
            │   ├── icon.png
            │   └── logo.png
            ├── drawable-nodpi
            │   └── splash_screen.xml
            ├── drawable-xhdpi
            │   ├── background.png
            │   ├── icon.png
            │   └── logo.png
            ├── drawable-xxhdpi
            │   ├── background.png
            │   ├── icon.png
            │   └── logo.png
            ├── drawable-xxxhdpi
            │   ├── background.png
            │   ├── icon.png
            │   └── logo.png
            ├── values
            │   ├── colors.xml
            │   └── styles.xml
            └── values-v21
                ├── colors.xml
                └── styles.xml

Not sure why or when this src/main was introduced.

Hey all - don't believe there is a fix needed for this plugin, but for nativescript-android.  Once this pull request gets released, you should be good to go.
https://github.com/NativeScript/android-runtime/pull/1070
Looks like there is another issue opened in their repo, with a possible workaround: https://github.com/NativeScript/android-runtime/issues/1081

I got my 4.1 system building on Android following @dapriett 's links.  Some things to know:
To follow the instructions, NativeScript will need to be installed locally (i.e., without sudo).  See this post for more info.
All you need to do is move the reference to jcenter() in build.gradle (NOT in your local app folder), as per the instructions here.
I reset the GooglePlayServices in app.gradle back to what I was using in NS 3.4.x, namely:
// See https://github.com/NativeScript/nativescript-geolocation/issues/108
  project.ext {
    googlePlayServicesVersion = "11.2.+"
  }

With these changes, I can now build and run successfully on Android.  Woo hoo!

ok, I don't have any of my libraries/main functions/languages or any other installed with sudo, in fact in linux envs the installation avoid using sudo, I think I get a warning or something like that, but, anyways nothing is builded using sudo.
Also, I have added project.ext several times and the issue persist.
Also I created my project using NS 4.0.1 when I begun, later on, yesterday I updated my env which does not change my directory structure, I don't have any src/main inside app/App_Resources
so for now I'm goint to read @dapriett comment to see if I can hit the solution, is awfull that including maps in a mobile application is being this hard, it shouldn't be like this and I don't know why globally all languages has the same issues, they all rush up things to release a new feature or new version but programmers don't make efforts to port all features to the new release, there are always bugs somewhere, When I choosed NS to build my project I'd read implementing maps was very straight forward but it is not and is a shame.

Updates, this finally worked!!, there are a couple of solutions that can be implemented

as @dapriett said before -> https://github.com/NativeScript/android-runtime/issues/1081
Wipe out all node_modules, npm cache and platforms, then npm install on application's root directory to install everything again, then add the plugin again and then add the platform again, IT HAS TO BE IN THAT ORDER.
Also the application was able to solve the missing jar but not sure how it did that because the resource: https://jcenter.bintray.com/android/arch/core/common/1.0.0/common-1.0.0.jar
is permanently down, that resource doesn't exist anymore, so there is still something missing around.
I also followed the install instructions for NS < 4 no matter if my application was built on NS 4.0.1
Also my nodejs version is v8.11.2 and NPM 6.0.1
That's it!!

I can confirm the solution here worked.

Just made the change - removed and reinstalled the latest android.
Thanks.

Just upgraded to 4.1.3, removed and readded platform and plugin, and still not building. Is some file hacking still required with 4.1.3?

You need to be extra carefull, is like a surgery procedure, so, remove node_modules, npm cache clean --force then tns plugin add google-maps-sdk, tns platform add android , check you have android runtime prerequisites like api 24+, and other librearies install in the android sdk and of course google play services.

I think patching the global build.gradle file is a working workaround, but I wouldn't call it a solution. I followed up on android-runtime/issues/1081.

This fixed the issue for me:
tns platform remove android
tns platform add android


User can only edit at initial sim state

Problem:
Before, the only way to return to the start of the simulation is to reload it from the server. This forces you to discard any changes you made since you loaded or saved a simulation.
Solution:
Basically, any time the user modifies the simulation, the current state is saved. Then, whenever the user presses the new stop button, it resets back to that last modified state. This is an alternative to the reset button that reloads the sim from the server. Now, the user is not able to edit the simulation unless it is at the initial state.
All of these changes make it more practical for situations where the user has to repeatedly play, stop, and make changes to the simulation.

To test, experiment with the stop button and making modifications between different plays of simulation
Uses engine v0.2.4

User should be able to add notes when simulation is not at initial state. The data within a note is not changed while the sim is running, so it doesn't hurt to allow adding them at any time in the simulation. The simulation should no longer reset notes when stop is pressed.

@benjic do you think this is something we should merge? I'll fix the conflicts if so

Awesome work, @aaroncameron21 !


documentation problem

The README.md description of installing poetry has some small problems, and we have fixed that.

closed by https://github.com/Vandivier/python-hello-web-monorepo/pull/4


Bump controller-gen to v0.12.0

Bump controller-gen to v.0.12.0

This we need to think a bit about. Don't know what have changed between the different versions.
Is there any specific reason you want to do it? Other than it's great to use a newer version :)

This change looks safe to merge.
Looking at: https://github.com/kubernetes-sigs/controller-tools/releases/
The changes in v0.12.0 are mostly dependency updates, and safe.
The change in v0.11.4 to remove creationTimestamp from generated files is a good one to take.

I don't see anything particularly worrying in the changelog since v0.10.0. The Kubernetes libraries  are bumped a few times, but even v0.10.0 is using a version that's ahead of our minimum requirement.


[Enhancement] Fix the Metamask Integration

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Additional context
Add any other context or screenshots about the feature request here.

Hello, @jaibhedia  I am a GSSoC'24 contributor. I want to work on this issue can you please assign it to me. Can you please label the it with level 1, level 2, level 3. You had labeled it with hard, I think it may be fall under level 3. Please assign me I am waiting to contribute to it. Thank you.

@jaibhedia Thank you.


bigquery/language/logging/prediction/vision: decouple packages

After #1529 ships, this does the de-coupling of packages using the new method, common.util.isCustomType()

PTAL.

Coverage remained the same at 100.0% when pulling 2f87aef2b2a8b0bf6f11a35da738c501cbcde85c on stephenplusplus:spp--1467-2 into 137efaeeaa17e820c3da48a61cd120ff6716956d on GoogleCloudPlatform:master.

Coverage remained the same at 100.0% when pulling 2f87aef2b2a8b0bf6f11a35da738c501cbcde85c on stephenplusplus:spp--1467-2 into 137efaeeaa17e820c3da48a61cd120ff6716956d on GoogleCloudPlatform:master.


PNPM workspace: protocol is not removed before publish

Describe the bug
As titled. This broke currently our release process :scream:
lerna publish --conventional-commits --create-release github --allow-branch main --yes --message="chore(release): Publish [skip ci]"

Reproduction

Create PNPM workspace
Use a dependency with workspace: protocol
Publish with lerna.
workspace: is still in the manifest.

Lerna config and logs
lerna.json

<!-- Please paste your `lerna.json` here -->

lerna-debug.log

<!-- If you have a `lerna-debug.log` available, please paste it here -->
<!-- Otherwise, feel free to delete this <details> block -->

Environment Info
| Executable        | Version |
| ----------------- | ------- |
| `lerna --version` | v1.4.0 |
| `npm --version`   | VERSION |
| `yarn --version`  | VERSION |
| `node --version`  | VERSION |

---
OR simply run `npx lerna info` command

Used Package Manager
pnpm
Validations

[X] Follow our Code of Conduct
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion.
[X] The provided reproduction is a minimal reproducible example of the bug.

Unfortunately, I had to switch back to lerna and use https://pnpm.io/workspaces#prefer-workspace-packages for published packages.

It's not supposed to, it worked fine for me with a real pnpm project ts-pnpm-monorepo that I tested with and here's the unpkg.
The PR for workspace: protocol is #148 the process is to call this method from publish command
https://github.com/ghiscoding/lerna-lite/blob/bffcb33677eb6bead47958110c6e2cc09ab8c28d/packages/publish/src/publish-command.ts#L569-L587
which then calls this line
https://github.com/ghiscoding/lerna-lite/blob/bffcb33677eb6bead47958110c6e2cc09ab8c28d/packages/core/src/package.ts#L282-L293
and I have a few unit tests for them as well, so it shouldn't publish at all any of the workspace: and I'm pretty sure there are other users having it in place also.  Did it fail or something? What was sent to unpkg? You didn't provide any sample of those failures

Yes, I'll try to provide more info. It could be also related to the pnpm-lock update after version bump because pnpm usually tries to use the workspace: protocol when updating dependencies.

if that's the case then PR #199 might potentially be problematic then

I don't think so because you are updating the lock after version bump and removing it before publishing right?

I'm not sure the word is really "removing" because technically speaking it's the package graph which is in memory that is simply being modified before publishing.

I'm considering migrating the repo to a pnpm workspace to help with the support of workspace: protocol which is non-existent in npm. At the beginning I used npm so that anyone could contribute and also wanted to try npm workspaces but I'm not so impressed with it and now that I support workspace protocol it's even harder to support. If we do migrate to pnpm then we could use breakpoint directly in the code

After some thought, I think I now why and it's just a theory but if I'm correct then it's because you're calling the shorter 1 liner command (version + publish) which fall in the last condition displayed below which is to create a new VersionCommand() instance
https://github.com/ghiscoding/lerna-lite/blob/bffcb33677eb6bead47958110c6e2cc09ab8c28d/packages/publish/src/publish-command.ts#L182-L190
however, and like I wrote in earlier post, I rely on the command name to know when to keep or remove the workspace: wording in this updateLocalDependency() function call
https://github.com/ghiscoding/lerna-lite/blob/bffcb33677eb6bead47958110c6e2cc09ab8c28d/packages/core/src/package.ts#L250-L258
and the theory is that since it called VersionCommand, then it doesn't remove the workspace: wording because it think it is doing a version not a publish, I know it does the publish later but I'm not sure if it changes back the command name or not and if it doesn't then there's the bug... However like I said this is just a theory and to prove it, I'm adding a lot more helpful info in the next PR to include tarball temp location and package.json content so that we can debug this and provide helpful info to everyone via the git-dry-run flag.
long story short, I'll look into fixing this but for a very likely quick fix you can use the 2 commands split, that is what I always use with Lerna (with extra config in lerna.json) and that is how I tested the workspace protocol, so it looks like I did forget to test the 1 liner version/publish command.
https://github.com/ghiscoding/lerna-lite/blob/bffcb33677eb6bead47958110c6e2cc09ab8c28d/package.json#L19-L20

Thanks for the investigation. I'm going to try it out after the pnpm workspace lock fix.

I gave this a try after merging the other 2 PRs and I can't seem to reproduce, at least not in dry-run mode. The last PR helps a lot by providing more helpful details about the tarball and what versions are being published, I tried with this simple demo
"dependencies": {
    "@lerna-lite/core": "workspace:^1.4.1",
    "@lerna-lite/info": "workspace:^1.4.1",
    "@lerna-lite/init": "workspace:^1.4.1",
    "@lerna-lite/publish": "workspace:*",
    "@lerna-lite/version": "workspace:^"
}

and ran the command you provided, in my use case I needed to turn off the new flags because npm isn't too happy with workspace: protocol but once I turn the lockfile-only thing, it seems to be working as expected
here's the command I ran locally
"dist-roll-publish-dry-run": "node ./packages/cli/dist/cli.js publish --conventional-commits --create-release github --allow-branch main --yes --no-sync-workspace-lock --no-manually-update-root-lockfile --git-dry-run",

and here's the tarball and publish details (again thanks to last PR you'll see a lot more useful info in dry-run mode)
lerna-lite notice === Tarball Details ===
lerna-lite notice name:          @lerna-lite/cli
lerna-lite notice version:       1.4.2
lerna-lite notice filename:      lerna-lite-cli-1.4.2.tgz
lerna-lite notice package size:  14.9 kB
lerna-lite notice unpacked size: 68.2 kB
lerna-lite notice shasum:        10fa5b50f555adc46f2c651e579cda8d04037370
lerna-lite notice integrity:     sha512-0hsvQ+NI0URkX[...]8hS6KLOWh5flA==
lerna-lite notice total files:   39
lerna-lite notice --- dry-run details ---
lerna-lite notice temp location: C:\Users\User\AppData\Local\Temp\16f72185-bd88-499d-89d2-1b5756b00df1\lerna-lite-cli-1.4.2.tgz
lerna-lite notice package name: @lerna-lite/cli
lerna-lite notice dependencies:
lerna-lite notice @lerna-lite/core    | ^1.4.2
lerna-lite notice @lerna-lite/info    | ^1.4.2
lerna-lite notice @lerna-lite/init    | ^1.4.2
lerna-lite notice @lerna-lite/publish | 1.4.2
lerna-lite notice @lerna-lite/version | ^1.4.2
lerna-lite notice dedent              | ^0.7.0
lerna-lite notice dotenv              | ^16.0.1
lerna-lite notice import-local        | ^3.1.0
lerna-lite notice npmlog              | ^6.0.2
lerna-lite notice yargs               | ^17.5.1
lerna-lite notice
lerna-lite info dry-run> git checkout -- package.json packages\cli\package.json packages\core\package.json packages\exec\package.json packages\info\package.json packages\init\package.json packages\list\package.json packages\optional-cmd-common\package.json packages\publish\package.json packages\run\package.json packages\version\package.json
Successfully published:
 -<EMAIL_ADDRESS>
as you can see, workspace: is completely removed and so I can't seem to replicate the issue from my side. Some things to note are that I'm in git-dry-run mode and I merged the last 2 PRS, however I don't think any of these 2 points have any impact on the repro.
Nonetheless, I would still suggest to use the 2 commands split that are lerna version and then later lerna publish, it's easier to follow and probably more predictable.

Hi @ghiscoding today I tried 1.5.0 and could reproduce it again. Here is the output of

pnpm lerna publish --conventional-commits --git-dry-run --sync-workspace-lock

lerna-lite success published @wundergraph/nextjs 0.0.19
lerna-lite notice
lerna-lite notice 📦<EMAIL_ADDRESS>lerna-lite notice === Tarball Contents ===
lerna-lite notice 11.4kB LICENSE
lerna-lite notice 4.0kB  dist/handlebar.template.js
lerna-lite notice 34.5kB dist/index.js
lerna-lite notice 34.1kB dist/lib.js
lerna-lite notice 4.0kB  dist/template.controller.js
lerna-lite notice 4.0kB  dist/template.js
lerna-lite notice 1.3kB  package.json
lerna-lite notice 1.2kB  README.md
lerna-lite notice 4.1kB  dist/handlebar.template.d.ts
lerna-lite notice 10.8kB dist/index.d.ts
lerna-lite notice 10.8kB dist/lib.d.ts
lerna-lite notice 264B   dist/template.controller.d.ts
lerna-lite notice 264B   dist/template.d.ts
lerna-lite notice 70.7kB dist/tsconfig.tsbuildinfo
lerna-lite notice === Tarball Details ===
lerna-lite notice name:          @wundergraph/nextjs
lerna-lite notice version:       0.0.19
lerna-lite notice filename:      wundergraph-nextjs-0.0.19.tgz
lerna-lite notice package size:  40.9 kB
lerna-lite notice unpacked size: 191.5 kB
lerna-lite notice shasum:        121c98149e22684d3a02f06b8b0ac94ed75840ad
lerna-lite notice integrity:     sha512-KancdootLYKPd[...]kOlvT2hS2VGhQ==
lerna-lite notice total files:   14
lerna-lite notice --- dry-run details ---
lerna-lite notice temp location: /tmp/212ba1fb-c274-4b7d-8b4a-669fde2cf36b/wundergraph-nextjs-0.0.19.tgz
lerna-lite notice package name: @wundergraph/nextjs
lerna-lite notice dependencies:
lerna-lite notice @wundergraph/protobuf | ^0.91.1
lerna-lite notice handlebars            | ^4.7.7
lerna-lite notice next                  | ^12.1.6
lerna-lite notice object-hash           | ^2.2.0
lerna-lite notice react-ssr-prepass     | ^1.5.0
lerna-lite notice devDependencies:
lerna-lite notice @types/node        | ^17.0.32
lerna-lite notice @types/object-hash | ^1.3.4
lerna-lite notice @types/react       | ^18.0.5
lerna-lite notice @wundergraph/sdk   | ^0.92.2
lerna-lite notice react              | ^18.1.0
lerna-lite notice react-dom          | ^18.1.0
lerna-lite notice typescript         | ^4.7.2
lerna-lite notice
lerna-lite success published @wundergraph/sdk 0.92.2
lerna-lite notice
lerna-lite notice 📦<EMAIL_ADDRESS>lerna-lite notice === Tarball Contents ===
lerna-lite notice 11.4kB  LICENSE
lerna-lite notice 1.9kB   dist/codegen/templates/markdown/authentication.js
lerna-lite notice 1.8kB   dist/configure/authentication.js
lerna-lite notice 3.8kB   dist/wunderctl/binarypath.js
lerna-lite notice 4.9kB   dist/postman/builder.js
lerna-lite notice 77B     dist/middleware/client.js
lerna-lite notice 9.6kB   dist/graphql/configuration.js
lerna-lite notice 10.8kB  dist/graphql/configuration.test.js
lerna-lite notice 737B    dist/codegen/templates/markdown/configure_auth_providers.template.js
lerna-lite notice 2.1kB   dist/wunderctl/exec.js
lerna-lite notice 1.1kB   dist/graphql/federation.js
lerna-lite notice 3.7kB   dist/codegen/templates/typescript/forms.js
lerna-lite notice 3.9kB   dist/codegen/templates/typescript/forms.tsx.template.js
lerna-lite notice 3.5kB   dist/middleware/plugins/graphql.js
lerna-lite notice 468B    dist/wunderctl/helper.js
lerna-lite notice 2.3kB   dist/codegen/templates/typescript/hooks.js
lerna-lite notice 17.8kB  dist/middleware/plugins/hooks.js
lerna-lite notice 6.5kB   dist/codegen/templates/typescript/hooks.template.js
lerna-lite notice 6.3kB   dist/codegen/index.js
lerna-lite notice 2.5kB   dist/codegen/templates/index.js
lerna-lite notice 9.5kB   dist/codegen/templates/typescript/index.js
lerna-lite notice 42.3kB  dist/configure/index.js
lerna-lite notice 632B    dist/cors/index.js
lerna-lite notice 30.0kB  dist/definition/index.js
lerna-lite notice 1.1kB   dist/dotgraphqlconfig/index.js
lerna-lite notice 591B    dist/env/index.js
lerna-lite notice 5.1kB   dist/index.js
lerna-lite notice 3.3kB   dist/linkbuilder/index.js
lerna-lite notice 660B    dist/strings/index.js
lerna-lite notice 452B    dist/transformations/index.js
lerna-lite notice 47.8kB  dist/v2openapi/index.js
lerna-lite notice 270B    dist/version/index.js
lerna-lite notice 956B    dist/wunderctl/index.js
lerna-lite notice 1.5kB   dist/wunderctlexec/index.js
lerna-lite notice 18.2kB  dist/codegen/index.test.js
lerna-lite notice 2.5kB   dist/codegen/templates/typescript/index.test.js
lerna-lite notice 9.6kB   dist/configure/index.test.js
lerna-lite notice 687B    dist/definition/index.test.js
lerna-lite notice 1.8kB   dist/linkbuilder/index.test.js
lerna-lite notice 10.2kB  dist/transformations/index.test.js
lerna-lite notice 3.6kB   dist/v2openapi/index.test.js
lerna-lite notice 376B    dist/wunderctl/bin/install.js
lerna-lite notice 649B    dist/wunderctl/install.js
lerna-lite notice 3.3kB   dist/wunderctl/installer.js
lerna-lite notice 1.8kB   dist/middleware/internal-client.js
lerna-lite notice 2.2kB   dist/codegen/templates/typescript/internal.client.js
lerna-lite notice 898B    dist/codegen/templates/typescript/internal.client.template.js
lerna-lite notice 15.1kB  dist/db/introspection.js
lerna-lite notice 449B    dist/db/introspection.test.js
lerna-lite notice 1.1kB   dist/codegen/templates/typescript/jsonschema.js
lerna-lite notice 528B    dist/codegen/templates/typescript/jsonschema.template.js
lerna-lite notice 1.5kB   dist/codegen/templates/typescript/linkbuilder.js
lerna-lite notice 2.7kB   dist/codegen/templates/typescript/linkbuilder.template.js
lerna-lite notice 397B    dist/wunderctl/logger.js
lerna-lite notice 19.0kB  dist/definition/merge.js
lerna-lite notice 42.0kB  dist/definition/merge.test.js
lerna-lite notice 19.8kB  dist/definition/namespacing.js
lerna-lite notice 15.6kB  dist/definition/namespacing.test.js
lerna-lite notice 1.3kB   dist/codegen/templates/typescript/operations.js
lerna-lite notice 831B    dist/configure/operations.js
lerna-lite notice 48.3kB  dist/graphql/operations.js
lerna-lite notice 1.2kB   dist/codegen/templates/typescript/operations.template.js
lerna-lite notice 41.6kB  dist/graphql/operations.test.js
lerna-lite notice 10.4kB  dist/codegen/templates/typescript/react.hooks.template.js
lerna-lite notice 5.4kB   dist/codegen/templates/typescript/react.js
lerna-lite notice 4.5kB   dist/codegen/templates/typescript/react.native.provider.template.js
lerna-lite notice 4.1kB   dist/codegen/templates/typescript/react.provider.template.js
lerna-lite notice 3.1kB   dist/graphql/renametypes.js
lerna-lite notice 1.0kB   dist/graphql/renametypes.test.js
lerna-lite notice 241B    dist/wunderctl/bin/run.js
lerna-lite notice 2.1kB   dist/wunderctl/run.js
lerna-lite notice 7.2kB   dist/graphql/schema.js
lerna-lite notice 1.7kB   dist/codegen/templates/typescript/server.js
lerna-lite notice 5.3kB   dist/middleware/server.js
lerna-lite notice 1.3kB   dist/codegen/templates/typescript/server.template.js
lerna-lite notice 246B    dist/wunderctl/bin/uninstall.js
lerna-lite notice 246B    dist/wunderctl/uninstall.js
lerna-lite notice 2.0kB   dist/wunderctl/uninstaller.js
lerna-lite notice 5.1kB   dist/codegen/templates/typescript/web.client.js
lerna-lite notice 16.4kB  dist/codegen/templates/typescript/web.client.template.js
lerna-lite notice 234.4kB dist/generated/protobuf/wundernode_config.js
lerna-lite notice 2.3kB   package.json
lerna-lite notice 1.2kB   README.md
lerna-lite notice 285B    dist/codegen/templates/markdown/authentication.d.ts
lerna-lite notice 1.3kB   dist/configure/authentication.d.ts
lerna-lite notice 212B    dist/wunderctl/binarypath.d.ts
lerna-lite notice 558B    dist/postman/builder.d.ts
lerna-lite notice 2.2kB   dist/middleware/client.d.ts
lerna-lite notice 520B    dist/graphql/configuration.d.ts
lerna-lite notice 11B     dist/graphql/configuration.test.d.ts
lerna-lite notice 636B    dist/codegen/templates/markdown/configure_auth_providers.template.d.ts
lerna-lite notice 62B     dist/wunderctl/exec.d.ts
lerna-lite notice 196B    dist/graphql/federation.d.ts
lerna-lite notice 255B    dist/codegen/templates/typescript/forms.d.ts
lerna-lite notice 3.9kB   dist/codegen/templates/typescript/forms.tsx.template.d.ts
lerna-lite notice 1.0kB   dist/middleware/plugins/graphql.d.ts
lerna-lite notice 56B     dist/wunderctl/helper.d.ts
lerna-lite notice 304B    dist/codegen/templates/typescript/hooks.d.ts
lerna-lite notice 606B    dist/middleware/plugins/hooks.d.ts
lerna-lite notice 6.5kB   dist/codegen/templates/typescript/hooks.template.d.ts
lerna-lite notice 1.7kB   dist/codegen/index.d.ts
lerna-lite notice 2.3kB   dist/codegen/templates/index.d.ts
lerna-lite notice 1.3kB   dist/codegen/templates/typescript/index.d.ts
lerna-lite notice 7.1kB   dist/configure/index.d.ts
lerna-lite notice 146B    dist/cors/index.d.ts
lerna-lite notice 8.4kB   dist/definition/index.d.ts
lerna-lite notice 746B    dist/dotgraphqlconfig/index.d.ts
lerna-lite notice 182B    dist/env/index.d.ts
lerna-lite notice 2.0kB   dist/index.d.ts
lerna-lite notice 1.6kB   dist/linkbuilder/index.d.ts
lerna-lite notice 130B    dist/strings/index.d.ts
lerna-lite notice 348B    dist/transformations/index.d.ts
lerna-lite notice 193B    dist/v2openapi/index.d.ts
lerna-lite notice 39B     dist/version/index.d.ts
lerna-lite notice 161B    dist/wunderctl/index.d.ts
lerna-lite notice 307B    dist/wunderctlexec/index.d.ts
lerna-lite notice 241B    dist/codegen/index.test.d.ts
lerna-lite notice 11B     dist/codegen/templates/typescript/index.test.d.ts
lerna-lite notice 11B     dist/configure/index.test.d.ts
lerna-lite notice 11B     dist/definition/index.test.d.ts
lerna-lite notice 11B     dist/linkbuilder/index.test.d.ts
lerna-lite notice 11B     dist/transformations/index.test.d.ts
lerna-lite notice 11B     dist/v2openapi/index.test.d.ts
lerna-lite notice 64B     dist/wunderctl/bin/install.d.ts
lerna-lite notice 84B     dist/wunderctl/install.d.ts
lerna-lite notice 108B    dist/wunderctl/installer.d.ts
lerna-lite notice 515B    dist/middleware/internal-client.d.ts
lerna-lite notice 310B    dist/codegen/templates/typescript/internal.client.d.ts
lerna-lite notice 811B    dist/codegen/templates/typescript/internal.client.template.d.ts
lerna-lite notice 918B    dist/db/introspection.d.ts
lerna-lite notice 11B     dist/db/introspection.test.d.ts
lerna-lite notice 260B    dist/codegen/templates/typescript/jsonschema.d.ts
lerna-lite notice 438B    dist/codegen/templates/typescript/jsonschema.template.d.ts
lerna-lite notice 271B    dist/codegen/templates/typescript/linkbuilder.d.ts
lerna-lite notice 2.7kB   dist/codegen/templates/typescript/linkbuilder.template.d.ts
lerna-lite notice 72B     dist/wunderctl/logger.d.ts
lerna-lite notice 4.7kB   dist/definition/merge.d.ts
lerna-lite notice 11B     dist/definition/merge.test.d.ts
lerna-lite notice 1.7kB   dist/definition/namespacing.d.ts
lerna-lite notice 11B     dist/definition/namespacing.test.d.ts
lerna-lite notice 260B    dist/codegen/templates/typescript/operations.d.ts
lerna-lite notice 2.9kB   dist/configure/operations.d.ts
lerna-lite notice 3.0kB   dist/graphql/operations.d.ts
lerna-lite notice 1.2kB   dist/codegen/templates/typescript/operations.template.d.ts
lerna-lite notice 11B     dist/graphql/operations.test.d.ts
lerna-lite notice 923B    dist/codegen/templates/typescript/react.d.ts
lerna-lite notice 10.6kB  dist/codegen/templates/typescript/react.hooks.template.d.ts
lerna-lite notice 4.6kB   dist/codegen/templates/typescript/react.native.provider.template.d.ts
lerna-lite notice 4.1kB   dist/codegen/templates/typescript/react.provider.template.d.ts
lerna-lite notice 239B    dist/graphql/renametypes.d.ts
lerna-lite notice 11B     dist/graphql/renametypes.test.d.ts
lerna-lite notice 31B     dist/wunderctl/bin/run.d.ts
lerna-lite notice 60B     dist/wunderctl/run.d.ts
lerna-lite notice 170B    dist/graphql/schema.d.ts
lerna-lite notice 299B    dist/codegen/templates/typescript/server.d.ts
lerna-lite notice 3.6kB   dist/middleware/server.d.ts
lerna-lite notice 1.3kB   dist/codegen/templates/typescript/server.template.d.ts
lerna-lite notice 55B     dist/wunderctl/bin/uninstall.d.ts
lerna-lite notice 55B     dist/wunderctl/uninstall.d.ts
lerna-lite notice 64B     dist/wunderctl/uninstaller.d.ts
lerna-lite notice 1.0kB   dist/codegen/templates/typescript/web.client.d.ts
lerna-lite notice 17.0kB  dist/codegen/templates/typescript/web.client.template.d.ts
lerna-lite notice 198.6kB dist/generated/protobuf/wundernode_config.d.ts
lerna-lite notice 97.7kB  dist/tsconfig.tsbuildinfo
lerna-lite notice === Tarball Details ===
lerna-lite notice name:          @wundergraph/sdk
lerna-lite notice version:       0.92.2
lerna-lite notice filename:      wundergraph-sdk-0.92.2.tgz
lerna-lite notice package size:  180.7 kB
lerna-lite notice unpacked size: 1.2 MB
lerna-lite notice shasum:        78e1f65286be0911eb86ed54f38e003144fae0fa
lerna-lite notice integrity:     sha512-AYgsjGGK78skF[...]huS2AB1oYzazg==
lerna-lite notice total files:   164
lerna-lite notice --- dry-run details ---
lerna-lite notice temp location: /tmp/2a3b259b-1a78-4384-a894-b0929b3df80f/wundergraph-sdk-0.92.2.tgz
lerna-lite notice package name: @wundergraph/sdk
lerna-lite notice dependencies:
lerna-lite notice @apollo/composition       | ^2.0.2
lerna-lite notice @apollo/federation        | ^0.36.2
lerna-lite notice @graphql-tools/schema     | ^8.3.10
lerna-lite notice @prisma/generator-helper  | ^3.9.2
lerna-lite notice @wundergraph/protobuf     | ^0.91.1
lerna-lite notice @wundergraph/wunderctl    | workspace:^0.91.1
lerna-lite notice axios                     | ^0.26.1
lerna-lite notice colors                    | ^1.4.0
lerna-lite notice execa                     | 5.1.1
lerna-lite notice fastify                   | ^3.27.1
lerna-lite notice fastify-graceful-shutdown | ^3.1.0
lerna-lite notice fastify-plugin            | ^3.0.1
lerna-lite notice graphql                   | ^16.3.0
lerna-lite notice graphql-helix             | ^1.12.0
lerna-lite notice handlebars                | ^4.7.7
lerna-lite notice js-yaml                   | ^4.1.0
lerna-lite notice json-schema               | ^0.4.0
lerna-lite notice lodash                    | ^4.17.21
lerna-lite notice long                      | ^5.2.0
lerna-lite notice object-hash               | ^2.2.0
lerna-lite notice openapi-types             | ^10.0.0
lerna-lite notice postman-collection        | ^4.1.1
lerna-lite notice prettier                  | ^2.5.0
lerna-lite notice protobufjs                | ^6.11.2
lerna-lite notice swagger2openapi           | ^7.0.8
lerna-lite notice devDependencies:
lerna-lite notice @types/axios       | ^0.14.0
lerna-lite notice @types/chai        | ^4.2.22
lerna-lite notice @types/colors      | ^1.2.1
lerna-lite notice @types/cors        | ^2.8.10
lerna-lite notice @types/debug       | ^4.1.7
lerna-lite notice @types/jest        | ^28.1.1
lerna-lite notice @types/js-yaml     | ^4.0.0
lerna-lite notice @types/json-schema | ^7.0.6
lerna-lite notice @types/lodash      | ^4.14.178
lerna-lite notice @types/node        | ^14.18.16
lerna-lite notice @types/object-hash | ^1.3.4
lerna-lite notice chai               | ^4.3.4
lerna-lite notice jest               | ^28.1.0
lerna-lite notice ts-jest            | ^28.0.4
lerna-lite notice typescript         | ^4.7.2
lerna-lite notice
lerna-lite info dry-run> git checkout -- package.json packages/nextjs/package.json packages/sdk/package.json

As you can see the workspace protocol was removed properly except for SDK package (dependencies). This is because I don't manage @wundergraph/wunderctl with lerna. In my opinion, the prefix should be always removed.

This is because I don't manage @wundergraph/wunderctl with lerna. In my opinion, the prefix should be always removed nonetheless it is managed by Lerna or not.

That's most probably the problem, I can only assume that Lerna's code (not the code I added but the original Lerna's code) only ever loop into something that exists in its for loop but if you're not providing it then it probably won't do anything with it hence why it keeps the workspace.
Removing the workspace: protocol for all might be doable but I can't work on it unless I have a repro. On my side I migrated Lerna-Lite to pnpm workspace yesterday and so I have a pnpm workspace to work with and the possibility to add breakpoints in the code. So if you want me to work on this, I need you to provide a repo or at the minimum the steps to do for testing this out, I really need a way to reproduce. Perhaps clone Lerna-Lite and modify it with your use case so that at least I get something to work with. Cheers

Hi @ghiscoding it's really simple to reproduce. Just remove one package from "packages" lerna.json but reference that dependency with the workspace: protocol in another package. If you publish the package, the workspace protocol isn't removed.

Everything else worked great! But this is a blocker for us.

It's because of the following code shown below, the concept that Lerna uses is that it doesn't touch anything other than what it has to update, they have a filter with localDependencies and I believe the local ones are the ones showing up in your packages list and anything else falls under external dependencies which I guess are anything that aren't going to be updated
https://github.com/ghiscoding/lerna-lite/blob/a39c8d9ec3546638d08c5be33aa5e27231c4f297/packages/publish/src/publish-command.ts#L569-L587
I can make it work with some exceptions, it will only works correctly when providing a workspace: with a semver version, it won't work as intended on things like workspace:* since npm-package-arg will interpret that as latest. So in your use case, I can get it to work but just make sure to always include a semver version when the package is outside of Lerna-Lite list of packages.
So if your package-1 external package is workspace:1.2.3 then it would publish "package-1": "1.2.3"
But if your external package is workspace:* then it would publish "package-1": "latest" because npm-package-arg parses it as "latest" and I don't want to have to add more code to fetch the real version number from registry.
I think it's acceptable and I can add some non-blocking (not throwing) errors that can be seen in log output to provide some hints to possibly replace them

This is reasonable. LGTM.

Published new release v1.5.1 which includes the fix for this issue, hopefully that fixes it.

Great work and I could verify it in my current release. I found out that peerDeps aren't removed. Can we reopen this issue?
I made some comments on https://github.com/ghiscoding/lerna-lite/pull/219/files

no need it's done

Thanks! Can you release it?

sorry I can't, I'm traveling this week, that will have to be next weekend at the earliest

No problem, enjoy!


Remove unused using from examples

Some examples have unknown usings. It would be nice to:
(a) remove them
(b) detect them all
For example:
protobuf/Logger/Server/Program.cs has an unused "using IceRpc.Protobuf;"

Fixed.


[android/mxnet] Add MXNet subplugin support

We newly added MXNet subplugin support for tensor_filter in https://github.com/nnstreamer/nnstreamer/pull/3742.
To run MXNet subplugin in android application, we added related implementation in api scripts.
We prepared prebuilt MXNet 1.9.1 libraries (built by NDK) and linked them at Android-mxnet.mk, Android-mxnet-prebuilt.mk.
You can build nnstreamer.aar with MXNet by following way.

set nnstreamer to https://github.com/nnstreamer/nnstreamer/pull/3742.
run bash java/build-nnstreamer-android.sh --enable_mxnet=yes

:memo: TAOS-CI Version: 1.5.20200925. Thank you for submitting PR #171. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://ci.nnstreamer.ai/.

:octocat: cibot: @makesource, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nnstreamer-api/ci/repo-workers/pr-checker/171-202205232010300.94728899002075-b484d9df49ceee6d3d58f77868ae654405f96348/.

:octocat: cibot: @makesource, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nnstreamer-api/ci/repo-workers/pr-checker/171-202205271620260.29833507537842-6309af4c378fdcf8dd3f68661f8e47b9c4ac8aa5/.


Compare symbols to symbols

This ensures that when we build the list of assignable attributes, we're comparing a list of symbols to a list of symbols, instead of a list of strings to a list of symbols. Otherwise, we get unexpected UnexpectedAttributeErrors.

:shaved_ice:


Create database schema and mongo set up

[ ] Set Up Mongo connection
[ ] Build models: Trainer, Session, Response

Here are the surveys for us to create the question dbs:
Pre-course SurveyMonkey_151565181.pdf
Session 1 SurveyMonkey_151558050.pdf
Session 2 SurveyMonkey_151565777.pdf
Session 3 SurveyMonkey_151566900.pdf


chore(deps): upgrade dev dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-dev-dependencies-k8s-26-main" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 3380

Questions ?
Please refer to the Backport tool documentation


drivers: sensor: add wurth elektronik sensor drivers

This pull request updates the revision of the hal, removes old drivers and updates and adds new drivers.
@mah-eiSmart

This is a big improvement to the Würth Elektronik sensor drivers, as

the sensor names are correct now (the name without article number does not identify the sensor)
numerous useful functions have been added
examples are added how to use the custom attributes
it's using the newest würth elektronik hal with the latest bug fixes

Thank you for contributing @wm-eisos and for reviewing.
BTW: The examples and drivers have been tested on several hardware platforms.

@yperess can you please rereview it.
Thanks in advance

@yperess can you please rereview it.
Thanks in advance

Looks like a few extra compliance tests failing still

This would be easier to review and get merged if you break it up into multiple PRs. Each PR should just cover one driver, removing the old one and adding the new one.

They have all been done in one PR since in this PR the halhas been updated with breaking changes to the old drivers and the new drivers need the new hal to function corectly.

@yperess i see that a couple of checks have been stuck for a while now. Do these require a review before they trigger?

@yperess i see that a couple of checks have been stuck for a while now. Do these require a review before they trigger?

Approved the workflow

Can you please reapprove it again now, i rann the check compliance py script this time and solved the issues hopefully no more compliance check fails.

@yperess @MaureenHelm since all checks have passed this time. can you please review it before any merge conflicts could happen.
Thanks in advance

@yperess @MaureenHelm this pull request is now ready for review

@MaureenHelm @yperess i just resolved the merge conflicts again. please review the commits before another merge conflict occurs.

@yperess can you please approve the workflow

Should i open another PR with the same commits as it seems to appear that this pull request has been inactive for 2 weeks
@MaureenHelm @yperess @nashif @teburd  @tristan-google

Should i open another PR with the same commits as it seems to appear that this pull request has been inactive for 2 weeks
@MaureenHelm @yperess @nashif @teburd  @tristan-google

I've triggered the workflow, there should be no need to re-open a PR since you already did so yourself. FYI given we are now in feature freeze for 3.5 this won't be another week until it can be considered for merging though.

@kartben can you please retrigger it

please retrigger the workflow i just marked the PR as ready for review

@MaureenHelm any updates regarding the rereview?

Latest force push was to apply 191865b on the drivers that have triggers

@kartben @MaureenHelm can you please review the changes?

Hello @carlescufi , hello @MaureenHelm ,
please approve this pull request. People are waiting to get access to the new version of the drivers.
Thank you for the support.

@teburd @yperess can I get your help reviewing this please?

@MaureenHelm any updates regarding this?

@kartben @yperess can you guys please check out this PR?

@MaureenHelm can you please check it out. im not sure if i should rebase,resolve the conflict and force push again.

@kartben any updates please?

@MaureenHelm @kartben can you please check it out. im not sure if i should rebase, resolve the conflict and force push again.

This will dismiss existing reviews but yes, this will need to be done eventually, i.e new sensors starting at 0x81 at the time of writing

@MaureenHelm @kartben can you please check it out. im not sure if i should rebase, resolve the conflict and force push again.

This will dismiss existing reviews but yes, this will need to be done eventually, i.e new sensors starting at 0x81 at the time of writing

any solution regarding the times to get the PRs approved it has been a cycle of me rebasing and fixing conflicts and before the PR is merged there is already another conflict

@MaureenHelm @kartben can you please check it out. im not sure if i should rebase, resolve the conflict and force push again.

This will dismiss existing reviews but yes, this will need to be done eventually, i.e new sensors starting at 0x81 at the time of writing

any solution regarding the times to get the PRs approved it has been a cycle of me rebasing and fixing conflicts and before the PR is merged there is already another conflict

Not really a criticism of your approach here, maybe there was no other way than to lump everything under the same PR (?), but frankly I think this boils down to the change being thousands of lines, which is incredibly much harder to manage for everyone involved, including reviewers.
See https://docs.zephyrproject.org/latest/contribute/guidelines.html#contribution-workflow -- "One general practice we encourage, is to make small, controlled changes. This practice simplifies review, makes merging and rebasing easier, and keeps the change history clear and clean."
For example, I am about to provide you with a few comments of things that need fixing, but as you'll have addressed them, that still won't be enough for me to give a +1 as the rest of the PR is beyond my domain of expertise.

@MaureenHelm @kartben can you please check it out. im not sure if i should rebase, resolve the conflict and force push again.

This will dismiss existing reviews but yes, this will need to be done eventually, i.e new sensors starting at 0x81 at the time of writing

any solution regarding the times to get the PRs approved it has been a cycle of me rebasing and fixing conflicts and before the PR is merged there is already another conflict

Not really a criticism of your approach here, maybe there was no other way than to lump everything under the same PR (?), but frankly I think this boils down to the change being thousands of lines, which is incredibly much harder to manage for everyone involved, including reviewers.
See https://docs.zephyrproject.org/latest/contribute/guidelines.html#contribution-workflow -- "One general practice we encourage, is to make small, controlled changes. This practice simplifies review, makes merging and rebasing easier, and keeps the change history clear and clean."
For example, I am about to provide you with a few comments of things that need fixing, but as you'll have addressed them, that still won't be enough for me to give a +1 as the rest of the PR is beyond my domain of expertise.

The thing is in this PR there is a hal update which produces breaking changes for the older drivers. Thats why i have mutliple drivers in the same PR.

The thing is in this PR there is a hal update which produces breaking changes for the older drivers.

So are you saying that just taking https://github.com/zephyrproject-rtos/zephyr/pull/62408/commits/fd5cecd7b4168079c3c2ecdc5784fc728832d43f leads to a configuration where drivers don't compile? We try to keep things bissectable so it would be good to fix if needed.

Thats why i have mutliple drivers in the same PR.

Yup but for example dropping the "non-generic" samples could be an entirely different PR, completely independent of the HAL bump, right? And this one would likely take a lot less longer to review.

Regarding the first point that is correct if the commit is merged then yes the older drivers wont compile.

Then please squash accordingly so that all commits correspond to a working state.

Regarding the first point that is correct if the commit is merged then yes the older drivers wont compile.

Then please squash accordingly so that all commits correspond to a working state.

what exactly should i squash

depends on PR (#68462) to be merged

@kartben regarding this PR, it is currently in draft but since the commits are no longer in this PR. This PR will fail because it still has the examples for the removed drivers? Anything to do regarding that ? i would like both to be merged for RC1.

@wm-eisos fyi and just to set expectations, we have entered feature freeze for Zephyr 3.6 release so it might be simpler to hold off for now ; in particular, the migration guide for 3.7 doesn't exist just yet so it will be easier for you to add to it once it's been seeeded after 3.6 is out. Thanks!

@kartben The PR has been updated and the release notes and migration guides have been moved to zephyr 3.7 files please have a look when you are free

any updates regarding this PR ?
@kartben @yperess @aescolar

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

Please remove the stale label. We are still waiting for review and merge.

Please remove the stale label. We are still waiting for review and merge.

@mah-eiSmart You will need to rebase the PR as it is currently conflicting with main.
@MaureenHelm, @kartben could you take another look?

@wm-eisos ^^

Please remove the stale label. We are still waiting for review and merge.

@mah-eiSmart You will need to rebase the PR as it is currently conflicting with main. @MaureenHelm, @kartben could you take another look?

@aescolar , yes that's right. My colleague, which is back next week, will do this. Actually, as you see in the history, we rebased already many times. After rebase, it would be nice to get finally the approval before the next incompatible changes of the master make the review again void.

@wm-eisos ^^

I have rebased the PR yesterday. please try to take another look as soon as possible.

@MaureenHelm, @kartben could you take another look at this PR?

are all of these bindings really needed at this point

Yes as these bindings are required to setup the sensor acccording to the behaviour that the user wants. PS this PR contains drivers for multiple sensors 7 in total

Can you please remove the Stale label, i have rebased the PR can you please check it as well.

there is a merge conflict

there is a merge conflict

I will solve it now however as you can see in this PR this loop keeps hapening where the merge conflicts are resolved and then new merge conflicts come up because the PR is still not merged

there is a merge conflict

I will solve it now however as you can see in this PR this loop keeps hapening where the merge conflicts are resolved and then new merge conflicts come up because the PR is still not merged

welcome to my life as well

@mah-eiSmart it looks like you approved of this PR, is that still the case

@mah-eiSmart it looks like you approved of this PR, is that still the case

Yes, from my side it's still fine!

somebody with sensor knowledge should review

@MaureenHelm as sensor maintainer, are you able to take a review of this?

somebody with sensor knowledge should review

@MaureenHelm as sensor maintainer, are you able to take a review of this?

@dkalowsk Seems, @MaureenHelm is busy. Can we go forward without her help?

somebody with sensor knowledge should review

@MaureenHelm as sensor maintainer, are you able to take a review of this?

@dkalowsk Seems, @MaureenHelm is busy. Can we go forward without her help?

There are ways to do so.  You can escalate in the developer meeting or on discord. I’m a little more concerned that this PR is a year in the making and stalling out on reviews. @nashif @MaureenHelm ping.

somebody with sensor knowledge should review

@MaureenHelm as sensor maintainer, are you able to take a review of this?

@dkalowsk Seems, @MaureenHelm is busy. Can we go forward without her help?

There are ways to do so. You can escalate in the developer meeting or on discord. I’m a little more concerned that this PR is a year in the making and stalling out on reviews. @nashif @MaureenHelm ping.

@dkalowsk , this PR has been adopted to new versions of Zephyr many times, in the past 12 months. Thus it's still up to date. Yesterday I got feedback that customers did not choose that sensor products, because the drivers are not up to date. Escalating on discord or on developer meeting we did not do so far, we have no experience with it.

This PR will be closed as the plan is to have seperate PRs per sensor


Jenkins issue

I got this issue on my mac.
ERROR: for jenkins  Cannot start service jenkins: error while creating mount source path '/usr/local/bin/docker': chown /usr/local/bin/docker: no such file or directory

Where is your docker binary installed? You might have to adjust that path in the docker compose yml.

I face the same issue:
➜  devops docker-compose up
Removing jenkins
gitlab is up-to-date
Recreating 09c82acaad92_09c82acaad92_jenkins
ERROR: for jenkins  Cannot start service jenkins: error while creating mount source path '/usr/local/bin/docker': chown /usr/local/bin/docker: no such file or directory
ERROR: Encountered errors while bringing up the project.
➜  devops which docker
/usr/local/bin/docker

Why was this issue closed? Did @keer2012 fix it? If so, can he/she please let the world know how because this is a massive pain in the backside.


Identifiers validation failed for dataset Estequiometría ecológica y percepción remota para el análisis de la distribución espacial e invasibilidad de zacate Buffel (Cenchrus ciliaris), en zonas prioritarias del noroeste de México

Identifier validation failed for the dataset Estequiometría ecológica y percepción remota para el análisis de la distribución espacial e invasibilidad de zacate Buffel (Cenchrus ciliaris), en zonas prioritarias del noroeste de México:

Crawler attempt: 155
Publishing organization: Comisión nacional para el conocimiento y uso de la biodiversidad
Publishing country: MEXICO
Installation: IPTCONABIO
Number of occurrences indexed for this dataset at the time of the issue: 391
Cause: GBIF IDs hit maximum allowed - 50%, duplicates - 100%, total records count 391, absent records count 391
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/3073471/step

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the Estequiometría ecológica y percepción remota para el análisis de la distribución espacial e invasibilidad de zacate Buffel (Cenchrus ciliaris), en zonas prioritarias del noroeste de México : https://doi.org/10.15468/m4udyv.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.

Identifier validation still  failing for the dataset Estequiometría ecológica y percepción remota para el análisis de la distribución espacial e invasibilidad de zacate Buffel (Cenchrus ciliaris), en zonas prioritarias del noroeste de México:

Crawler attempt: 158
Publishing organization: Comisión nacional para el conocimiento y uso de la biodiversidad
Publishing country: MEXICO
Installation: IPTCONABIO
Number of occurrences indexed for this dataset at the time of the issue: 391
Cause: GBIF IDs hit maximum allowed - 50%, duplicates - 100%, total records count 391, absent records count 391
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/3094205/step

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the Estequiometría ecológica y percepción remota para el análisis de la distribución espacial e invasibilidad de zacate Buffel (Cenchrus ciliaris), en zonas prioritarias del noroeste de México : https://doi.org/10.15468/m4udyv.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.


Bootstrap theme doesn't respect Bootstrap color schema

Describe the bug
Bootstrap theme doesn't respect Bootstrap color schema.
To Reproduce

Go to https://jsfiddle.net/Kolyunya/L4u8xptg/2/
See theme background color is black.
See Bootstrap select background is black.
See Tom Select select background is white.

Expected behavior
Select background color and text color should match the Bootstrap theme.
Additional context
Add any other context about the problem here.

OS: MacOS v13
Device: Mac Book
Browser Chrome v116, Firefox v117

I temporarily fixed the problem with the following scss
/* TOM SELECT */
.ts-dropdown, .ts-control, .ts-control input {
  color: var(--bs-body-color);
}
.ts-wrapper.plugin-remove_button .item .remove {
  color: $red;
}
.plugin-clear_button .clear-button {
  color: $red;
  right: 60px;
}
.ts-dropdown {
  z-index: 1060;
}

I added patch #673 for this

Bump

Bump


Error while verifying the Quote and geting the Coordinator’s Root-Certificate

Hello,
I am trying to deploy the demo emojivoto demo in AKS using Marblerun.
However, I am currently stuck at step 3.4 "Verify the Quote and get the Coordinator’s Root-Certificate".
I am attaching the error log with additional logs here.
Marblerun error.txt

The problem seems to be that you're not configuring the remote access for the Marblerun Client API when deploying on AKS.
While using Minikube you can just use the kubectl port-forward command, in AKS you need to make the coordinator-client-api  service accessible from the outside world.
When running on AKS a LoadBalancer will be assigned automatically the service and you'll receive a public IP address.
In the tools/aks_install.sh we assign a DNS name to the public IP of the LoadBalancer:
# set dns for coordinator
echo "[*] Setting DNS for the marblerun-coordinator"
IP=""
echo -n "[*] Waiting for LoadBalancer to assign a public IP..."
until [[ $IP =~ ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$ ]];
do
    IP=$(kubectl -n marblerun get svc coordinator-client-api -o jsonpath="{.status.loadBalancer.ingress[0].ip}")
    echo -n "."
    sleep 3
done
PUBLICIPID=$(az network public-ip list --query "[?ipAddress!=null]|[?contains(ipAddress, '$IP')].[id]" --output tsv)
az network public-ip update --ids $PUBLICIPID --dns-name "$MARBLERUN_DNSNAME" > /dev/null
MARBLERUN=""
until [[ $MARBLERUN == "$MARBLERUN_DNSNAME."* ]]
do
    MARBLERUN="$(az network public-ip show --ids $PUBLICIPID --query "[dnsSettings.fqdn]" --output tsv):25555"
    echo -n "."
    sleep 3
done
echo ""
echo -e "[$okStatus] Done"

You have two options here:

Either you follow this approach and set the DNS correctly for the LoadBalancer IP
Or you connect to the public IP directly. Note that in this case you'll need to disable the certificate verification (It might take a few seconds until the IP is assigned to the service)

$ kubectl -n marblerun get svc
NAME                     TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)           AGE
coordinator-client-api   LoadBalancer   <IP_ADDRESS>   <IP_ADDRESS>   25555:30915/TCP   4m7s
coordinator-mesh-api     ClusterIP      <IP_ADDRESS>    <none>           25554/TCP         4m7s
$ era -c coordinator-era.json -h <IP_ADDRESS>:25555 -o marblerun.crt
Azure Quote Provider: libdcap_quoteprov.so [ERROR]: Could not retreive environment variable for 'AZDCAP_DEBUG_LOG_LEVEL'
SUCCESS, certificate writen to marblerun.crt

I set up the DNS name to the public IP of the LoadBalancer and tried again. Now facing a different error.
$ era -c coordinator-era.json -h $MARBLERUN -o marblerun.crt
panic: Get "https://marblerun.westeurope.cloudapp.azure.com/quote": dial tcp <IP_ADDRESS>:443: connect: connection timed out
goroutine 1 [running]:
main.main()
/home/moritz/edgeless/era/cmd/era/main.go:32 +0x433
As far as I know, Microsoft does not provide "SGX Quote Helper" feature now for remote attestation with the new AKS with ConfCom Addon, so is it trying to access it? Is that the reason behind this error?

Are you sure you're using the right port? Default port of the coordinator-client-api is 25555.

Yeah, I forgot about the port. It's working now. However, I am now facing another error at step 4:
curl --cacert marblerun.crt --data-binary @tools/manifest.json "https://$MARBLERUN/manifest"
curl: (60) SSL: no alternative certificate subject name matches target host name 'marblerun.westeurope.cloudapp.azure.com'
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

curl: (60) SSL: no alternative certificate subject name matches target host name 'marblerun.westeurope.cloudapp.azure.com'
More details here: https://curl.haxx.se/docs/sslcerts.html

The problem is when your installing Marblerun via the helm chart, e.g.:
helm install marblerun-coordinator edgeless/marblerun-coordinator \
    --create-namespace \
    -n marblerun \
    --set coordinator.hostname=YOUR_DOMAIN

You have to specify YOUR_DOMAIN. The coordinator will issue a self-signed certificate and obtain a quote for it.
This certificate will be used for TLS on the client API.
When you're configuring the DNS for coordinator-client-api LoadBalancer service, you need to make sure you're using the same YOUR_DOMAIN.
That is what curl is complaining about. $MARBLERUN points to marblerun.westeurope.cloudapp.azure.com, but the client API certificate was issued for a different domain.


Getting a cycle error

Description
I'm getting a cycle error.
my code:
module "acm" {
  source  = "terraform-aws-modules/acm/aws"
  version = "~>4"

  for_each    = toset(var.service_name)
  domain_name = "${local.resource_prefix}-${each.key}.${var.domain_name}"

  create_route53_records  = false
  validation_record_fqdns = module.acm_route53_records.validation_route53_record_fqdns

}

module "acm_route53_records" {
  source  = "terraform-aws-modules/acm/aws"
  version = "~>4"

  providers = {aws = aws.main}

  for_each    = toset(var.service_name)

  create_certificate          = false
  create_route53_records_only = true

  zone_id               = data.aws_route53_zone.selected.id
  distinct_domain_names = module.acm[each.key].distinct_domain_names

  acm_certificate_domain_validation_options = module.acm[each.key].acm_certificate_domain_validation_options

}

error:
Error: Cycle: module.acm_route53_records.var.distinct_domain_names (expand), module.acm_route53_records.local.distinct_domain_names (expand), module.acm_route53_records.var.acm_certificate_domain_validation_options (expand), module.acm_route53_records.local.validation_domains (expand), module.acm_route53_records.aws_route53_record.validation, module.acm_route53_records.output.validation_route53_record_fqdns (expand), module.acm.var.validation_record_fqdns (expand), module.acm.aws_acm_certificate_validation.this, module.acm.output.acm_certificate_arn (expand), module.acm (close)

if I only run with just the acm only block it works fine.

[x ] ✋ I have searched the open/closed issues and my issue is not listed.

⚠ Note
Before you submit an issue, please perform the following first:

Remove the local .terraform directory (! ONLY if state is stored remotely, which hopefully you are following that best practice!): rm -rf .terraform/
Re-initialize the project root to pull down modules: terraform init
Re-attempt your terraform plan or apply and check if the issue still persists

Versions

Module version [latest]:

Terraform version: 1.2.8

I don't see an immediate issue other than the missing index ([each.key]) here:
validation_record_fqdns = module.acm_route53_records[each.key].validation_route53_record_fqdns


adding polygon to raster map

Please don't merge yet!
Still not perfect....without adding the sp polygon, the raster map looks like this:

but then when I add it, it looks like this:

There seems to be an issue with the projections because of the lat/long values are so different.
> sp::bbox(precip_sp_projected)
  min max
x   1  21
y   1  29
> sp::bbox(projected_sp)
      min       max
x  515163  554718.2
y 2252248 2304876.6

@lindsaycarr projected_sp has to be in UTM coordinates, those aren't lat/lons

@wdwatkins yeah, I'm not really sure what that means or how to do that?

Hmm, also the min/max you are getting for the raster I think is just the raster cell coordinates (ie it is 21x29 pixels).  If you look at a map that won't be anywhere near WI.
Maybe see look into how the base raster is georeferenced?

It looks fairly simple to transform from UTM to lat/lon if you need to.  https://stackoverflow.com/questions/36520915/converting-utms-to-lat-long-in-r

OK, so I looked at this page (https://gis.stackexchange.com/questions/23841/create-a-raster-with-georeferenced-information-in-r) and realized I had the exact extent of the raster in order to georeference it to lat/long, so I added that step. I'm much closer because the watershed polygon plots over the same region, but now the precip values don't show up:

Good progress, is there a white background with the polygon maybe?

There was something strange happening with re-projecting it. Something about warping. I kept it in the projection string that geoknife automatically uses and it works:

@wdwatkins can you do another quick review? I can run make and this is what I get for the clip fig:

If you're dealing with cosmetic stuff yet I would say reduce the color scale range so it is all used, unless there will be other maps with values that go to two.  Will look at the code later this morning.

Well, the maximum value is 1.8 ... so I had the scale round up from the maximum. What's the best way to do it?

Oh ok, never mind then.  It must just be a single cell or something.

They all look faded though, like alpha is not 1. I haven't figured that out.

Hmm yep - that's the issue. I thought I had that working for something previously? I'll submit changes to that and then merge this! Thanks!

Here's what it looks like now (still not included in publish)