DocsArchive-<IP_ADDRESS>Auto archive content

Please don't merge this PR until target archive repo PR https://github.com/OPS-E2E-PPE/docs-archive-test-target_c19fe9ed-6ee0-4e86-a28d-bdccd32f75f5/pull/1 is merged into live branch.
Auto archive content to https://github.com/VSC-Service-Account/docs-archive-test-target_c19fe9ed-6ee0-4e86-a28d-bdccd32f75f5.git

Docs Build status updates of commit c96615c:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error-ServiceAccountCannotAccessRepository] Your repository https://github.com/VSC-Service-Account/docs-archive-test-source has enabled Docs Build service account. It seems that at least one of the accounts, e2ebd4, does not have Read permission to the repo. Please ask your repo admin to grant correct permission to service accounts (refer to this document: https://review.docs.microsoft.com/en-us/engineering/projects/ops/engdocs/how-to-grant-service-account-permission-in-your-repository?branch=master#ops-e2e-ppe) and then retry the build. Don't know who to contact? Refer https://repos.opensource.microsoft.com/VSC-Service-Account/repos/docs-archive-test-source/permissions/ to get admin list of the repo if the repo is in one of the organizations Microsoft owns.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


add Linking to avutil and create build directory

Hello, thanks for your precious tutorial.
To make it build on my system i have to link also avutil.
It should fix also #15
Thanks

Thanks 😄 What OS are you using and ffmpeg/libav version?

I'm on archlinux with ffmpeg 3.4.2 and gcc 7.3.0 :)
Without making "build" dir and without linking avutil i get:

/usr/bin/ld: cannot open output file build/hello_world: No such file or directory
collect2: error: ld returned 1 exit status
make: *** [Makefile:4: hello_world] Error 1

If i only create "build" without linking i get:

/usr/bin/ld: /tmp/cc3NrScJ.o: undefined reference to symbol 'av_frame_free@@LIBAVUTIL_55'
/usr/lib/libavutil.so.55: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [Makefile:4: hello_world] Error 1

adding mkdir build and -lavutil as in PR: no error.

thank you very much @anthonytex


Routing question

When in a single-language site I would have e.g.
paginabinding:
    path:           /{slug}
    defaults:       { _controller: 'Bolt\Controllers\Frontend::record', 'contenttypeslug': 'pagina' }
    contenttype:    paginas

for my "pagina" contenttype to be rendered as
/pagina-slug
what should I do to get
/en/pagina-slug and /nl/pagina-slug etc
in a site with Bolt translate?
And should it be done in the same location in routing.yml?

@evertalbers If you have the automatic routing activated it should be fixed automatically... Does it not for you?

The contenttype is
paginas:
    name: Paginas
    singular_name: Pagina

the urls that do work are e.g.
/nl/paginas/projecten and
/en/paginas/projects
but these do not work:
/nl/projecten and
/en/projects

@evertalbers Could you post you full routing.yml so I can try it out?

My, you're quick. I'll post the routing in a minute.
BTW, and possibly related, I see that I can translate the slug in the backend, and that the urls are working correctly in the browser, but that the {{ localeswitcher() }} renders the urls as
/en/paginas/**projects** and /nl/paginas/**projects** on the English page and as
/en/paginas/**projecten** and /en/paginas/**projecten**on the Dutch page
(which are both the same pagina -record)
So it is not possible make the slug translatable? I expect that SEO fanatics are going to want this.

Here we are, routing.yml:
# This file defines user-definable routes for the frontend of your Bolt website.
# Check below for examples, or read the documentation at http://docs.bolt.cm/templates-routes#routing

# Begin Profin-specific routes

sitemapxml:
  path: /sitemap.xml
  defaults: { _controller: 'Bolt\Extension\Bolt\Sitemap\Extension::sitemapXml' }

sitemap:
  path: /sitemap
  defaults: { _controller: 'Bolt\Extension\Bolt\Sitemap\Extension::sitemap' }

paginabinding:
    path:           /{slug}
    defaults:       { _controller: 'Bolt\Controllers\Frontend::record', 'contenttypeslug': 'pagina' }
    contenttype:    paginas
homebinding:
    path:           /{slug}
    defaults:       { _controller: 'Bolt\Controllers\Frontend::record', 'contenttypeslug': 'home' }
    contenttype:    homepages

# categorybinding:
#     path:            /{doelgroepen}/{slug}
#     defaults:        { _controller: 'Bolt\Controllers\Frontend::record', 'contenttypeslug': 'paginas', 'doelgroepen': 'zakelijk' }
#     requirements:
#         doelgroepen: [ 'Bolt\Controllers\Routing::getTaxonomyRequirement', ['particulier', 'zakelijk'] ]
#     contenttype:      paginas

# End of Profin-specific routes

# These are the routes defining the default behaviour of Bolt's frontend. Changing these
# might give unexpected results. If possible, only add NEW routes above these.

homepage:
  path:               /
  defaults:           { _controller: 'Bolt\Controllers\Frontend::homepage' }

search:
  path:               /search
  defaults:           { _controller: 'Bolt\Controllers\Frontend::search' }

preview:
  path:               /preview/{contenttypeslug}
  defaults:           { _controller: 'Bolt\Controllers\Frontend::preview' }
  requirements:
    contenttypeslug:  'Bolt\Controllers\Routing::getAnyContentTypeRequirement'

contentlink:
  path:               /{contenttypeslug}/{slug}
  defaults:           { _controller: 'Bolt\Controllers\Frontend::record' }
  requirements:
    contenttypeslug:  'Bolt\Controllers\Routing::getAnyContentTypeRequirement'

taxonomylink:
  path:               /{taxonomytype}/{slug}
  defaults:           { _controller: 'Bolt\Controllers\Frontend::taxonomy' }
  requirements:
    taxonomytype:     'Bolt\Controllers\Routing::getAnyTaxonomyTypeRequirement'

contentlisting:
  path:               /{contenttypeslug}
  defaults:           { _controller: 'Bolt\Controllers\Frontend::listing' }
  requirements:
    contenttypeslug:  'Bolt\Controllers\Routing::getPluralContentTypeRequirement'

Is the error you are getting this: Parameter "slug" for route "paginabinding" must match "[^/]++" ("" given) to generate a corresponding URL. ?

This is the error on a 'pagina' where I left out the 'pagina/' in the url, still with the routing above:

Error gone, see above :-)

Good to hear, I'll close the issue than. :)

@evertalbers I'm guessing the issue you mentioned today is if the contenttype slug is translateable? As in  paginas in your example?

Yes it was, and that's solved. Only now I see this post so I've been cross-posting/cross-slacking a bit here.


refactor(offerings) get rid of base model for offerings, service offerings and disk offerings

#781, #787 will be closed here too.

@qqcky , please fix PR name


Add productFields on Trees

As discussed on gitter, it would be really cool to access all the fields of a tree.
We already have productPrefix which enumerates the values, but there's no way of enumerating the names of the fields.
Ultimately the idea would be to have enough pieces to expose a toMap that returns a Map[String, Tree | Seq[Tree]] (yeah, I know, no unions in Scala yet, but clarity). For example, given
1 + 2

the resulting tree would be
Term.ApplyInfix(
  lhs = Lit.Int(
    value = 1
  ),
  op = Term.Name(
    name = "+"
  ),
  targs = Seq(),
  args = Seq(
    Lit.Int(
      value = 2
    )
  )
)

then the toMap function applied to the top-level Tree would return
Map(
  "lhs" -> Lit.Int(1),
  "op" -> Term.Name("+"),
  "targs" -> Seq(),
  "args" -> Seq(Lit.Int(2))
)

With that, one could recursively apply toMap to the structure and add more metadata (e.g. the type), ending up with a serializable representation of a tree.
Map(
  "type" -> "Term.ApplyInfix",
  "lhs" -> Map(
     "type" -> "Lit.Int",
    "value" -> 1
  ),
  "op" -> Map(
    "type" -> "Term.Name",
    "name" -> "+"
  ),
  "targs" -> Seq(),
  "args" -> Seq(
    Map(
      "type": "Lit.Int",
      "value": 2
    )
  )
)

As I'm writing this, I think it would probably be cool to have a serialize method that does this, perhaps provided by contrib.
Thoughts?

We could also use this to generate prettyStructure from this.

@gabro How has your prototype evolved? Have your requirements changed in the last few days?

no, they're essentially the same. It would still be very useful to access the names of the fields of a Tree, so to zip them with the values.

Would you consider contributing this functionality? I'm quite overwhelmed at the moment by the end-of-quarter stuff.
Here's where I'd add synthesis of the productFields method: https://github.com/scalameta/scalameta/blob/master/scalameta/common/shared/src/main/scala/scala/meta/internal/ast/ast.scala#L168. I'd obtain the labels for productFields from fieldParamss.

Yup, I tried something like that today, but I had an hard time debugging it and I couldn't get very far. I'll try again and see what I can do :)

Please let me know where you get stuck. I'll be happy to help.

Yay, I have something that appears to be working :) @xeno-by as soon as you have time: https://github.com/scalameta/scalameta/pull/956


Clean up '#if CORE' in CurrentConfigurations.cs

Related #3565 and #4357.

For simple changes like: removing unnecessary using directives, or purely removing enclosing if/defs, please group them in one PR in future.


Gridded data

Tippecanoe's gridded data support is limited to --grid-low-zooms, which requires a lot of guesswork to choose an appropriate detail and maxzoom, uses the tile grid rather than the natural grid of the data, and drops rows and columns instead of interpolating values.
There should be a tippecanoe-grid command that is roughly equivalent to gdal_polygonize (and perhaps also gdal_contour) but instead of outputting a single set of polygons for the grid, outputs a series of grids appropriate to different zoom levels, with "tippecanoe": { "minzoom": …, "maxzoom": … } set so they show up at the appropriate zoom levels.
For manageable tile sizes, the grid should be approximately 128x128 in each tile, so if the grid unit is, say, 1000 feet, it should choose zoom level 10 for the full-detail zoom level, because 360 / (2^10) / .00000274 / 128 is about 1000. Each lower zoom level should then cut the number of cells in each dimension in half.
Major uncertainties:

What file format should it accept? Is there a format that is each for people to get their data into, sufficiently general, and not too much work to parse?
How much projection support is needed? Ideally it would handle the natural projection of the gridded data instead of requiring that it already be reprojected to WGS84 or Web Mercator.
Does it need to be able to reconstruct the grid of data that has already been polygonized?

What file format should it accept? Is there a format that is each for people to get their data into, sufficiently general, and not too much work to parse?
I suggest NetCDF - as close as it gets to a standard gridded data interchange format, easy to work with, many libraries.


[AMD-149] Add updated timestamp into node and relation

Summary of Changes
Add updated timestamp into node and relation. This will enable certain feature such as pagination.
Tests
Performed integration test.
Documentation
What documentation did you add or modify and why? Add any relevant links then remove this line
CheckList
Make sure you have checked all steps below to ensure a timely review.

[x] PR title addresses the issue accurately and concisely. Example: "Updates the version of Flask to v1.0.2"

In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.

[x] PR includes a summary of changes.
[x] PR adds unit tests, updates existing unit tests, OR documents why no test additions or modifications are needed.
[x] In case of new functionality, my PR adds documentation that describes how to use it.

All the public functions and the classes in the PR contain docstrings that explain what it does

[x] PR passes make test
[x] I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message"

Codecov Report

Merging #82 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #82      +/-   ##
==========================================
+ Coverage   83.19%   83.21%   +0.01%
==========================================
  Files          54       54
  Lines        2606     2609       +3
  Branches      267      267
==========================================
+ Hits         2168     2171       +3
  Misses        353      353
  Partials       85       85

Impacted Files
Coverage Δ

databuilder/publisher/neo4j_csv_publisher.py
84% <100%> (+0.24%)
:arrow_up:

Continue to review full report at Codecov.

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


In a complex integration test setup which runs the go tool with a custom (ephemeral) XDG_CONFIG_HOME and HOME directory, I want to entirely turn off go telemetry: I found telemetry to trigger go module downloads that end up polluting my ephemeral module cache:

testing.go:1232: TempDir RemoveAll cleanup: unlinkat<EMAIL_ADDRESS>permission denied

(This failure seems to have started with Go 1.23, but I’m having trouble reproducing it outside of GitHub Actions.)
What did you see happen?
I tried setting GOTELEMETRY in the environment, but it has no effect:
% go env GOTELEMETRY
local
% GOTELEMETRY=off go env GOTELEMETRY
local

I also tried setting GOTELEMETRY in GOROOT/go.env, but it has no effect there either (whereas GOAMD64 has, so I’m editing the right file):
% go env GOAMD64
v1
% echo 'GOAMD64=v3' >> '/home/michael/sdk/go1.23.0'/go.env
% go env GOAMD64
v3
% echo 'GOTELEMETRY=off' >> '/home/michael/sdk/go1.23.0'/go.env
% go env GOTELEMETRY
local

What did you expect to see?
I would have expected GOTELEMETRY=off to be honored.
In https://github.com/golang/go/issues/67111, I can see mention of GOTELEMETRY being an unsettable environment variable. While I understand the rationale for go telemetry on being the only way to enable telemetry, I don’t think that applies to turning off telemetry, which I think should be possible via the environment.

Related Issues and Documentation

Unknown go command variable GOTELEMETRY - how to disable telemetry? #67424 (closed)
x/telemetry/internal/counter: ErrDisabled references non-existent GOTELEMETRY environment variable #65503 (closed)
telemetry.go.dev/privacy: "Internal Server Error" #68859 (closed)
x/tools/gopls: no datas for gotelemetry #67781 (closed)
x/telemetry: `go install` / `go run` fails for `golang.org/x/telemetry/cmd/gotelemetry@latest`: "no matching versions for query "latest"" #63825 (closed)
Go Telemetry > Configuration
cmd/go: TestScript/env_changed fails when modifying go.env for Go distributions #67793 (closed)
cmd/go: go env -changed prints changed values for variables in go.env #67542 (closed)

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

like GOMOD, it's there only to report the current state, not to allow modifications.

@golang/telemetry :
Should setting the GOTELEMETRY environment variable affect whether we record telemetry?  Do we ever document that that is how it behaves?  Thanks.

Should setting the GOTELEMETRY environment variable affect whether we record telemetry? Do we ever document that that is how it behaves? Thanks.

That's not how it behaves. See this comment from the proposal: https://github.com/golang/go/issues/67111#issuecomment-2111097777.
I think this needs to be documented, at least at the bottom of go help environment, but also at go help telemetry and go.dev/doc/telemetry.
I also recall that we've discussed it making GOTELEMETRY settable, and I believe there has been no objection to supporting that, apart from the confusing asymmetry that we'd never support GOTELEMETRY=on (as @stapelberg astutely assessed. Let's reopen this issue to track improving the documentation, and open a separate issue for making GOTELEMETRY=off settable.
The issue with GOMODCACHE is tracked by https://github.com/golang/go/issues/67111#issuecomment-2111097777, and I consider it a bug that we should fix for 1.23.1.

Filed #68960 to formally consider supporting GOTELEMETRY=off in the environment.

BTW, it looks go clean -telemetry doesn't work. What is the current implementation way to clean telemetry data?

@zigo101 you can install golang.org/telemetry/cmd/gotelemetry and run gotelemetry clean.
You can also delete files in os.UserConfigDir()/go/telemetry. You may want to keep the mode file if it is set to off.


[flutter_tools] remove bogus same repo check

Description
Flutter currently attempts to check if the flutter tool that is running an application is the same version in the application's .packages/package_config.json file. As written, the check is bogus since:

It runs before package resolution
pub will update the .packages/package_config.json after switching tools

In short, this check will never give a meaningful result unless the user is manually specifying a .packages/package_config path - meaning they are likely embedding flutter into another build system.

It looks like this code was added to fix https://github.com/flutter/flutter/issues/3330. Does that issue need a different fix?

I'm not quite sure what the scenarios in 2016 were that the check was trying to prevent. I reopened and commented on the bug.
Perhaps we ran pub less often? Not that we run pub automagically in most cases the problem resolves itself.


fix(core): only clone the own properties instead of all possible prototype properties

Description
I am currently investigating into replacing jquery by cash in our https://github.com/fomantic/Fomantic-UI ( because everyone is moaning about it ) and came across this while testing:
Whenever the extend  method is used, it should make sure to only extend the own properties instead of all possible prototype functions as well

@lubber-de could you try to adhere to the library's coding style more? Also could you add a test for this?

After more investigation for our usecase (use cash as a jquery drop-in replacement for fomantic-ui) i am closing this because the extend function rather needs to implement the deep option instead of limiting to ownProperties (which would still be valid if only raw 1 level objects should be extended)
However, there would be some more features like isPlainObject needed and as i read in https://github.com/kenwheeler/cash/issues/196  it seems cash is currently not interested to implement such to keep the library size small

@lubber-de can you compile a list of the things that you'd need to switch to cash? I think deep and isPlainObject could be added here.


Fix 404 Navigation Issue from README_JA and README_CN to English Docs

This PR resolves issue #1502 by updating the navigation links in the README_JA and README_CN.

Issue: Error 404 when redirecting to README.md (English docs) from README_CN.md and README_JA.md.
Problem: The files redirected within the docs folder, while the README.md was located outside the folder.
Solution: Changed the URL to correctly redirect outside the docs folder.

Files Changed:

README_JA.md
README_CN.md

This contribution is part of Hacktoberfest 2024.

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 62.65%. Comparing base (45f102c) to head (eecbfb5).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1504   +/-   ##
=======================================
  Coverage   62.65%   62.65%
=======================================
  Files         285      285
  Lines       17535    17535
=======================================
  Hits        10986    10986
  Misses       6549     6549

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

https://github.com/geekan/MetaGPT/pull/1503 looks more complete and includes links to several other READMEs. But I understand that the actual modification has not been completed, and the directions of several other documents need to be corrected as well.


Fixed pickResizeHandler.

Hello,
I fixed the pickResizeHandler which took the wrong split in "event.target.className.split(" ")[1]". It took "select-areas-resize-handler" instead of the direction which is in "event.target.className.split(" ")[2]". Some whitespaces got also deleted.
Regards
Moritz

Thank you, the change is available on 1.0.4
https://github.com/delkant/angular-areas/releases/tag/1.0.4


finetuning  OD task

Hi,
Dear author, when can you provide a demo for fine-tuning the OD task? Are there any modifications needed? Thank you very much, I am looking forward to your code

I think someone is already working on it, look here: https://github.com/SangbumChoi/florence2-finetuning/commit/863df42ee731a715eed3e188d9844e0702b1fbfe

Awesome, thank you very much!


[T6A3][T09-C2]Clarence Chee

@cheec Some comments added. Please close the PR after reading comments.


Shader group rebuilt to match Unity w/ Sun lamp

Per our discussion in the issues thread, I have rebuilt the shader group based on Unity's code. This shader will match Unity when the light settings are correct. They must be:

Sun Lamp with Strength 1, Color White [1,1,1], Angle 180deg, no Shadows
World Lighting 0 (can use Lightpath in the World nodes if you still want the background to display color other than black.)

If you use this, I suggest having the addon set the Sun to use these values, and warn users when they don't have them. This setup could be made to work with the sun having Color if the color is input into the nodes.

I have not tested this in detail yet and there may still be some issues. We will be testing it more in the coming days.
I am also working on better UVs for the Matcap that will match Unity better and should have that soon.

Thank you very much. I will check it in my environment this weekend.

@aVersionOfReality Please share me the blend file with the correct setup.
I tried your node but it didn't show the Lit color. I believe that the sun lamp and world light have been set up as specified by you.

My test .blend file
https://github.com/saturday06/3d-model-test-resources/blob/unity-mtoon1-debug/blend/render/sphere1.blend

My reference unity project
https://github.com/saturday06/3d-model-test-resources/tree/unity-mtoon1-debug/unity/UniVrmUrpMtoon1Screenshot

Here is a screenshot of the current situation. Lit Color is not displayed in Blender 3.6.3 and Windows 11

After modifying the Shading Grade nodes, Lit Color now appears. However, the display is different from Unity.
Maybe my settings aren't good enough, so I still want a .blend file that's set up correctly.

Ah, it is my mistake. I forgot to test without Toon set to 1, and I didn't realize Shading Shift Texture scale defaulted to 1, which I suppose was obvious. Recreating the Unity code snippet is not enough. Many things are different. There must be more happening than is shown in this shader file.
I have a new version where I've fixed both issues, but need to test some other things. Will try to send tomorrow.

Merged. I will make the following changes.

Use legacy light emulation for a while. I will remove it in the future.
I will adjust it to work with Blender 2.93 as well.

Any additional changes are welcome.
Thanks!


Send test notifications ends with HTTP 400 error

Describe the bug
Testing notifications is not working and it returns POST error 400 on logs and returns error "There was an error communicating with the server".
Version
0.46.00 via Docker
To Reproduce
Steps to reproduce the behavior:

Go to Settings
Click on Notifications
Input URL to Notification URL List. If already have URLs, just go to part 4
Click Send test notification
Bug reproduced

Expected behavior
Test notifications should go normally
Desktop (please complete the following information):

OS: Windows 11
Browser: Edge
Version: Latest as time of writing (126.0.2592.102)

Additional context
This issue was found by my friend and I managed to reproduce it myself as well on my machine
I am not entirely sure if this could affect also possible notifications which needs to be send if/when notification has to be pushed.

I cant do anything without logs from the server/software and the chrome console from 'inspect' can you do that?

Ahh I see it also, thanks all, i can confirm it

OK yeah its only on group/tag and global settings because it doesnt know which Watch to use as the template, fixing now

@JantsoP @L480 oops, please try latest docker image 0.46.01 and let me know if it solves your problem (it should!)

Works now, thanks!

Can also confirm that it works now :)


net/netip: Prefix's MarshalText and String methods produce different values

What version of Go are you using (go version)?

$ go version
go version devel go1.18-766f89b5c6 Fri Dec 10 19:26:50 2021 +0000 linux/amd64

Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/capnspacehook/.cache/go-build"
GOENV="/home/capnspacehook/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/capnspacehook/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/capnspacehook/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/capnspacehook/Documents/git/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/capnspacehook/Documents/git/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="devel go1.18-766f89b5c6 Fri Dec 10 19:26:50 2021 +0000"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/capnspacehook/Documents/git/go/src/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3691310336=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Tested that Prefix's MarshalText and String methods produced the same values on valid addresses:
https://go.dev/play/p/5KqfR6YXCox?v=gotip
What did you expect to see?
true
"::ffff:<IP_ADDRESS>/8", "::ffff:<IP_ADDRESS>/8"

What did you see instead?
false
"::ffff:c0a8:8cff/8", "::ffff:<IP_ADDRESS>/8"

Again, I found this while working on #49367. Seems extremely similar to #50110.

CC @bradfitz


Admin should be able to download all applications, regardless of version

Is your feature request related to a problem? Please describe.
In the admin view, each version appears with a link to the applications. The user has to scroll to the bottom to see the most recent version and if they click download at the top, it isn't clear what version is being downloaded. https://github.com/seattle-uat/civiform/issues/1560 will work to address seeing the latest version only, but it would also be ideal if the admin could download all applications.
Describe the solution you'd like
Admin is able to download ALL applications, regardless of form version.
Additional context
Add any other context or screenshots about the feature request here.
Done when
What conditions need to be met before this issue can be closed?
The admin is able to download ALL applications, regardless of form version.

Solved by #1990! Closing.


Usability issue with search on main page

As long as you are looking at the search window, could you change it so that when the search button is pressed, the focus changes to the search window?
This will make it easier to press search, type your search keywords
Instead of today's press search, move your cursor to the search window, press enter, type your search keywords

Could you provide more clarity on what you're talking about?

When you want to search for something, you need to type a search text string. The search text needs to be entered in the search box that opens below the search button. But the cursor is still hovering over the search button so you cannot type into the search box.

got it

Do you know which folder contains the main page?

Information about the web site: https://apache.org/dev/infra-site.html
The source code for this website is in the GitHub repository https://github.com/apache/www-site . Everyone has read access. All ASF committers have write access, although you should only commit changes to areas you are responsible for.

i added the focus function so the cursor auto come to input filed  ( check pull request )


[dv/alert_handler] add sanity test

connect alert_handler agent on the alert sender side
enable one alert and let it go through interrupt and escalation
Signed-off-by: Cindy Chen<EMAIL_ADDRESS>

Hi Sri @sriyerg I updated the code as you suggested, could you PTAL?


WIP: update golang.org/x/crypto vendor to use acme v2

Fix #9041

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@06984bb). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #9056   +/-   ##
=========================================
  Coverage          ?   41.11%
=========================================
  Files             ?      549
  Lines             ?    71495
  Branches          ?        0
=========================================
  Hits              ?    29393
  Misses            ?    38382
  Partials          ?     3720

Continue to review full report at Codecov.

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

backport to 1.10 ?

Yeah backport seems reasonable

@techknowlogick why WIP / whats the current state
( as people asking mor and more in discord how to do ssl ...)

@6543 WIP as while I believe this would work, I would like to test this first.
I've just spun up a VM to test this, once done then I will remove WIP and merge.

Just tested and this worked, will merge this once build is successful.


What is the timeline for production-ready support for ReactNative?

Hi folks, we're currently evaluating different options to render and interact with GLTF models. We have a ReactNative application. We're considering to implement this within the WebView and later add ReactNative support. We've tried Three.JS and it works well within WebView, but we couldn't make expo-gl and expo-three work to bridge into ReactNative.
We're wondering if we should pick BabylonJS for the time being and later add native support. What would be the timeline for production-ready support for ReactNative? We've tried the current version and it was much slower than rendering within a WebView. We've also experienced issues rendering some of the models on the WebView but not on the desktop browser.

Thanks for your interest! We are planning on releasing a dot version of BabylonReactNative as part of the Babylon.js 4.2 release in Nov. Many features will be working, but there will be some gaps. It would great if you can try it out and let us know how it goes.

If you have further questions, feel free to reach out to the team on the forum for faster responses.


[FHIR] Support for custom trust stores

The IBM FHIR Server ships with a default trust store which is set up to trust the fhir-client's client cert.
We also have an environment variable named SEC_TLS_TRUSTDEFAULTCERTS which defaults to true.
When true, the server will also trust anything that is trusted by the underlying java runtime.
However, for in-cluster dbs or certain managed dbs like the IBM Cloud Databases for PostgreSQL, we need the ability to configure the ibm-fhir-server with a custom trust store entry so that it can connect to the db over TLS.

We will enable the user to pass in their own keystore and truststore files via Secrets. The following values will be added to the values.yaml file to specify the Secret names:

keyStoreSecret
trustStoreSecret

For the truststore Secret, it will be expected to contain the content of the truststore file, the filename, and the password. The expected Secret keys are as follows:

Key
Value

fhirTrustStore
The contents of the truststore file

fhirTrustStoreFilename
The name of the truststore file

fhirTrustStorePassword
The truststore password

If a truststore secret is not specified, the default truststore will be used.

Small design update:
We will enable the user to pass in their own keystore and truststore files via Secrets. The following values will be added to the values.yaml file to specify the Secret names and file format:

keyStoreSecret
keyStoreFormat
trustStoreSecret
trustStoreFormat

For the truststore Secret, it will be expected to contain the content of the truststore file and the password. The expected Secret keys are as follows:

Key
Value

fhirTrustStore
The contents of the truststore file

fhirTrustStorePassword
The truststore password

If a truststore secret is not specified, the default truststore will be used.


Update last model

Hi @allemangD,
I found a bug loading the libraries. I've fixed them and updated the link to the lastest model :)
Thank you,
Gaelle

Apologies for the slow response on this PR. I do not have a suitable Windows machine to test this at the moment - however the changes make sense to me and the library loading looks to work correctly. I'll go ahead and merge.


WIP: I18N effort for dubbo code base - Polish

More details: #1044

Thank you very much for your effort.
I didn't noticed your PR, and i have just fixed the problem you mentioned in #1044 with commits from b04e83e24155ac5f20ac10f862993cb5fbabf9b0 to  0467e151b45588f907557f2656782898b7443544  .
Thanks again.


Fix "Prop editor: Right-click draws auto-tiles, instead of removing"

Fix: Prop editor: Right-click draws auto-tiles, instead of removing them #18

I must apologize in advance. As a high school student in a boarding school in China, I'm unable to use any electronic devices on campus, thus I can only address your feedback during the biweekly holiday. If there are any issues with this pull request and you are unable to reach me, please disregard or directly close this pull request for now. My apologies once again.


KeyError:<PHONE_NUMBER>.0

I just setup autobloody on NixOS, installed the gds driver by placing the jar file into neo4j's plugins directory and tried to run autobloody like so:
autobloody -u <user> -p '<password>' --host <dc_ip> -dp '<neo4jPassword>' -ds '<startUser>@<domain>' -dt '<domain>'

then I got the following error trace:
WARNING:neo4j.notifications:Received notification from DBMS server: {severity: WARNING} {code: Neo.ClientNotification.Statement.FeatureDeprecationWarning} {category: DEPRECATION} {title: This feature is deprecated and will be removed in future versions.} {description: The query used a deprecated field from a procedure. ('schema' returned by 'gds.graph.drop' is deprecated.)} {position: line: 1, column: 1, offset: 0} for query: "CALL gds.graph.drop('autobloody')"
[+] Done, 2 edges have been found between <startUser>@<domain> and <domain>

Authenticated as <user>:

Traceback (most recent call last):
  File "/nix/store/1rlgs2p487c9g4g3fs7lk0inkp9854wy-autobloody-0.1.8/bin/.autobloody-wrapped", line 9, in <module>
    sys.exit(main())
             ^^^^^^
  File "/nix/store/1rlgs2p487c9g4g3fs7lk0inkp9854wy-autobloody-0.1.8/lib/python3.12/site-packages/autobloody/main.py", line 89, in main
    automate.simulate()
  File "/nix/store/1rlgs2p487c9g4g3fs7lk0inkp9854wy-autobloody-0.1.8/lib/python3.12/site-packages/autobloody/automation.py", line 41, in simulate
    self._unfold()
  File "/nix/store/1rlgs2p487c9g4g3fs7lk0inkp9854wy-autobloody-0.1.8/lib/python3.12/site-packages/autobloody/automation.py", line 58, in _unfold
    raise e
  File "/nix/store/1rlgs2p487c9g4g3fs7lk0inkp9854wy-autobloody-0.1.8/lib/python3.12/site-packages/autobloody/automation.py", line 55, in _unfold
    self.rel_types[typeID](rel)
    ~~~~~~~~~~~~~~^^^^^^^^
KeyError:<PHONE_NUMBER>.0

For the sake of potential spoilers I censored usernames, passwords and domain names in the command and error logs above.

At the end I got the following error:
KeyError:<PHONE_NUMBER>.0

@CravateRouge

Oh my bad. Thanks for the explanation. I assumed there was an issue with autobloody itself.

But i know there is definetly a path with GenericAll in this example. I just looked in bloodhound again.
In this example I have a user that has GenericAll directly over another user. And I authenticated in autobloody using the user that has GenericAll.

It's alright, I agree the error is not very clear.
You can check the #Limitations section of the README to see which edges autobloody can handle. In your case I guess there is a path with edges supported by autobloody and others that you have to exploit using other tools. So you can use autobloody but only for parts of the path having only edges supported by autobloody


x/tools/internal/gocommand: documentation doesn't state what Run{,Piped,Raw} do and what they returns

There are 3 exported identifiers with the word "Run" in package golang.org/x/tools/internal/gocommand. None of them say what the identifiers do and what they return. Each one says "it's like this other Run variant". This makes it hard to know how to use the API of gocommand package.
// RunPiped is like Run, but relies on the given stdout/stderr
func (i *Invocation) RunPiped(ctx context.Context, stdout, stderr io.Writer) error

// Run calls Runner.RunRaw, serializing requests if they fight over go.mod changes.
func (runner *Runner) Run(ctx context.Context, inv Invocation) (*bytes.Buffer, error)

// RunRaw calls Invocation.runRaw, serializing requests if they fight over go.mod changes.
func (runner *Runner) RunRaw(ctx context.Context, inv Invocation) (*bytes.Buffer, *bytes.Buffer, error, error)

Documentation for Invocation.runRaw isn't readily visible because it's an unexported identifier:
// RunRaw is like RunPiped, but also returns the raw stderr and error for callers
// that want to do low-level error handling/recovery.
func (i *Invocation) runRaw(ctx context.Context) (stdout *bytes.Buffer, stderr *bytes.Buffer, friendlyError error, rawError error)

It has named return values that help.
The Runner type is documented as follows:
// An Runner will run go command invocations and serialize them if it sees a concurrency error.

Perhaps that should be made more visible on the methods, and their *bytes.Buffer and error results can be given names like stdout, stderr to help clarify what's what.
/cc @heschik

There have been a number of changes to this package recently, and the documentation has been improved as a result. Closing.


[ISSUE #316] Topic removal inconsistency

Remove consume queue and consume offsets in accordance with topic/consumer group removal in the master node
What is the purpose of the change
Bug fix.
Brief changelog
When topics in the master node are removed, logical consume queues in the slave node are correctly purged.
Verifying this change
Logical consume queue files are actually removed after applying this patch.
Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[ ] Run mvn -B clean apache-rat:check findbugs:findbugs checkstyle:checkstyle to make sure basic checks pass. Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test  to make sure integration-test pass.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

#316

@lizhanhui I will close the pr, we could discuss the complete proposal in the related issues


Refactor: Model

Simplify Likelihood Model

Codecov Report

Merging #14 (84eba45) into dev (955fbcc) will increase coverage by 0.08%.
The diff coverage is 73.91%.

@@            Coverage Diff             @@
##              dev      #14      +/-   ##
==========================================
+ Coverage   60.93%   61.02%   +0.08%
==========================================
  Files          57       57
  Lines        8259     8288      +29
  Branches     1637     1639       +2
==========================================
+ Hits         5033     5058      +25
- Misses       2789     2793       +4
  Partials      437      437

Flag
Coverage Δ

unittests
61.02% <73.91%> (+0.08%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

tf_pwa/model/opt_int.py
66.16% <50.00%> (+0.47%)
:arrow_up:

tf_pwa/model/model.py
54.09% <74.62%> (+1.95%)
:arrow_up:

Continue to review full report at Codecov.

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


time-machine test dependency is problematic for PyPy3

I'm sorry to be bothering you but the time-machine test dependency that is present right now makes it impossible to run over 200 tests on PyPy3. time-machine relies on patching internals of CPython's _datetime implementation, and as such is not installable on PyPy3 at all.
Could you please consider using e.g. pytest-freezer instead? This one's portable and works across all Python implementations.
Unfortunately, PyPy3 support became important right now because pydantic-core started using inline-snapshot, and its consumers do support PyPy3.

the time-machine problem is not so big. The PyPy3 support is a bigger problem. This could take a while.

Oh, I've assumed that the lack of time_machine is the only problem. But from a quick patch, indeed I've seem to be still getting 192 failures.
If that's any help, my patch was:
diff --git a/tests/conftest.py b/tests/conftest.py
index 5ef37fc..8a69dc2 100644
--- a/tests/conftest.py
+++ b/tests/conftest.py
@@ -268,8 +268,8 @@ import datetime
 import pytest

 @pytest.fixture(autouse=True)
-def set_time(time_machine):
-        time_machine.move_to(datetime.datetime(2024, 3, 14, 0, 0, 0, 0),tick=False)
+def set_time(freezer):
+        freezer.move_to(datetime.datetime(2024, 3, 14, 0, 0, 0, 0))
         yield
 """
             )

@mgorny could you please tell me if this fix would solve your issue for now?
I hope to provide support for pypy in the long term, but this might take a while.

and I also know that I have a "Programming Language :: Python :: Implementation :: PyPy" classifier in my pyproject.toml ... I will fix this too.

0.14.0 official supports pypy. But I removed the PYPY classifier because the code rewriting does not currently work.

Thanks!


Mesh Visualization Discrepancies in Habitat vs outside

Hi, I am running into some 3D transformation issues while visualizing rigid meshes from Habitat in a different viewer.
I was able to  export a rigid body mesh from Habitat and use it separately. I was also able to extract the transformation of the mesh using this.
Now when I visualize the mesh in a different viewer and try to also visualize the mesh by loading the mesh-file and transforming the vertices using new_verts = verts * rotmat + transl, the two meshes are not exactly the same. Screenshot is attached below:

Blue:  saved mesh exported from Habitat directly.
Green: mesh computed from saved transformations.

The translation seems right, but the rotation is off. Could this be an artifact of the discrepancies between the co-ordinate systems used by Habitat and my mesh-viewer software? I believe my viewing is in (x-right, y-forward, z-up) and Habitat uses (x-right, y-up, z-backward). To test this, I tried to transform the vertices between the co-ordinate systems before applying the transformations, new_verts = (C * verts) * rotmat + transl, where C is the rotation matrix between the two co-ordinate systems:
[1, 0, 0],
[0, 0, -1],
[0, 1, 0]

But this still doesn't seem to work. See attached screenshot:

Blue:  saved mesh exported from Habitat directly (same as previous screenshot).
Orange: mesh computed by first transforming with C and further applying saved transformations.

Any ideas what the issue might be? Thanks!

I was able to resolve this by converting my rotmat and transl into a homogenous transformation matrix (transf) and use the formula:

transf_new = C * transf * C_inv, where C is the transformation from Habitat co-ordinate system to mine, and C_inv is the inverse of C.

Then I was able to get the new vertices by: verts_new = transf_new * verts.


fix: sdkmath type in PoolSnapshot

Description
Closes: #XXXX
typo fixes

Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...

[ ] included the correct type prefix in the PR title
[ ] added ! to the type prefix if API or client breaking change
[ ] targeted the correct branch
[ ] provided a link to the relevant issue or specification
[ ] added a changelog entry to CHANGELOG.md
[ ] included comments for documenting Go code
[ ] updated the relevant documentation or specification
[ ] reviewed "Files changed" and left comments if necessary
[ ] confirmed all CI checks have passed

Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...

[ ] confirmed the correct type prefix in the PR title
[ ] confirmed ! in the type prefix if API or client breaking change
[ ] confirmed all author checklist items have been addressed
[ ] reviewed API design and naming
[ ] reviewed documentation is accurate
[ ] reviewed tests and test coverage
[ ] manually tested (if applicable)

Hey @saiSunkari19 can you also update go version to 1.19 to fix unit tests and include entry inside CHANGELOG.md? Thanks!

Sure, I will do that

Hi @saiSunkari19 yes please, thanks!

Hey @saiSunkari19 can you update go version to 1.18 on this line please? Thanks 👍🏻

Updated, Thanks


[KOGITO-9112] Fixing deadline functionality

This is a quick fix, I would open an additional JIRA so we can work quietly on nice automatic test for deadline functionality (but this is tricky, while the fix is clear)

(tests) - kogito-runtimes job #2451 was: ABORTED
Possible explanation: Most probably a timeout, please review

Reproducer
export BUILD_MVN_OPTS_CURRENT=-T 1C -Dvalidate-formatting -Prun-code-coverage
build-chain build cross_pr -f 'https://raw.githubusercontent.com/kiegroup/kogito-pipelines/main/.ci/pull-request-config.yaml' -o 'bc' -p kiegroup/kogito-runtimes -u https://github.com/kiegroup/kogito-runtimes/pull/2977 --skipParallelCheckout
NOTE: To install the build-chain tool, please refer to https://github.com/kiegroup/github-action-build-chain#local-execution

Please look here: https://eng-jenkins-csb-business-automation.apps.ocp-c1.prod.psi.redhat.com/job/KIE/job/kogito/job/main/job/pullrequest/job/kogito-runtimes.tests.kogito-runtimes/2451/display/redirect
Test results:

PASSED: 3274
FAILED: 0

Those are the test failures: none
See console log:

Console Logs
[2023-05-05T22:05:52.328Z] [INFO] Kogito :: Add-Ons :: Quarkus ....................... SUCCESS [  0.031 s][2023-05-05T22:05:52.328Z] [INFO] Kogito :: Rest Exception Handler :: Quarkus ........ SUCCESS [  8.398 s][2023-05-05T22:05:52.328Z] [INFO] Kogito :: Add-Ons :: Messaging ..................... SUCCESS [  8.125 s][2023-05-05T22:05:52.328Z] [INFO] Kogito Add-On Messaging - Parent ................... SUCCESS [  0.030 s][2023-05-05T22:05:52.328Z] [INFO] Kogito Add-On Messaging - Common ................... SUCCESS [ 50.095 s][2023-05-05T22:05:52.328Z] [INFO] Kogito Add-On Messaging ............................ SUCCESS [  1.412 s][2023-05-05T22:05:52.328Z] [INFO] Kogito :: Serverless Workflow :: gRPC:: Runtime .... SUCCESS [  1.547 s][2023-05-05T22:05:52.328Z] [INFO] Kogito :: Workitems :: RestWorkItem ................ SUCCESS [ 15.737 s][2023-05-05T22:05:52.328Z] [INFO] Kogito :: Serverless Workflow :: rest:: Runtime .... SUCCESS [  0.598 s][2023-05-05T22:05:52.328Z] [INFO] Kogito :: Add-Ons :: Kubernetes .................... SUCCESS [ 19.429 s][2023-05-05T22:05:52.328Z] [INFO] Kogito Add-On Kubernetes - Parent .................. SUCCESS [  0.049 s][2023-05-05T22:05:52.328Z] [INFO] Kogito Add-On Kubernetes Tests Utils ............... SUCCESS [  5.628 s][2023-05-05T22:05:52.328Z] [INFO] Kogito Add-On Kubernetes ........................... SUCCESS [03:09 min][2023-05-05T22:05:52.328Z] [INFO] Kogito :: Quarkus Serverless Workflow Extension .... SUCCESS [  0.150 s][2023-05-05T22:05:52.328Z] [INFO] Kogito :: Quarkus Serverless Workflow Extension :: Runtime SUCCESS [ 10.643 s][2023-05-05T22:05:52.328Z] [INFO] Kogito :: Serverless Workflow :: OpenAPI:: Common .. SUCCESS [ 12.090 s][2023-05-05T22:05:52.328Z] [INFO] Kogito :: Serverless Workflow :: OpenAPI:: Generated SUCCESS [  0.358 s][2023-05-05T22:05:52.328Z] [INFO] Kogito :: Serverless Workflow :: gRPC:: Parser ..... SUCCESS [  0.879 s][2023-05-05T22:05:52.328Z] [INFO] Kogito :: Serverless Workflow :: Rest:: Parser ..... SUCCESS [  8.884 s][2023-05-05T22:05:52.328Z] [INFO] Kogito Add-On Quarkus Common - Parent .............. SUCCESS [  0.059 s][2023-05-05T22:05:52.328Z] [INFO] Kogito Add-On Common - Deployment .................. SUCCESS [  6.974 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Kubernetes - Deployment .............. SUCCESS [ 43.336 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Messaging - Deployment ............... SUCCESS [  1.643 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Quarkus Workflows Extension :: Deployment  SUCCESS [  4.494 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Persistence :: Parent ......... SUCCESS [  0.030 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Persistence :: JDBC ........... SUCCESS [02:53 min][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Quarkus Persistence .................. SUCCESS [  0.052 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Persistence JDBC - Parent ............ SUCCESS [  0.062 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Persistence JDBC ..................... SUCCESS [  9.937 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Quarkus :: Events ............. SUCCESS [  0.027 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Events Process - Parent .............. SUCCESS [  0.047 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Events Process ....................... SUCCESS [  1.733 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Test Utilities :: Quarkus ................ SUCCESS [ 19.441 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Persistence JDBC - Deployment ........ SUCCESS [  4.599 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Events Process - Deployment .......... SUCCESS [  1.381 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Quarkus Workflows Extension :: Integration Tests SUCCESS [04:49 min][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Quarkus Workflows Extension :: Image Integration Tests SUCCESS [  02:44 h][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Quarkus Rules Extension :: Integration Tests SUCCESS [01:32 min][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Quarkus Rules Extension :: Integration Tests (Hot Reload) SUCCESS [02:01 min][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Quarkus Decisions Extension :: Integration Tests SUCCESS [02:14 min][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Quarkus Decicions Extension :: Integration Tests (Hot Reload) SUCCESS [01:47 min][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Quarkus Predictions Extension :: Integration Tests SUCCESS [ 40.576 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Quarkus Test List ........................ SUCCESS [  2.594 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Persistence :: Infinispan ..... SUCCESS [01:09 min][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Persistence Infinispan - Parent ...... SUCCESS [  0.036 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Persistence Infinispan ............... SUCCESS [  1.092 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Persistence Infinispan - Deployment .. SUCCESS [  1.573 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Persistence Infinispan Health Check .. SUCCESS [01:52 min][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Persistence Kafka Streams - Parent ... SUCCESS [  0.042 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Persistence Kafka Streams ............ SUCCESS [ 55.790 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Persistence Kafka Streams - Deployment SUCCESS [  0.899 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Persistence :: File System .... SUCCESS [ 12.422 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Persistence FileSystem - Parent ...... SUCCESS [  0.031 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Persistence FileSystem ............... SUCCESS [  0.517 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Persistence FileSystem - Deployment .. SUCCESS [  0.494 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Persistence :: MongoDB ........ SUCCESS [ 48.358 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Persistence MongoDB - Parent ......... SUCCESS [  0.056 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Persistence MongoDB .................. SUCCESS [  3.263 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Persistence MongoDB - Deployment ..... SUCCESS [  0.636 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Persistence :: PostgreSQL ..... SUCCESS [ 35.503 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Persistence PostgreSQL - Parent ...... SUCCESS [  0.036 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Persistence PostgreSQL ............... SUCCESS [  3.245 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Persistence PostgreSQL - Deployment .. SUCCESS [  1.754 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Persistence :: RocksDB ........ SUCCESS [ 14.423 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Persistence Rocksdb - Parent ......... SUCCESS [  0.035 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Quarkus Add-On Persistence Rocksdb .......... SUCCESS [  0.788 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Persistence Rocksdb - Deployment ..... SUCCESS [  1.128 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Process SVG :: Common ......... SUCCESS [ 12.340 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Process SVG - Parent ................. SUCCESS [  0.061 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Process SVG .......................... SUCCESS [ 19.105 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Process SVG - Deployment ............. SUCCESS [  1.458 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Process Management :: Common .. SUCCESS [  9.310 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Process Management - Parent .......... SUCCESS [  0.027 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Process Management ................... SUCCESS [ 14.310 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Process Management - Deployment ...... SUCCESS [  1.225 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Source Files :: Common ........ SUCCESS [  5.000 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Source Files - Parent ................ SUCCESS [  0.025 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Source Files ......................... SUCCESS [ 44.496 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Source Files - Deployment ............ SUCCESS [  9.129 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Knative :: Parent ............. SUCCESS [  0.028 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Knative :: Eventing ........... SUCCESS [ 13.290 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Knative - Parent ..................... SUCCESS [  0.025 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Knative Eventing - Parent ............ SUCCESS [  0.032 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Knative Eventing ..................... SUCCESS [  1.527 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Knative Eventing - Deployment ........ SUCCESS [ 19.275 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Knative Serving - Parent ............. SUCCESS [  0.092 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Knative Serving ...................... SUCCESS [01:01 min][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Knative Serving - Deployment ......... SUCCESS [  3.579 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Events :: Parent .............. SUCCESS [  0.027 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Events :: Event-Driven Decisions SUCCESS [ 20.199 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Events Decisions - Parent ............ SUCCESS [  0.029 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Events Decisions ..................... SUCCESS [  0.839 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Events Decisions - Deployment ........ SUCCESS [  2.282 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Events :: Event-Driven Predictions SUCCESS [ 11.462 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Events Predictions - Parent .......... SUCCESS [  0.044 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Events Predictions ................... SUCCESS [  1.273 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Events Predictions - Deployment ...... SUCCESS [  2.378 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Events :: Event-Driven Rules .. SUCCESS [  9.163 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Events Rules - Parent ................ SUCCESS [  0.063 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Events :: Event-Driven Rules :: Quarkus SUCCESS [  1.110 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Events Rules - Deployment ............ SUCCESS [  1.184 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Events :: MongoDB ............. SUCCESS [ 19.562 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Events MongoDB - Parent .............. SUCCESS [  0.053 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Events MongoDB ....................... SUCCESS [01:09 min][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Events MongoDB - Deployment .......... SUCCESS [  3.166 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Marshallers :: Parent ......... SUCCESS [  0.029 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Marshallers:: Avro ............ SUCCESS [ 11.110 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Quarkus:: Marshallers :: Parent SUCCESS [  0.030 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Quarkus:: Marshallers:: Avro:: Parent SUCCESS [  0.032 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Quarkus:: Marshallers:: Avro .. SUCCESS [  2.061 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Quarkus:: Marshallers:: Avro:: Deployment SUCCESS [  1.155 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Quarkus :: Camel :: Parent .... SUCCESS [  0.030 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Quarkus :: Camel :: Runtimes .. SUCCESS [ 10.642 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Quarkus :: Camel :: Deployment  SUCCESS [ 19.134 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Quarkus :: Camel :: Integration Tests SUCCESS [01:47 min][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Explainability ................ SUCCESS [ 12.695 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Explainability - Parent .............. SUCCESS [  0.035 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Explainability ....................... SUCCESS [  4.144 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Explainability - Deployment .......... SUCCESS [  1.247 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Explainability - Integration tests ... SUCCESS [ 49.785 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Jobs .......................... SUCCESS [  0.028 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Jobs :: API ................... SUCCESS [  8.565 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-Ons Quarkus Jobs Parent ................. SUCCESS [  0.034 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-Ons Quarkus Jobs Common - Parent ........ SUCCESS [  0.031 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-Ons Quarkus Jobs Common - Messaging ..... SUCCESS [  9.290 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-Ons Quarkus - Rest Callback ............. SUCCESS [ 14.710 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Jobs :: Management Common ..... SUCCESS [  5.444 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-Ons Quarkus Jobs Management - Parent .... SUCCESS [  0.034 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-Ons Quarkus Jobs - Management ........... SUCCESS [ 14.026 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-Ons Quarkus Jobs Management - Deployment  SUCCESS [  9.266 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-Ons Quarkus Jobs Messaging - Parent ..... SUCCESS [  0.028 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-Ons Quarkus Jobs - Messaging ............ SUCCESS [ 17.132 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-Ons Quarkus Jobs Messaging - Deployment . SUCCESS [  8.583 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-Ons Quarkus Jobs Knative Eventing - Parent SUCCESS [  0.027 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-Ons Quarkus Jobs - Knative Eventing ..... SUCCESS [ 18.489 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-Ons Quarkus Jobs Knative Eventing - Deployment SUCCESS [ 13.156 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: E-Mail :: Common .............. SUCCESS [  7.836 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Mail - Parent ........................ SUCCESS [  0.028 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Mail ................................. SUCCESS [ 52.121 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Mail - Deployment .................... SUCCESS [  1.918 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Monitoring .................... SUCCESS [  0.029 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Monitoring Core ............... SUCCESS [ 21.428 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Monitoring - Parent .................. SUCCESS [  0.089 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Monitoring Core ...................... SUCCESS [ 20.075 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Monitoring Prometheus Common .. SUCCESS [  1.030 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Monitoring Prometheus - Parent ....... SUCCESS [  0.060 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Monitoring Prometheus ................ SUCCESS [  6.335 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Monitoring Prometheus - Deployment ... SUCCESS [  2.242 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Monitoring Elastic Common ..... SUCCESS [  7.777 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Monitoring Elastic - Parent .......... SUCCESS [  0.031 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Monitoring Elastic ................... SUCCESS [  0.908 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Monitoring Elastic - Deployment ...... SUCCESS [  1.269 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Task Notification - Parent ........... SUCCESS [  0.041 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Task Notification .................... SUCCESS [  3.098 s][2023-05-05T22:05:52.329Z] [INFO] Kogito Add-On Task Notification - Deployment ....... SUCCESS [  1.548 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: Tracing ....................... SUCCESS [  0.028 s][2023-05-05T22:05:52.329Z] [INFO] Kogito :: Add-Ons :: TypedValue API ................ SUCCESS [  9.225 s][2023-05-05T22:05:52.330Z] [INFO] Kogito :: Add-Ons :: Tracing :: API ................ SUCCESS [  7.891 s][2023-05-05T22:05:52.330Z] [INFO] Kogito :: Add-Ons :: Tracing :: Common ............. SUCCESS [ 17.983 s][2023-05-05T22:05:52.330Z] [INFO] Kogito Add-On Tracing Decision - Parent ............ SUCCESS [  0.035 s][2023-05-05T22:05:52.330Z] [INFO] Kogito Add-On Tracing Decision ..................... SUCCESS [ 24.216 s][2023-05-05T22:05:52.330Z] [INFO] Kogito Add-On Tracing Decision - Deployment ........ SUCCESS [  4.937 s][2023-05-05T22:05:52.330Z] [INFO] Kogito Add-On Tracing Decision - Integration tests . SUCCESS [01:46 min][2023-05-05T22:05:52.330Z] [INFO] Kogito :: Add-Ons :: Task Management :: Common ..... SUCCESS [  0.690 s][2023-05-05T22:05:52.330Z] [INFO] Kogito Add-On Task Management - Parent ............. SUCCESS [  0.049 s][2023-05-05T22:05:52.330Z] [INFO] Kogito Add-On Task Management ...................... SUCCESS [  4.450 s][2023-05-05T22:05:52.330Z] [INFO] Kogito Add-On Task Management - Deployment ......... SUCCESS [  2.024 s][2023-05-05T22:05:52.330Z] [INFO] Kogito :: Integration Tests :: Quarkus ............. SUCCESS [  0.036 s][2023-05-05T22:05:52.330Z] [INFO] Kogito :: Integration Tests :: Quarkus :: OpenAPI Client Codegen SUCCESS [02:14 min][2023-05-05T22:05:52.330Z] [INFO] Kogito :: Integration Tests :: Quarkus :: Rules .... SUCCESS [ 55.694 s][2023-05-05T22:05:52.330Z] [INFO] Kogito :: Integration Tests :: Quarkus :: Decisions  SUCCESS [01:06 min][2023-05-05T22:05:52.330Z] [INFO] Kogito :: Integration Tests :: Quarkus :: RESTEasy Classic SUCCESS [ 48.303 s][2023-05-05T22:05:52.330Z] [INFO] Kogito :: Integration Tests :: Quarkus :: RESTEasy Reactive SUCCESS [ 46.489 s][2023-05-05T22:05:52.330Z] [INFO] Kogito :: Maven Plugin ............................. SUCCESS [  9.520 s][2023-05-05T22:05:52.330Z] [INFO] Kogito :: Integration Tests :: Maven Plugin ........  SUCCESS [01:40 min][2023-05-05T22:05:52.330Z] [INFO] Kogito :: DB Scripts Collection .................... SUCCESS [  0.707 s][2023-05-05T22:05:52.330Z] [INFO] Kogito :: Add-Ons :: Predictions ................... SUCCESS [  0.029 s][2023-05-05T22:05:52.330Z] [INFO] Kogito :: Add-Ons :: Predictions :: API ............ SUCCESS [  7.197 s][2023-05-05T22:05:52.584Z] [INFO] Kogito :: Add-Ons :: Predictions :: SMILE .......... SUCCESS [  9.777 s][2023-05-05T22:05:52.584Z] [INFO] Kogito :: Serverless Workflow :: OpenAPI:: Parser .. SUCCESS [  7.514 s][2023-05-05T22:05:52.584Z] [INFO] Kogito :: Serverless Workflow :: Fluent ............ SUCCESS [  1.728 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Serverless Workflow :: Executor:: Core ... SUCCESS [ 10.421 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Serverless Workflow :: Executor:: Rest ... SUCCESS [  9.467 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Serverless Workflow :: Executor .......... SUCCESS [  0.046 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Serverless Workflow :: Executor:: gRPC ... SUCCESS [  0.484 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Serverless Workflow :: Executor:: Tests .. SUCCESS [  9.770 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Spring Boot .............................. SUCCESS [  0.248 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Spring Boot :: BOM ....................... SUCCESS [  0.033 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Spring Boot ................... SUCCESS [  0.043 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: CloudEvents :: Spring Boot .... SUCCESS [  0.036 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Messaging :: Spring Boot ...... SUCCESS [  1.085 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Spring Boot :: Events - Parent  SUCCESS [  0.042 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Events :: Event-Driven Decisions :: Spring Boot SUCCESS [  0.529 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Events :: Event-Driven Predictions :: Spring Boot SUCCESS [  0.453 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Events :: Event-Driven Rules :: Spring Boot SUCCESS [  0.571 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Events :: SprintBoot :: Process :: Kafka SUCCESS [  2.389 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Events ::  MongoDB :: SprintBoot SUCCESS [ 17.413 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Spring Boot :: Starters Parent ........... SUCCESS [  7.265 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Spring Boot :: Starter :: Decisions ...... SUCCESS [  0.746 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Messaging :: Spring Boot (ITs)  SUCCESS [01:06 min][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Spring Boot :: Monitoring :: Parent SUCCESS [  0.030 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Monitoring Core Springboot .... SUCCESS [ 16.970 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Monitoring Prometheus Springboot SUCCESS [  0.924 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Monitoring Elastic Springboot . SUCCESS [  0.798 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Explainability :: Spring Boot Addon SUCCESS [ 11.198 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Spring Boot :: Starter :: Rules .......... SUCCESS [  0.138 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Spring Boot :: Starter :: Processes ...... SUCCESS [  0.482 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Spring Boot :: Starter :: Predictions .... SUCCESS [  0.142 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Spring Boot :: Starter ................... SUCCESS [  0.188 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Jobs :: Management SprintBoot Addon SUCCESS [ 11.036 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: E-Mail :: Spring Boot Addon ... SUCCESS [  1.039 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Task notification :: Spring Boot Addon SUCCESS [  0.884 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Tracing :: Spring Boot ........ SUCCESS [ 16.905 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Rest Exception Handler:: Spring Boot ..... SUCCESS [  9.667 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Process SVG :: Spring Boot Addon SUCCESS [ 14.221 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Process Management :: Spring Boot Addon SUCCESS [  9.006 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Task Management :: Spring Boot Addon SUCCESS [  0.509 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Spring Boot :: Kubernetes ..... SUCCESS [ 27.594 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Spring Boot :: Persistence :: Parent SUCCESS [  0.060 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Persistence File System :: Springboot SUCCESS [  0.290 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Persistence Infinispan :: Springboot SUCCESS [  0.779 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Persistence JDBC :: Springboot  SUCCESS [  0.831 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Persistence MongoDB :: Springboot SUCCESS [  1.481 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Add-Ons :: Persistence PostgreSQL :: Springboot SUCCESS [  1.734 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Spring Boot :: Maven Archetype ........... SUCCESS [03:28 min][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Test Utilities :: Spring Boot ............ SUCCESS [ 21.987 s][2023-05-05T22:05:52.585Z] [INFO] Kogito :: Integration Tests :: Spring Boot ......... SUCCESS [06:11 min][2023-05-05T22:05:52.585Z] [INFO] ------------------------------------------------------------------------[2023-05-05T22:05:52.585Z] [INFO] BUILD SUCCESS[2023-05-05T22:05:52.585Z] [INFO] ------------------------------------------------------------------------[2023-05-05T22:05:52.585Z] [INFO] Total time:  02:56 h (Wall Clock)[2023-05-05T22:05:52.585Z] [INFO] Finished at: 2023-05-05T18:05:52-04:00[2023-05-05T22:05:52.585Z] [INFO] ------------------------------------------------------------------------[2023-05-05T22:05:53.508Z] [ERROR] Error executing command mvn dependency:tree clean install  -s /home/jenkins/workspace/KIE/kogito/main/pullrequest/kogito-runtimes.tests.kogito-runtimes@tmp/config4014383366583134545tmp -Dmaven.wagon.http.ssl.insecure=true -Dmaven.test.failure.ignore=true -nsu -ntp -fae -e -Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false -Dmaven.wagon.httpconnectionManager.ttlSeconds=120 -Dmaven.wagon.http.retryHandler.count=3 -T 1C -Dvalidate-formatting -Prun-code-coverage  -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn -B. The process '/opt/tools/apache-maven-3.8.7/bin/mvn' failed with exit code 143[2023-05-05T22:05:53.508Z] [command]/usr/bin/docker system prune -f[2023-05-05T22:05:53.508Z] Deleted Containers:[2023-05-05T22:05:53.508Z] cf7ad50768be224eeca74208e53580a7be63b726887485996aa18dbba004ce92[2023-05-05T22:05:53.508Z] [2023-05-05T22:05:53.508Z] Deleted Networks:[2023-05-05T22:05:53.508Z] 0ef6b265-6491-4922-b38f-9aa31eb817ac[2023-05-05T22:05:53.508Z] [2023-05-05T22:05:53.508Z] Total reclaimed space: 7.87kB[2023-05-05T22:05:53.508Z] [INFO] Execution summary for kiegroup/kogito-runtimes[2023-05-05T22:05:53.508Z] # [BEFORE] [kiegroup/kogito-runtimes] export INTEGRATION_BRANCH=[2023-05-05T22:05:53.508Z] [INFO] OK [Executed in 0.215995 ms][2023-05-05T22:05:53.508Z]  [2023-05-05T22:05:53.508Z] # [BEFORE] [kiegroup/kogito-runtimes] bash -c "if [ ! -z '' ] && [ -f .ci/environments/update.sh ]; then .ci/environments/update.sh ""; fi"[2023-05-05T22:05:53.508Z] [INFO] OK [Executed in 7.545 ms][2023-05-05T22:05:53.508Z]  [2023-05-05T22:05:53.508Z] # [COMMANDS] [kiegroup/kogito-runtimes] export MVN_CMD=`bash -c "if [ '' = 'true' ]; then printf 'deploy  '; else printf 'install'; fi"`[2023-05-05T22:05:53.508Z] [INFO] OK [Executed in 5.766444 ms][2023-05-05T22:05:53.508Z]  [2023-05-05T22:05:53.508Z] # [COMMANDS] [kiegroup/kogito-runtimes] mvn dependency:tree clean install  -s /home/jenkins/workspace/KIE/kogito/main/pullrequest/kogito-runtimes.tests.kogito-runtimes@tmp/config4014383366583134545tmp -Dmaven.wagon.http.ssl.insecure=true -Dmaven.test.failure.ignore=true -nsu -ntp -fae -e -Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false -Dmaven.wagon.httpconnectionManager.ttlSeconds=120 -Dmaven.wagon.http.retryHandler.count=3 -T 1C -Dvalidate-formatting -Prun-code-coverage  -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn -B[2023-05-05T22:05:53.508Z] [INFO] NOT OK [Executed in 10603170.87604 ms][2023-05-05T22:05:53.508Z] [ERROR] The process '/opt/tools/apache-maven-3.8.7/bin/mvn' failed with exit code 143[2023-05-05T22:05:53.508Z]  [2023-05-05T22:05:53.508Z] # [AFTER] [kiegroup/kogito-runtimes] docker system prune -f[2023-05-05T22:05:53.508Z] [INFO] OK [Executed in 230.714248 ms][2023-05-05T22:05:53.508Z]  [2023-05-05T22:05:53.508Z]  [2023-05-05T22:05:53.508Z] # Uploading artifacts[2023-05-05T22:05:53.508Z] [INFO] Will not upload any artifacts in CLI environment[2023-05-05T22:05:53.508Z]  [2023-05-05T22:05:53.508Z] [ERROR] Failed to execute commands for kiegroup/kogito-runtimes[2023-05-05T22:05:53.508Z] [ERROR] Failed to execute mvn dependency:tree clean install  -s /home/jenkins/workspace/KIE/kogito/main/pullrequest/kogito-runtimes.tests.kogito-runtimes@tmp/config4014383366583134545tmp -Dmaven.wagon.http.ssl.insecure=true -Dmaven.test.failure.ignore=true -nsu -ntp -fae -e -Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false -Dmaven.wagon.httpconnectionManager.ttlSeconds=120 -Dmaven.wagon.http.retryHandler.count=3 -T 1C -Dvalidate-formatting -Prun-code-coverage  -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn -B :[2023-05-05T22:05:53.508Z] [ERROR] The process '/opt/tools/apache-maven-3.8.7/bin/mvn' failed with exit code 143[2023-05-05T22:05:53.513Z] script returned exit code 1[Pipeline] }[Pipeline] // withCredentials[Pipeline] }[2023-05-05T22:05:53.827Z] Deleting 1 temporary files[Pipeline] // configFileProvider[Pipeline] }[Pipeline] // scriptPost stage[Pipeline] junit[2023-05-05T22:05:53.933Z] Recording test results[2023-05-05T22:05:58.613Z] [Checks API] No suitable checks publisher found.[Pipeline] archiveArtifacts[2023-05-05T22:05:58.631Z] Archiving artifacts[Pipeline] script[Pipeline] {[Pipeline] sh[2023-05-05T22:05:59.817Z] + rm -rf console.log[Pipeline] sh[2023-05-05T22:06:00.107Z] + wget --no-check-certificate -qO - https://eng-jenkins-csb-business-automation.apps.ocp-c1.prod.psi.redhat.com/job/KIE/job/kogito/job/main/job/pullrequest/job/kogito-runtimes.tests.kogito-runtimes/2451/consoleText[2023-05-05T22:06:00.107Z] + tail -n 300


Implement From and Into for enums

The basic idea is to allow extraction of raw values from enums. So my hope was there would be actually some magic blanket implementation for Into. If there is a better way to avoid explicitly generating Into implementations please let me know.

rebased on main and merge as b58eb62e627f0215032259c78a45f2852fad3a8e :)

Thanks for also integrating the float matching changes !


OS keychain

Change log

Store private key in OS provided keychains instead of the store

Refactor keychain access across the app to reduce the amount of places where we fetch from the keychain (public key is stored in store which is easier to access, so updated all places that were getting the private key and deriving the public key to get the public key directly instead).

Mocked the keyring lib for testing the new keychain

Fixed broken tests

[ch17842]

Resolved comments. Updates LGTM and thanks for updating the mailbox tests.

Thanks for the quick review! Merging...


End game Screen

This story already partially implemented (there is an end screen with score/bricks/answers) so rest is now lower priority.
currently games ends with the game board disapperaing, and a screen appears that says "Game Over, your score, play again".
This story replaces "Game Over".
Instead randomly pick between one of the following:

"Cyberattack" (in big letters, rest in regular text) "you should have payed better attention to your supply chain. Better luck next time"
"Lawsuit" (in big letters, rest in regular text) "you should have payed better attention to your supply chain. Better luck next time"

in either case, follow with the score and play again as before.
Ideally the 'completed' game board would also show on this page (so you could see how you 'lost')

done and in production


TFTRT: Prevent segments with partially defined inputs for static mode

In static mode, If an input to a segment does not have a fully defined shape (exlcuding batch dim), we should prevent that segment from converting and fall back to native TF. TensorRT requires shapes to be defined in static mode. In some cases we would've caught the undefined shape by checks in certain ops but it was not reliable and the undefined shapes manifested in weird error messages.

I'm still not entirely sure about this. Do we expect partially defined input shapes to work in static mode?

I'm still not entirely sure about this. Do we expect partially defined input shapes to work in static mode?

I am not sure about that as well. Adding Lambda for that. I could not figure that out by quick read of the code.
I remember a discussion about the bucketing logic but not sure if that is already done and if that is part of TRTStatic orTRTDynamic.

I don't think unknown shapes can work with static mode because the static mode requires building the TRT engine which includes all the optimizations that depend on shapes. But this requirement is for the inputs of the TRT engine, and not necessarily for the inputs of the whole graph; in other words, it's possible that there are unknown shapes in the graph inputs but not in the TRT engine inputs. I think Trevor's change checks the shape of TRT engine inputs which is the right thing.


Does esm.sh work on China mainland?

Awesome work on esm.sh, thanks so much! I noticed that a CDN inside China was mentioned on the readme before, but it is now removed. Does esm.sh have good support inside China, like jsdelivr.com?

it works but vary slow, it's hard to say since China gov doesn't allow .sh domain even cloudflare can provide CDN in China.


Fixed the issue by setting the link HREF to # value

The Deploy test result looks good. LGTM.

The Deploy test result looks good. LGTM.

Merged!

Merged!


Community Overview Update

@lfbrock @jasonblais me again, re-wrote the Community Overview as what was posted was pretty tricky--when I read it, it sounded like we only farm out small, unimportant stuff to community, which is not accurate (e.g. Gyfcat, Docker, Desktop app, etc.).
I've re-written it to frame community as the overarching priority and Mattermost staff as paid members of community, customers as community as well able to accelerate features, but not dictate our destiny.
Feel free to edit and share feedback.
I think the page was going in somewhat the right direction, but it needed acceleration.

@it33 Thanks! At a quick glance the edits are definitely an improvement.
To increase discoverability, we should also consider moving or referencing this page elsewhere, given it only receives 1 or 2 views per day.
Have made a follow-up task to review more closely later. Will also review with Joram who might have feedback on the code contributor levels.


feat(STADTPULS-307): ensure device ID conforms to TTN pattern

This PR updates the yup schema for device IDs. We want to make sure that inputs conform to the allowed pattern in TTN. This PR does that validation and prevents the user from inputting invalid IDs (including an update hint to what went wrong).
If the TTN pattern changes or we include other integration types, we will have to update the pattern.
We cannot rely on frontend validation only and therefore we additionally need to update our DB to only accept the new schema as well. This is yet to be done.

@vogelino, I've added another commit (64655a3) that removes the regex check. I would argue that we should not validate something that is dictated from the outside and that can change at any time: What if suddenly _ ore uppercase letters will be allowed in TTN and we miss that?
Therefore I would rather say to only allow more characters here. Now we also have the tooltip that clarifies that the TTN and Stadtpuls device ID have to match.

Sidenote: I would still wait with the merge for the database migration, so that the allowed characters match in frontend validation and database type.

I would argue that we should not validate something that is dictated from the outside and that can change at any time
I agree with that. Good decision there. Well done! 👍


nixos/syncthing: move configuration to condigDir

Motivation for this change
Fix #47513
Things done

[x] Tested using a NixOS VM
[x] Fits CONTRIBUTING.md.

Would you mind adding a ref to "https://github.com/syncthing/syncthing/issues/3434#issuecomment-235401876" (or the issue itself) in the commit message?

Hm, is this too late to target 18.09? (Currently this PR updates 18.09 release notes.) I personally wouldn't mind seeing it land in 18.09, but it is short notice :-)

@bjornfor done. Thank you.

I moved the check to 19.03 for obvious reasons.

@joachifm done.

ping

Thank you all!

Thanks!


IP Tracker added

I have fixed issue #293 Kindly Review this.

Description 📜
Fixes #293

Type of change 📝
Please delete options that are not relevant. And in order to tick the check box just but x inside them for example [x] like this

[ x] Add a new project

Domain of Contribution 📊
Please delete options that are not relevant.And in order to tick the check box just but x inside them for example [x] like this

[x ] Project using HTML, CSS & JS

Checklist ✅
Please delete options that are not relevant.And in order to tick the check box just but x inside them for example [x] like this

[x ] I have performed a self-review of my own code or work.
[ x] I'm GSSoC'22 contributor

Screenshots / Gif (Optional) 📸
Add the screenshot of the changes you have made

@khushi-purwar I have added Readme file. Kindly review it.


Rebuilds with same value

I made rainbench to test the throughput of different libs and I am trying to add context_watch but it's not working. A mutation triggers a rebuild but the ValueNotifier has the same value. It works fine with ValueListenableBuilder.
Here is the code: https://github.com/jinyus/rainbench/blob/92f1742febd15cdecda5542768a1824098fe2a2f/lib/rain/value_notifier.dart#L47
class ContextWatchValueNotifierRain extends StatelessWidget {
  const ContextWatchValueNotifierRain({super.key});

  @override
  Widget build(BuildContext context) {
    final screenWidth = MediaQuery.of(context).size.width;
    return Stack(
      children: [
        // Cloud at top
        Clouds(screenWidth: screenWidth),
        const Progress(),

        // Raining drops based on beacon position
        for (int i = 0; i < rainDropCount.peek(); i++)
          Builder(
            builder: (context) {
              final startingLeftOffset = (screenWidth - totalRowWidth) / 2;
              final row = i ~/ columns;
              final col = i % columns;
              final val = cw.ValueListenableContextWatchExtension(
                valueNotifierObservable.observable,
              ).watch(context);

              return Positioned(
                left: startingLeftOffset + col * (dropWidth + dropSpacing),
                top: initialTopOffset +
                    row * dropSpacing +
                    200.0 * (1 + (val * .1)),
                child: const Icon(
                  Icons.water_drop,
                  size: dropWidth,
                  color: Colors.blue,
                ),
              );
            },
          ),
      ],
    );
  }
}

Looks like you forgot to wrap the MaterialApp in a ContextWatchRoot.

BTW, I'd recommend trying context_watch v2.0.0-dev.4 or later for the benchmark if possible as it should have a better performance.

Looks like you forgot to wrap the MaterialApp in a ContextWatchRoot. With context_watch v2+ you'd receive an error in this case.

Thanks, this fixed it, I'll use v2


Eng 1187 Script to automatically run gitbook snippets

Describe your changes and why you are making these changes
Script to run through Gitbook Python code snippets. Run through all of them except the ones that require lots of set up (integrations) or have workflow UUIDs hard-coded in.
Also fixes bugs discovered via running through the code snippets:

The monthly function instance type check incorrect for day (DayOfWeek --> DayOfMonth).
Fix DayOfMonth exception statement from "Invalid hour value" to "Invalid day value".
Fix assertion for bounds to work when bound_value is falsey (e.g. 0).

TODO: Get integrated into our Github Actions. Will work as a follow up task to determine the frequency to run this & get it set up (https://linear.app/aqueducthq/issue/ENG-2748/integrate-into-github-actions).
Related issue number (if any)
Eng 1187
Loom demo (if any)
Script output:
>> OK        parameters.md
>> OK        quickstart-guide.md
>> SKIPPING  (no Python snippets found) metrics-and-checks.md
>> SKIPPING  (no Python snippets found) faqs.md
>> SKIPPING  (no Python snippets found) SUMMARY.md
>> OK        artifacts.md
>> SKIPPING  (no Python snippets found) the-aqueduct-philosophy.md
>> SKIPPING  (no Python snippets found) operators.md
>> OK        README.md
>> OK        metrics-and-checks/preset-metrics-and-checks.md
>> OK        metrics-and-checks/checks-ensuring-correctness.md
>> OK        metrics-and-checks/metrics-measuring-your-predictions.md
>> SKIPPING  operators/configuring-resource-constraints.md
>> OK        operators/file-dependencies-in-python.md
>> SKIPPING  operators/specifying-a-requirements.txt.md
>> OK        operators/lazy-vs-eager-execution.md
>> OK        operators/creating-a-python-operator.md
>> SKIPPING  api-reference
>> SKIPPING  api-reference/sdk-reference
>> SKIPPING  api-reference/sdk-reference/package-aqueduct
>> SKIPPING  api-reference/sdk-reference/package-aqueduct/package-aqueduct.artifacts
>> SKIPPING  api-reference/sdk-reference/package-aqueduct/package-aqueduct.constants
>> SKIPPING  api-reference/sdk-reference/package-aqueduct/package-aqueduct.integrations
>> SKIPPING  api-reference/sdk-reference/package-aqueduct/package-aqueduct.models
>> OK        workflows/managing-workflow-schedules.md
>> OK        workflows/editing-a-workflow.md
>> SKIPPING  (no Python snippets found) workflows/README.md
>> OK        workflows/workflow-versions.md
>> SKIPPING  workflows/deleting-a-workflow.md
>> OK        workflows/creating-a-workflow.md
>> SKIPPING  integrations
>> SKIPPING  integrations/on-demand-resources
>> SKIPPING  integrations/data-systems
>> SKIPPING  integrations/data-systems/sql-systems
>> SKIPPING  integrations/data-systems/non-sql-systems
>> SKIPPING  integrations/compute-systems
>> SKIPPING  integrations/compute-systems/on-demand-resources
>> SKIPPING  integrations/adding-an-integration
>> SKIPPING  example-workflows
>> OK        guides/porting-a-workflow-to-aqueduct.md
>> SKIPPING  (no Python snippets found) guides/conquering-the-python-environment.md
>> SKIPPING  (no Python snippets found) guides/README.md
>> SKIPPING  (no Python snippets found) guides/debugging-a-failed-workflow.md
>> SKIPPING  installation-and-configuration
>> SKIPPING  installation-and-configuration/installing-aqueduct
>> SKIPPING  (no Python snippets found) notifications/connecting-to-email.md
>> SKIPPING  (no Python snippets found) notifications/connecting-to-slack.md
>> SKIPPING  (no Python snippets found) notifications/README.md
Congrats! You've successfully ran all code snippets in the documentation.

Error Output:
>> FAILED    parameters.md
-------------------------[CODE]-------------------------
from aqueduct import op, Client
import pandas as pd

client = Client()
db = client.integration("aqueduct_demo")

@op
def predict_churn(reviews: pd.DataFrame, country: str):
    ...

reviews = db.sql("Select * from customers")
country_param = client.create_param("country", default="Venezuela")
churn = predict_churn(reviews, country_param)

# This will return the result of `predict_churn()` with default "Venezuela" as the country input.
churn.get()

# This will return the result of `predict_churn()` with "United Kingdom" as the country input.
churn.get(parameters={"country": "United Kingdom"})
# This will create a new parameter directly, named `country`, with default value `Venezuela`.
churn = predict_churn(reviews, "Venezuela")
-------------------------[FAILED BLOCK]-------------------------
churn = predict_churn(reviews, country_param)
flow = client.publish_flow("Churn Prediction", artifacts=[churn])

...

import tim
# Sleep for 10 seconds to wait for flow to finish.
time.sleep(10)

# This will trigger a new run of the already published flow "Churn Prediction",
# but with the country parameter value set to "China".
client.trigger(flow.id(), parameters={"country": "China"})
-------------------------[ERROR]-------------------------
WARNING:Operator `predict_churn`'s argument `country` is not an artifact type. We have implicitly created a parameter named `predict_churn:country` and your input will be used as its default value. This parameter will be used when running the function.
Traceback (most recent call last):
  File "/Users/eunicechan/Desktop/aqueduct/regression_tests/tests/gitbook/_Users_eunicechan_Desktop_gitbook_parameters.py", line 27, in <module>
    import tim
ModuleNotFoundError: No module named 'tim'

>> OK        quickstart-guide.md
>> SKIPPING  (no Python snippets found) metrics-and-checks.md
>> SKIPPING  (no Python snippets found) faqs.md
>> SKIPPING  (no Python snippets found) SUMMARY.md
>> OK        artifacts.md
...

Checklist before requesting a review

[x] I have created a descriptive PR title. The PR title should complete the sentence "This PR...".
[x] I have performed a self-review of my code.
[x] I have included a small demo of the changes. For the UI, this would be a screenshot or a Loom video.
[N/A] If this is a new feature, I have added unit tests and integration tests.
[N/A] I have run the integration tests locally and they are passing.
[x] I have run the linter script locally (See python3 scripts/run_linters.py -h for usage).
[N/A] All features on the UI continue to work correctly.
[x] Added one of the following CI labels:

run_integration_test: Runs integration tests
skip_integration_test: Skips integration tests (Should be used when changes are ONLY documentation/UI)

Should we run this as a part of the release process?

@vsreekanti I think that's a good time to test. I can look into integrating it into the release script.

@kenxu95 Happy to chat about how we can integrate this into our testing process.
I think running it at release makes sense because it is not as frequent and that way we can be sure the code snippets work with the release version of Aqueduct. However, I think running it on every commit could also be useful to ensure that we are not committing code that does not work and spreads out the work more.
Maybe we can do a combination or just have it at one part of the process.


Make paltrace work on selected views

Calling _autolayoutTrace prints the entire view tree, regardless of which view it's called on, but _autolayoutTraceRecursively: prints the tree of the view it's called on.

works for me ¯\_(ツ)_/¯


Add guidance on tickets for UAA and Shibboleth

Changes proposed in this pull request:

Add guidance on tickets for UAA and Shibboleth

security considerations
Need to determine if public tix for routine updates are OK

@Chiakao @JoeLindsey87 @seanmbazemore @wz-gsa -- This WIP PR adds a few hints to ConMon on what to do with findings for UAA and Shibboleth. Should we fix the conflicts and merge, or close unmerged?


Shims: use _hypotf on Windows rather than __builtin_hypot

Unfortunately, hypotf is an inline in MSVCRT which forwards to
_hypotf.  This repairs the Windows build.

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

CC: @stephentyrone

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please test

@swift-ci please smoke test

This seems like it should eventually be fixed in the LLVM lowering of __builtin_hypotf rather than the standard library (I'm fine with taking it here as a quick fix, though). Can you file a bug against LLVM?

Yeap, filed https://bugs.llvm.org/show_bug.cgi?id=41366 for that

@swift-ci please smoke test

@swift-ci please smoke test and merge

@swift-ci please smoke test

@swift-ci please smoke test and merge

@swift-ci please smoke test Linux platform


No support for "Stack Depth Color"

Describe the bug
Cannot change color of Stack Depth field in Listing.
To Reproduce
Steps to reproduce the behavior:

Edit ~/.ghidra/tools/_code_browser.tcd
Add:

                <WRAPPED_OPTION NAME="Address Color" CLASS="ghidra.framework.options.WrappedColor">
                    <STATE NAME="color" TYPE="int" VALUE="-10066330" />
                </WRAPPED_OPTION>

Start Ghidra
Observe Stack Depth Field is still 0x0000FF blue.

Expected behavior
Color should change, option to change color should also be in Listing Tool's preferences.
Screenshots

Environment (please complete the following information):

OS: Windows 10
Java Version: 11
Ghidra Version: 9.2.4
Ghidra Origin: PUBLIC BUILD

Additional context
Why does the Listing Tool's color configuration tab appear as an option when "Stack Depth" is listed as an overall search term, when there is no option to change it?

Another thing that I couldn't figure out how to change is the segment comments: