Button alignment issue

Hey @SurajPratap10 ,
I have found a small alignment issue on the landing page.
**ISSUE reference: **
Issue 1.
https://github.com/SurajPratap10/Imagine_AI/assets/92604300/5b0a61c0-24a3-4d45-8eac-89499ac0e04d
As you can see the try it button is out of alignment and is also out of the viewport when the site is accessed

Issue 2.

as you can see the Generate button is too far down from the form
Solution:

I will fix the alignment with respect to the section above and below the button.
Add a smooth scroll for the button for a better user experience.
I will fix the alignment of the generate button.

Please assign me this issue under GGSOC 23'
Regards Priyam Maini.

Can you check the live site now @PR1YAM9 , Ig it's already fixed

Can you check the live site now @PR1YAM9 , Ig it's already fixed
I have checked just now it is Not fixed.


Number of OSS-Fuzz bugs vs Number of OSV-Fuzz Vulns

There are about 6000 OSS-Fuzz issues tagged as bug-security: https://bugs.chromium.org/p/oss-fuzz/issues/list?q=Type%3DBug-Security -status%3AWontFix%2CDuplicate&can=1
However, the OSS Fuzz Vuln Data only contains about 1500 Vulnerabilities. Why is that the case? It seems that early issues, like https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9&q=Type%3DBug-Security -status%3AWontFix%2CDuplicate&can=1, are not present?

Hi,
Yes, unfortunately we weren't able to backfill all of our data to the older ones, due to build system issues making bisection difficiult.


Dockerize OpenCollective

After a few frustrating attempts to setup an OpenCollective dev environment, it occurred to me I could start contributing to the project much sooner if there were a Docker-based setup for it. Hoping some kind soul who's got a better handle on things would be willing to package things up nice & neat. Or quick & dirty.

closing this for lack of activity.


coverage.thresholdAutoUpdate and coverage.perFile Conflict

Describe the bug
We're pretty strict on our unit testing goals, and have our thresholds applied at the per file, level, but we'd also like to take advantage of the really nice auto updating feature for continuous improvement.  However, when using coverage.thresholdAutoUpdate, the thresholds are bumped to corresponding with the global coverage achieved, and not the lowest file coverage achieved for each metric.  If coverage.perFile is set, the auto update should use the lowest individual file coverage for each of the four metrics, rather than the global coverage for its update.  With this conflict, there's no way to use both together.  The first test run will raise the threshold higher than the lowest individual file coverage, which results in a failed test run the second time.  We have to disable the auto update, when using perFile
e.g. in this example, the statement and branch thresholds should be set to 97.2 and 83.33, but instead are being set to 99.5, and 92.59
----------------------------------|---------|----------|---------|---------|-------------------
File                              | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
----------------------------------|---------|----------|---------|---------|-------------------
All files                         |   99.55 |    92.59 |     100 |   99.55 |
 findWorkspacesRoot               |     100 |      100 |     100 |     100 |
  findWorkspacesRoot.ts           |     100 |      100 |     100 |     100 |
  index.ts                        |     100 |      100 |     100 |     100 |
 hasConfigFile                    |     100 |      100 |     100 |     100 |
  hasConfigFile.ts                |     100 |      100 |     100 |     100 |
 hasDependency                    |     100 |    83.33 |     100 |     100 |
  hasDependency.ts                |     100 |    83.33 |     100 |     100 | 19,38
 isInMonorepo                     |     100 |      100 |     100 |     100 |
  isInMonorepo.ts                 |     100 |      100 |     100 |     100 |
 loadConfig                       |    97.2 |    95.23 |     100 |    97.2 |
  loadConfig.ts                   |    97.2 |    95.23 |     100 |    97.2 | 89-92
 loadConfig/__fixtures__/demo-lib |     100 |      100 |     100 |     100 |
  test.config.js                  |     100 |      100 |     100 |     100 |
 readNearestPackage               |     100 |       90 |     100 |     100 |
  PackageJson.ts                  |     100 |      100 |     100 |     100 |
  index.ts                        |     100 |      100 |     100 |     100 |
  readNearestPackage.ts           |     100 |    89.28 |     100 |     100 | 14,37,72

I searched existing issues for this, and don't see anything related to it.
Reproduction
Generating coverage folder doesn't seem to work in stackblitz?  Hopefully, the description is thorough enough.
System Info
System:
    OS: Windows 10 10.0.22000
    CPU: (12) x64 11th Gen Intel(R) Core(TM) i5-11500H @ 2.90GHz
    Memory: 7.56 GB / 31.67 GB
  Binaries:
    Node: 16.19.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 3.5.0 - C:\Program Files\nodejs\yarn.CMD
    npm: 8.19.3 - C:\Program Files\nodejs\npm.CMD

Used Package Manager
yarn
Validations

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

@michaelfaith is this coverage.provider: c8 or coverage.provider: istanbul specific, or both?

Thanks for the analysis / confirmation

Thanks for the quick turnaround on this!


Add code to ensure gdc-client v1.2.0 is blacklisted (resolves #210)

resolves #210
Fixed jenkins to show 1.2.0 (This should fail)

Expected failure!


Conformance rules change

Change proposed to pending proposed conformance rules
Relating to https://github.com/SciTools/iris/issues/5202,
A user expressed the opinion,  that data-variables should always reference

based on this para, notably "The use of the coordinates attribute is copied from the CF-conventions. It is used to map the values of variables defined on the unstructured meshes directly to their location"

A relevant rule would slot in here after R510,
something like "R511 it must list in its 'coordinates' attribute any mesh coordinates for the relevant location".

This is not obvious to me:
The coordinates attribute is a CF requirement. For UGRids, it's doesn't exactly make sense -- for example, a value may be associated with a cell face or edge -- defining it as such is a full definition. If you want to add CF coordinates, then usually one uses the centroid of the face or edge. Which can be useful for folks that want to easily plot the values, for instance. But it's not strictly a correct "location" of the value.
So I don't think it makes sense to require it in the UGRID spec.
If you want your file to be BOTH UGRUD and CF compliant, then the coordinates attribute will be required -- but it's up to CF compliance checkers to catch that.
I guess the short version is:
While UGRID is designed as an extension to CF, it should be possible to have a UGRID compliant file that isn't CF compliant.
As for iris -- it probably should add a coordinate attribute, as its goal is to be CF compliant as well.

@ChrisBarker-NOAA thanks for your view.  Enormously helpful, as I was really conflicted on this one.
But I still want more !...
When we wrote the Iris UGRID loader+saver, and when I drafted the ugrid conformance pages + checker, it was my opinion that this information was strictly redundant, so Iris does not do it + the checker does not require it.
However in https://github.com/SciTools/iris/issues/5202 some of our users were strongly of the opinion that UGRID requires it, based on the reading of the quoted para in the UGRID conventions :  I.E. that not doing it is a bug in Iris, and the Iris output is therefore not valid UGRID.
If you think it doesn't bear that interpretation, (that a coordinates entry on a mesh data-variable is required where applicable), that at least supports my original view of this !
But in that case, how would you counter that alternative reading of the UGRID para "The use of the coordinates attribute is copied from the CF-conventions."  -- how to you read that this does not imply it is required ?

My understanding, and intention for this proposed change is that, while not having a coordinates entry does not make it "invalid CF", we can add a requirement which would make this "invalid UGRID"
-- since the extra context which comes from a UGRID interpretation of the information does allow for that.
But I am very open to any statements from more experienced contributors, that this was not the original intent and is not generally a good idea.
See also #64

I see the text in the UGRID docs now:
"The use of the coordinates attribute is copied from the CF-conventions. It is used to map the values of variables defined on the unstructured meshes directly to their location: latitude, longitude, or other spatial coordinates,"
But I read that as "if it's optional in CF, it's optional in UGRID" :-)

My understanding, and intention for this proposed change is that, while not having a coordinates entry does not make it "invalid CF", we can add a requirement which would make this "invalid UGRID"

I would prefer it the other way around -- I think the coordinates attribute is unnecessary, and sometimes "wrong" for UGRID -- if a client is UGRID aware, it shouldn't be required, and maybe shouldn't be used.
I'm a bit surprised that CF doesn't require it, but that's their purview.

Clarifying note:
I'm speaking only for myself, but way back when, I questioned the "coordinates" attribute -- but is was recommended by CF, so we included it, specifically referring to CF.
In my mind, the practical reason for that was that a client that was CF-aware, but not UGRID-aware, could most likely do something useful with the file. Which is nice, I guess, but I'm more concerned with UGRID-aware applications :-)


Thresholded incomplete Cholesky decomposition failed due to insufficient positive-definiteness of matrix A with parameters:

Thresholded incomplete Cholesky decomposition failed due to insufficient positive-definiteness of matrix A with parameters:
discard_threshold = 1.000000e-04
shift = 0.000000e+00
Try decreasing discard_threshold or start with a larger shift
😺dzNodes: LayerStyle -> SegmentAnythingUltra Processed 10 image(s).
😺dzNodes: LayerStyle -> Warning: ImageBlendAdvance mask mismatch, dropped!
😺dzNodes: LayerStyle -> Warning: ImageBlendAdvance mask mismatch, dropped!
😺dzNodes: LayerStyle -> Warning: ImageBlendAdvance mask mismatch, dropped!
😺dzNodes: LayerStyle -> Warning: ImageBlendAdvance mask mismatch, dropped!
😺dzNodes: LayerStyle -> Warning: ImageBlendAdvance mask mismatch, dropped!
😺dzNodes: LayerStyle -> Warning: ImageBlendAdvance mask mismatch, dropped!
😺dzNodes: LayerStyle -> Warning: ImageBlendAdvance mask mismatch, dropped!
😺dzNodes: LayerStyle -> Warning: ImageBlendAdvance mask mismatch, dropped!
😺dzNodes: LayerStyle -> Warning: ImageBlendAdvance mask mismatch, dropped!
😺dzNodes: LayerStyle -> Warning: ImageBlendAdvance mask mismatch, dropped!
😺dzNodes: LayerStyle -> ImageBlendAdvance Processed 10 image(s).
😺dzNodes: LayerStyle -> ImageCombineAlpha Processed 10 image(s).

If the image is large or when processing video frames, it will prompt the above issue, and then comfyui will handle the interruption

If the  layer_image and layer_mask input sizes are inconsistent, the layer_mask input will be ignored. that for ImageBlendAdvance node.

If the image is large or when processing video frames, it will prompt the above issue, and then comfyui will handle the interruption

How large of  images did you deal with? I tested 4k video frames is works fine.

The process is to remove the background from a 40 second video. If the video is any longer, it will interrupt the comfyui due to errors

Try change to other detail_method

I have tried both the first and second ones, but the same error occurred. The third one cannot be used. My own analysis feels that the maximum value was not considered enough when designing the program. I hope the author can make changes and test it when they have time, as they often process videos of about 1 minute

Can you upload the video here? I will test it.

Sure, how can I send it to you, email or directly upload it here? Here are two tests for you to try

Please send to<EMAIL_ADDRESS>

I used  RmBgUltra V2 node to process video file result_2.mp4 , and set select_every_nth to 4 , that works fine.

😺dzNodes: LayerStyle -> RmBgUltra V2 Processed 300 image(s).
Prompt executed in 599.27 seconds

https://github.com/chflame163/ComfyUI_LayerStyle/assets/130118553/8f6127c1-e933-4d92-ab29-d5fb434266ac


MANGA Plus by SHUEISHA

Source request for MANGA Plus by SHUEISHA
Language: Multi

duplicate, i cant read


Fix reading WSL distributions from the registry

On Windows 11 the WSL registry list contains AppxInstallerCache entry which produces an exception when reading the distribution version.
This fix catches such registry exception but lets continue reading the next entries.
The registry list looks like:
Lxss
  |- {dist-uuid-1}  <- distribution
  |- {dist-uuid-2}  <- distribution
  |- ....
  |- AppxInstallerCache <- empty

Great thanks!


Sidecar: Block creation timing question, possible bug?

Note: logs are in reverse order in time (:
I've got some Prometheuses that are somewhat unstable, so they received some OOM kills. Basically that's one thing needed to be fixed on my end, but what I noticed where gaps in our data. Especially when both replica's are getting killed in the same 'block creation time'.
What I noticed is that Prometheus should/is (?) creating those blocks every 2 hours. We definitely also configured this hard (is the default but: tsdb.max-block-duration=2h  - Yet I only see Thanos shipping the block +1 hour after the restart (so 3 hours AFTER the restart). I expected 2 hours.

Logs of the sidecar, please check the times for "upload new block"
2021-05-11 15:00:22
level=info ts=2021-05-11T13:00:22.648159419Z caller=shipper.go:333 msg="upload new block" id=01F5DR6HG3AWDSJ3967V8N5WDN
2021-05-11 14:18:52
level=info ts=2021-05-11T12:18:52.661485079Z caller=shipper.go:333 msg="upload new block" id=01F5DNTGY1H1N9QQT02TM7MYAW
2021-05-11 11:18:50
level=info ts=2021-05-11T09:18:50.634547874Z caller=intrumentation.go:48 msg="changing probe status" status=ready
2021-05-11 11:18:50
level=info ts=2021-05-11T09:18:50.633820659Z caller=sidecar.go:165 msg="successfully loaded prometheus external labels" external_labels="redacted"
2021-05-11 11:18:48
level=warn ts=2021-05-11T09:18:48.590915263Z caller=sidecar.go:311 msg="failed to get Prometheus flags. Is Prometheus running? Retrying" err="request config against http://<IP_ADDRESS>:9090/api/v1/status/flags: Get \"http://<IP_ADDRESS>:9090/api/v1/status/flags\": dial tcp <IP_ADDRESS>:9090: connect: connection refused"
2021-05-11 11:18:46
level=warn ts=2021-05-11T09:18:46.582507762Z caller=sidecar.go:311 msg="failed to get Prometheus flags. Is Prometheus running? Retrying" err="request config against http://<IP_ADDRESS>:9090/api/v1/status/flags: Get \"http://<IP_ADDRESS>:9090/api/v1/status/flags\": dial tcp <IP_ADDRESS>:9090: connect: connection refused"
2021-05-11 11:18:46
level=info ts=2021-05-11T09:18:46.582227423Z caller=http.go:57 service=http/server component=sidecar msg="listening for requests and metrics" address=[<IP_ADDRESS>]:10902
2021-05-11 11:18:46
level=info ts=2021-05-11T09:18:46.582211452Z caller=intrumentation.go:60 msg="changing probe status" status=healthy
2021-05-11 11:18:46
level=info ts=2021-05-11T09:18:46.581962066Z caller=grpc.go:120 service=gRPC/server component=sidecar msg="listening for serving gRPC" address=[<IP_ADDRESS>]:10901
2021-05-11 11:18:46
level=info ts=2021-05-11T09:18:46.581831384Z caller=intrumentation.go:48 msg="changing probe status" status=ready
2021-05-11 11:18:46
level=info ts=2021-05-11T09:18:46.581555704Z caller=reloader.go:222 component=reloader msg="started watching config file and recursively rule dirs for changes" cfg= out= dirs=
2021-05-11 11:18:46
level=info ts=2021-05-11T09:18:46.581287856Z caller=sidecar.go:299 msg="starting sidecar"
2021-05-11 11:18:46
level=info ts=2021-05-11T09:18:46.580716051Z caller=factory.go:46 msg="loading bucket configuration"
2021-05-11 11:18:46
level=info ts=2021-05-11T09:18:46.58031115Z caller=grpc.go:93 service=gRPC/server component=sidecar msg="registering as gRPC StoreAPI and RulesAPI"
2021-05-11 11:18:46
level=info ts=2021-05-11T09:18:46.58020196Z caller=options.go:23 protocol=gRPC msg="disabled TLS, key and cert must be set to enable"
2021-05-11 11:18:46
level=info ts=2021-05-11T09:18:46.579921281Z caller=main.go:152 msg="Tracing will be disabled"
2021-05-11 11:00:43
level=info ts=2021-05-11T09:00:43.010821846Z caller=shipper.go:333 msg="upload new block" id=01F5DAF3009S3792EWMBHD2MDB
2021-05-11 09:00:43
level=info ts=2021-05-11T07:00:43.327962994Z caller=shipper.go:333 msg="upload new block" id=01F5D3KBXJQFCEFEC2336V610M
2021-05-11 07:00:42
level=info ts=2021-05-11T05:00:42.859121061Z caller=shipper.go:333 msg="upload new block" id=01F5CWQMG000N594R1TC481Z74

Once both Prometheuses have failures, as said before, I sometimes get this behaviour in the bucket:

This means missing data. If we check the Prometheus itself (i.e. the 'raw' data that still lives on the Prometheus), the data is actually still there.
If we visualize the logs for both Prometheus instances on the 'upload new block' we can also see this behaviour:

Versions used:
It's a mix of versions (:
The sidecars in question are still on 0.15, and yes this needs to be upgraded but yea..
The store + query components are 0.17.2
Prometheus versions are also a mix of versions, if this is important I could check a few versions.
My initial question
If we look at the restart time, why does it take 3 hours instead of the 2 hours I expected, to upload a block?
Other relevant things

Compactor is still not there on those specific blocks, so that's why they are still in that red form and missing other levels of compaction.
Since we run such an old version I checked the changelog for any specific related things, but could not find any.

One more person in Slack had this as-well

After debugging, I noticed we had a storage issue, causing to miss data. This resulted in this expected behaviour (:


Official Matrix support room

Matrix aims to be a successor of IRC.
https://matrix.org/

Matterbridge inserts the nick of the sender into the message. This is ugly.
I wonder if Matrix could be used to bridge with a more native-like experience.
There is already a bridged Gitter room. #gitter_elves=2Felvish:matrix.org
The Gitter users are represented like native users (even profile pictures are supported) with the difference that (Gitter) is appended to their names. Freenode users are bridged similarly, with puppet users.

For Telegram there is https://t2bot.io/telegram/ (can be self hosted) it uses puppet accounts aswell on the matrix side.

I gave Matrix a try. Initially I tried to use Matrix's bridges to replace Matterbridge, but the experience was less than ideal for several reasons:

The official Gitter integration is quite nonstable and drops messages
The Telegram bridge https://t2bot.io/telegram/ seems to be problematic either; I couldn't set up bridging with !tg bridge <id>
The format that the IRC bridge uses for reply is quoting the message being replied in <...> at the beginning; this seems to be not customizable, and worse than Matterbridge's format of quoting in (re: ...) at the end.

So I will just opt to treating Matrix as yet another IM bridged by Matterbridge. I have already created a room #elvish:matrix.org and I'll configure Matterbridge to bridge it with the other rooms, and document it.

Re Matrix providing a more native experience: the native experience is only available for Matrix and IRC users, because the flexibility of the Matrix protocol allows the bridge to create "puppet" accounts to mirror IRC/Gitter/Telegram on the Matrix side. Not exactly sure how the IRC side is implemented, but at least the IRC protocol makes it pretty easy to send messages under arbitrary nicknames, thus achieving an effect similar with puppeting.
For people using other IMs, especially Telegram and Gitter where most active users are on, messages from other IMs will still be sent by a bot run by the bridge.
Granted, some bridges have specific support for linking accounts in different IMs, so that they can send the message from the linked accounts, but that works against the idea of "using whichever IM you want" and come with security risks.

@xiaq The t2bot.io Telegram bridge has a notice:

If your user ID ends with :matrix.org then you will encounter some problems using t2bot.io - please register for an account elsewhere or run your own homeserver. Learn more

You have an account on matrix.org, maybe this was the problem.
The matrix.org IRC bridge and the matrix.org Gitter bridge also has performance issues.
Best solution would be running a custom Gitter bridge, plumbing the Matrix room to IRC, and invoking the Telegram bot. This way, Matrix and IRC users would have a protocol-native experience, and Gitter and Telegram experience would be nearly the same as now.

@notramo Ha, one would assume that matrix.org runs a decent Matrix server :) good to know that there are better choices though. Running my own server also sounds like a feasible choice.
My biggest problem now is the quoting format - it seems really non-ideal and not customizable. If it's easy to change them I'd consider switching :)

@xiaq I opened an issue at the IRC bridge repo.
Currently the solution I see mostly is that some IRC channel admins ask the Matrix users to not use the reply feature, but mention the user they are replying to.
I took a look at the conversation. Most of the traffic is from Gitter and Telegram, and only a very small amount of traffic comes from IRC (about 10-15%). Also, replies are very rare, so asking users not to use this function wouldn't bring too much change.
Also, if guest joins would be allowed in the Matrix room, then users could join the chat without registering on any homeserver (just like IRC). (Maybe some users use IRC only because it doesn't force them to register. In this case, they could use Matrix as well.)
Also, there are interesting IRC servers which use Matrix as backend. Maybe you should check them out.
https://github.com/matrix-org/matrix-ircd
https://github.com/nilsding/AgentSmith


Implement possibility of changing the order of the template parameters

In the current template implementation the string parameters in the template file is defined in a rigid order, it is not possible to put the injected texts into different positions than what is defined.
Implement naming of the injected text parameters to let the template define the exact position where the text goes independently of the order of the parameters.

This was done in v1.2.0


Replaced non-standard characters with ellipsis

Docs Build status updates of commit 2cb9e82:
:clock10: Full build: the average full build time is 32 min(s) 48 sec(s), this is based on the last 508 build(s) for this repository.

Docs Build status updates of commit 2cb9e82:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

azps-4.5.0/Az.Accounts/Add-AzEnvironment.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
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.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Support for windows vscode

Changes adds support for windows devices to the vscode plugin as a fix for #72 .
This was tested on:

Windows 10 Pro
Windows 7 Professional
MacOS Monterey

Thanks for working on this and testing on windows

Hey Davsclaus I found a small issue, that I want to resolve before this is merged. I'll update the PR later.


Fixing the test search pattern during the build process

@micdenny let's see if tests are picked up correctly.

it seems that AppVeyor is not happy if all the tests assemblies have the same name even if they live in different folders. The fix is easy even if time consuming, I'll raise an issue for all the repo.


Internationalized errors should depend spring-mvc-server

internationalized-errors should depend on spring-mvc-server to have ControllerAdvice and other needed dependencies

@pascalgrimaud I think this can be closed now.

Thanks @atomfrede !


Repo for Coroutines

Does this repo support coroutines?

Does this repo support coroutines?

This repo not support but you can browse my other repo. The repo supports coroutines.

Thank you for your support.


[bp/1.30] DynatraceResourceDetector: Change log level to debug

As discussed with @wbpcode I'm creating this backport to 1.30 for this small change. It just changes the log level to avoid unnecessary logs when the resource detector is added. Only back porting to 1.30 is enough, as we changed the error handling of the detector in after 1.29
Commit Message: Backport from #33564
Risk Level: Low
Testing: Manual
Docs Changes: No
Release Notes: No
Platform Specific Features: No
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

@joaopgrassi do we want to backport this any further?

@phlax no, I think 1.30 is enough. thanks!


Reset state between scenarios

Do we need to implement hooks? Or create a new interpreter?

@jowers @barneyfisher if we need hooks, this is going to require some more changes to Cucumber (nothing drastic, but changes nonetheless) so it's worth you having a think about how this will work in practice so we've got a clear idea of the success criteria. Have either of you had a chance to try this out on any real code yet?

I think we're going to try something tomorrow/Friday on some real code to see what happens...

From what we saw in the training today, I think creating a new interpreter per test case is the right default. If we find people want to opt out of that we can look at that later.

Ok, we've started to get a bit of feedback on this one. The main concern so far has been being able to connect, and disconnect from the db, which I think we'd need to do by implementing hooks.

Bear in mind that as of 314caa7f232d691dc0ec9571db5e548d70fd368e we're creating a new Tcl interpreter for each scenario. I think we can close this ticket and create new ones for hooks etc.


Edit the trace_signals() and report_signals() in Environment

Modify these methods to use a common internal signal_parser_method()

Modify the Reporter and Tracer classes where these methods are used.

Move the common code into the signal_parser_method()

Relates to #2052

Fixes #2052

@bgeltz can you please look at this?


Add opinionated container binding with podman

We should support a mechanism where some container images are "lifecycle bound" to the base bootc image.
The basics of this would look like any old boring podman-systemd unit.
However, the important thing is that these images would have a special annotation:
[Container]
Bootc=bound

And they'd be required to be fetched by sha256 digest (by default).  What would happen under the covers here is that bootc would hook into podman and:

disallow GC of these images even if the unit isn't running (for all deployments)
Fetch new images (from the new base container image) on bootc upgrade

In the automotive world we often think of containers as two possible things. Either they come with the system, and are updated atomically with it, or they are separately installed. They way we expect this to work is for the system ones to be installed in a separate image store that is part of the ostree image. And then the "regular" containers will just be stored in /var/lib/container.
The automotive sig manifests ship a storage.conf that has:
[storage.options]
additionalimagestores = [   /usr/share/containers/storage ]

Then we install containers in the image with osbuild like:
      - type: org.osbuild.skopeo
        inputs:
          images:
            type: org.osbuild.containers
            origin: org.osbuild.source
            mpp-resolve-images:
              images:
                - source: registry.gitlab.com/centos/automotive/sample-images/demo/auto-apps
                  tag: latest
                  name: localhost/auto-apps
        options:
          destination:
            type: containers-storage
            storage-path: /usr/share/containers/storage

This was part of the driver for the need of for composefs to be able to contain overlayfs base dirs (overlay nesting). Although that is less important if container/storage also uses composefs.

Quadlet supports .image files now which can be directly referenced in .container files.  Maybe that's a way to achieve a similar effect.
Cc: @ygalblum

Then we install containers in the image with osbuild like:

So IMO this issue is exactly about having bootc install and bootc update handle these images.  Because as is today, needing to duplicate the app images in an osbuild manifest is...unfortunate.  With this proposal, when osbuild is making a disk image, it'd use bootc install internally to the pipeline, and we wouldn't need to re-specify the child container images out of band of the "source of truth" of the parent image.

Then we install containers in the image with osbuild like:

So IMO this issue is exactly about having bootc install and bootc update handle these images. Because as is today, needing to duplicate the app images in an osbuild manifest is...unfortunate. With this proposal, when osbuild is making a disk image, it'd use bootc install internally to the pipeline, and we wouldn't need to re-specify the child container images out of band of the "source of truth" of the parent image.

I understand that, and I merely pointed out how we currently do it in automotive, not how it would be done with bootc.
Instead, what I propose is essentially:
Dockerfile:
FROM bootc-base
RUN podman --root /usr/lib/containers/my-app pull quay.io/my/app
ADD my-app.container /etc/containers/systemd

my-app.container:
[Container]
Image=quay.io/my/app
PodManArgs=--storage-opt=overlay.additionalimagestore=/usr/lib/containers/my-app

And then you have an osbuild manifest that just deploys the above image like any normal image.
Of course, instead of open-coding the commands like this, a tool like bootc install tool could do the right thing automatically.
You might also want the tool to tweak the image name in the quadlet to contain the actual digest so we know that the exact right image version is used every time.

Its also interesting to reflect on the composefs efficiency in a setup like this.
If we use composefs for the final ostree image, we will get perfect content sharing, even if each of the individual additional-image-stores use its own composefs objects dir. Even if no effort is made to try to share object files between image store directories. Because all the files will eventually be deduplicated as part of the full ostree composefs image.
In fact, we will even deduplicate files between image stores that use the traditional overlayfs or vfs container store formats.

In fact, maybe using vfs backend is the right approach here? It is a highly stable on-disk format, and its going to be very effective to start such a container. And we can ignore all the storage inefficiencies, because they are taken care off by the outer composefs image.

my-app.container:
[Container]
Image=quay.io/my/app
PodManArgs=--storage-opt=overlay.additionalimagestore=/usr/lib/containers/my-app

Just wanted to note that --storage-opt is a global argument. So, the key to use is GlobalArgs instead of PodmanArgs.

I wonder if we should tweak the base images to have a standardized /usr location for additional image store images.

/usr/lib/containers/storage?

You want that in the default storage.conf in containers/storage?

If you setup an empty additionalstore you need to precreate the directories and lock files. This is what we are doing to setup an empty AdditonalStore.   We should fix this in containers/storage to create these files and directories if they do not exists.

Yes that is the way it should work. If I have time I will look at it. Basically ignore the storage if it is empty.

cat /etc/containers/storage.conf
[storage]
driver = "overlay"
runroot = "/run/containers/storage"
graphroot = "/var/lib/containers/storage"
[storage.options]
pull_options={enable_partial_images = "true", use_hard_links = "false", ostree_repos=""}
additionalimagestores = [
"/usr/lib/containers/storage",
]

Additional store directory is empty
 ls -l /usr/lib/containers/storage/
total 0

podman info
...

So podman will write to the empty directory and create
# ls -lR /usr/lib/containers/storage/
/usr/lib/containers/storage/:
total 4
drwx------. 2 root root 4096 Nov 24 07:03 overlay-images

/usr/lib/containers/storage/overlay-images:
total 0
-rw-r--r--. 1 root root 0 Nov 24 07:03 images.lock

So podman will write to the empty directory and create the missing content.
If the file system is read-only it fails.
podman info
Error: creating lock file directory: mkdir /usr/lib/containers/storage/overlay-images: read-only file system

So, I've been thinking about the details around this for a while. In particular about the best storage for these additional image directories.  The natural approach would be to use the overlay backend, as we can then use overlay mounts for the actual container, but this has some issues.
First of all, historically, ostree doesn't support whiteout files. This has  been recently fixed, although even that fix requires adding custom options to ostree. In addition, if ostree is using composefs, there are some issues with encoding both the whiteouts as well as the overlayfs xattrs in the image. These are solved by the overlay xattr escape support I have added in the most recent kernel, although we don't yet have that backported into the CS9 kernel.
However, I wonder if using overlay directories for the additional image dir is even the right approach? All the files in the additional image dir will anyway be deduplicated by ostree, so maybe it would be better if we used an approach more like the vfs backend, where each layers is completely squashed (and then we rely on the wrapping ostree to de-duplicate these). Such a layer would be faster to setup and use (since it is shallower), and fix all the issues regarding whiteouts and overlay xattrs.
I see two approaches for this:

Use overlay backend with composefs format. This moves all the xattrs and whiteouts into the composefs image file, which will work fine in any ostree image
Teach the overlay container/storage backend the ability to squash individual layers, and then do this for all the images in the additional image store.

Opinions?

So there's two totally different approaches going on here (and the second approach has two sub-approaches):
Physically embed the app images in the base image
In this model, bootc upgrade and bootc rollback will also upgrade/rollback the system images "naturally", the same way as any other files.  (There's a lot of discussion above about the interactions with whiteouts/composefs/etc. though)
From the UX point of view, a really key thing is there is one container image - keeping the problem domain of "versioning/mirroring" totally simple.
However...note that this model "squashes" all the layers in the app images into one layer in the base image, so on the network, e.g. the base image used by an app changes, it will force a re-fetch of the entire app (all its layers), even if some of the app layers didn't change.
I think there's also the converse problem - unless we very carefully ensure that the podman pull or equivalent that generates the layer is fully reproducible (e.g. timestamps) it means any updates to the base image will generate a different squashed app layer, which is also quite problematic.  (Forcing a new storage in the registry)
In other words, IMO this model breaks some of the advantages of the content-addressed storage in OCI by default.  We'd need deltas to mitigate.
(For people using ostree-on-the-network for the host today, this is mitigated because ostree always behaves similarly to zstd:chunked and has static deltas; but I think we want to make this work with OCI)
Longer term though, IMO this approach clashes with the direction I think we need to take for e.g. configmaps - we really will need to get into the business of managing more than just one bootable container image, which leads to:
Reference the app images
Loose binding
In this model, the app images would only be referenced from the base image as .image files.
We would teach bootc install (i.e. at disk write time) to support "pre-pulling" container images referenced by /usr/share/containers/systemd/*.image files in the tree (using the credentials embedded in the base image) - but physically the container images live in /var in the final installed filesystem.
(There's an interesting sub-question here of whether we do this by default for .image files we find)
Anyways though, here these images are disconnected from the base image lifecycle; bootc upgrade/rollback would not affect them.  They can be fully uninstalled (though to do so the .image file would need to be masked).  Updates to them work by fetching from the registry directly.
A corollary to this is that for e.g. disconnected installs, the user must mirror all the application container images too.
This for example is the model used AFAIK by Fedora Workstation when flatpaks are installed - they are embedded in the ISO, but live in /var.
Strict binding
A key aspect of this would be that like "loose binding", the container images would be fetched separately from a registry.  For disconnected installs, the admin would need to mirror them all.  But we wouldn't lose all the efficiency bits of OCI.
This is what I was getting at originally; the images would still live in /var/lib/containers (I think), but bootc upgrade would enforce that the referenced .image files in the new root are pre-fetched before the next boot.
Hmm...more generally really I think we may need to drive something into podman where instead of .image files effectively expanding into an imperative invocation of podman pull, things like podman image prune would at least optionally know how to not prune the images.  On a bootc system, we'd make sure to wire things up so that podman would avoid pruning images referenced from .image files in both the booted root and the rollback.
That said, again once we switch to podman storage for bootc then it may just make more sense to physically locate the images in the bootc container storage and have bootc own all updates/GC.

I am sure someone has already invented this, but I think we should suppport a "rollup" OCI artifact that (much like a manifest list) is just a pointer to a bunch of other container images. A bit like the OCP "release image" except not an executable itself.

I saw this go by:
https://opencontainers.org/posts/blog/2023-07-07-summary-of-upcoming-changes-in-oci-image-and-distribution-specs-v-1-1/#2-new-manifest-field-for-establishing-relationships
Although, it seems like it's almost the inverse of what we want here.  I guess in the end, maybe things like "super image" are just a special case of manifest lists.

Some discussion about this on the podman side in https://github.com/containers/podman/issues/22785

One discussion that intersects with parts of this issue happened in https://github.com/containers/podman/discussions/18182#discussioncomment-5925088.  In short: we discussed how we can mark images to be un-removable.

Implemented in https://github.com/containers/bootc/pull/659.

@ckyrouac and I had a discussion and came up with a new proposed design. The original comment is edited but in a nutshell we propose to create /usr/lib/bootc/bound-images.d which is a symlink to existing .image files. We will error out if we detect systemd specifiers in use.

which is a set of symlinks to existing .image files. We will error out if we detect systemd specifiers in use.

I think binding it to Quadlet will hurt longterm maintenance as it breaks separation of concerns.  Having dedicated file of set of files in .d with a simple syntax doesn't run into the technical troubles.  There are use cases outside of running containers under systemd which wouldn't be forced to fiddle with Quadlet.
I won't block but still think that a new config file is cleaner and easier to maintain longterm.

I think binding it to Quadlet will hurt longterm maintenance as it breaks separation of concerns.

Can you edit the comment at the top that has the set of Pros/Cons and clarify your concerns there?
One thing I found compelling about the symlink approach is when I realized this downside with the separate file:

The admin only will need to bump a :sha256 digest in two places to update in general (both in a .container or .image and the custom .toml here)

However overall, I think we have explored the space pretty well and just need to make a decision and since @ckyrouac is doing the work I think it's his call, unless you have more information to add to the Pros/Cons.

Can you edit the comment at the top that has the set of Pros/Cons and clarify your concerns there?

Thanks, done :heavy_check_mark:

The admin will need to bump a :sha256 digest in two places to update in general (both in a .container or .image and the custom .toml here)

That's already the case.  The proposal doesn't cover .container or .kube files, so admins are forced to move things into .image files.

That's already the case. The proposal doesn't cover .container or .kube files, so admins are forced to move things into .image files.

This was only lightly touched on but it does currently cover .container files - we would parse those and find their referenced Image= and I expect that to be the default case. Handling .kube directly would be an obvious extension to that as well.

One other thing to ponder here is related to https://github.com/containers/bootc/issues/518
Basically if you look at this from a spec/status perspective; we effectively have a clear spec that is readable by external tooling: the "symlink farm". It's not reflected in bootc status - should it? I'm not sure.
What we don't directly have is status; while I think we'll end up doing the podman create in order to pin, that still allows things like podman system reset or just a plain podman rm -f. Should bootc also expose a status for this in our status fields? I think so.
Perhaps the status is just a boolean pinnedImagesValid: true|false (or maybe we go all the way to a condition).
I also wonder if we may need an explicit verb to re-synchronize in the case of a podman system reset? Or maybe just typing bootc upgrade again should do that.

@vrothberg can we dig in a bit into the high level design here of whether this should use additionalstores or not?
In the current code, it doesn't. I see pros and cons to both approaches.
One way to think about this is I see a continuum between "floating" "logically bound" and "physically bound".
With "physically bound" is that the images are officially read-only, podman rm isn't going to ever work, etc.
However...IMO, for logically bound images I can see people also wanting to do dynamic updates to them apart from a bootc upgrade. Yes, you might also queue an update to them on the base bootc image side, but for a number of workloads it could make total sense to do it dynamically outside of the host.
Take e.g. an OpenShift control plane node with etcd. We want etcd always there by default - but it's also totally sane and valid to rev etcd for a hotfix apart from updating the host.
The images being in the "default mutable /var/lib/containers" storage makes the use case of dynamic updates work pretty seamlessly I believe, whereas with a separate additional store I think introduces some confusion/friction there.
The choice of an additional

Tangential, but if we do choose to use an additional store, I think we should put it under /sysroot/ostree or so, making it visible to the host podman as /usr/share/bootc/storage or something?  It's basically where the host bootc storage is, and it's basically what https://github.com/containers/bootc/pull/215 is doing.

If you do an update on an image in the primary store, it will  use the tag in the primary store.
Example,  If I had alpine:latest in additional store and did a podman pull alpine and downloaded a different image into the primary store, then podman images and all tools would use the alpine:latest in the primary store.
This could be an issue if later we pulled an image into the bootc image additional store that is newer then the alpine in the primary store.
Bottom line for now we could just indicate in the .Image and .Container files to use an addional store to protect the images.  But this would force the quadlets to always use the images in the additionalstore.
The big advantage of the additional store, is we have it now, and do not need to wait for some future podman release.

@rhatdan It's a bit unclear to me, are you arguing for or against using an additionalstore by default for logically bound images? (And does the answer depend on "short term" vs "medium term"?)

I am giving point/counter point.  I don't think we necessarily want bootc to force an additional store, but we might want to take advantage of one in RHEL AI. A lot of this is talking out loud.
But I think we could just use standard stores and tell users "don't do that" if they attempt to do a podman image prune, bootc or starting a quadlet would pull the image.

As Dan mentioned, if you have image A in an additional store and force-pull it a newer one, it will be pulled into the primary store. The primary will always take precedence over additional stores when looking up local images.

This could be an issue if later we pulled an image into the bootc image additional store that is newer then the alpine in the primary store.

I think we can always construct a situation where the user may do something they shouldn't do.  We cannot protect against that.
I think additional stores are the way to go as they were designed with this use case (read-only images) in mind.
For Quadlets in general I see benefits of using additional stores as it's one more protection from the user accidentally removing an image.

OK. I'm increasingly convinced, however the basic mechanics of wiring this up are going to be somewhat nontrivial.

:new: https://github.com/containers/bootc/pull/659 landed with a very MVP functionality; however I think we should have basic docs and tests next.
Beyond "absolute MVP" functionality here is things like:

pinning the image (podman create) or using an additional store per above discussion

Can you also change the usr/lib/bootc-experimental/bound-images.d directory name to just /usr/lib/bootc/nound-images.d?

Can you also change the usr/lib/bootc-experimental/bound-images.d directory name to just /usr/lib/bootc/nound-images.d?

IOW you want the image to be not experimental and maintained ~forever?

I want the concept to be managed forever.
If RHEL AI uses it, We need it for the next X years.
If you change the format of the files, I don't care. but starting out with saying something is experimental in the RHEL world should be a non-starter.

We're already shipping things classified as experimental (xref https://github.com/containers/bootc/issues/690 ); I think it's an essential way to get feedback without committing to an interface immediately.
As far as stability, in theory we could allow usage of an experimental interface, but we just need to keep it around as long as the known consumers use it.
That all said, OK...the feature as is today is sufficiently small that perhaps it can just be stable to start for the next release.

I don't care if you document something as experimental, but putting it into the file system, makes it difficult to transition, when it is no longer experiemental.  I just want the directory renamed.

I don't care if you document something as experimental, but putting it into the file system, makes it difficult to transition, when it is no longer experiemental. I just want the directory renamed.

This was changed in https://github.com/containers/bootc/pull/714

OK, the more I play with this the more I am coming to the conclusion it makes sense to put bound images in the "bootc storage". Which...doesn't yet exist, but should. I will write up a separate issue.

So...an interesting semantic with logically bound images as they exist today (writing to the default shared /var/lib/containers) is that by default if you're tracking a floating tag (e.g. :latest) for the image, each time bootc upgrade is invoked we will only re-fetch the tag when the base image changes.
But...when that does happen, the updated bound image is immediately visible.
Some people will want to invoke e.g. bootc upgrade without rebooting just as a way to "pre-fetch" an upgrade.  In that scenario, if you have logically bound images, if any container referencing them happens to restart, it will suddenly see the new image.
It would hence feel more predictable to me if we made logically bound images default to only appearing in their referenced root. It is more likely that we can implement that on top of https://github.com/containers/bootc/issues/721 but it's still quite nontrivial.
OTOH...as I said in some other place I can actually see it being quite useful for users to pre-update logically bound images (can I acronym as LBI? just here?) ok yes LBIs outside of the default host update lifecycle.
But if we go that path...it seems certainly far cleaner to offer an explicit bootc image upgrade or so that explicitly doesn't touch the host, instead of just offering bootc upgrade which would do it via side effect?
Or...of course alternatively, bootc upgrade could check for all LBI updates (for versioned tags) even if the host image didn't change. That would feel more consistent too.

@ckyrouac opinions on :arrow_up:

Maybe we just for now strongly discourage floating tags for LBIs, and document the semantic that they will only update when the host changes.

Something I also am realizing related to this is that bootc upgrade --check won't give you any info for LBIs at all; i.e. we lose the ability to know how much data we'll download in advance at all. The users who choose to use this may not care...at first. But...this may argue for creating a build process that can ensure that the bootc base image's manifest can reference the LBIs at a metadata level.
There's a lot of advantages to that, but it would be Hard to do in a Containerfile flow today without going all the way to something like FROM oci-archive.

It would hence feel more predictable to me if we made logically bound images default to only appearing in their referenced root. It is more likely that we can implement that on top of https://github.com/containers/bootc/issues/721 but it's still quite nontrivial.

I think this makes the most sense. I haven't had a chance to look closely at your draft PR to use an additional store for bound images, but this is how I expect it to work. e.g. when upgrading a bootc system that has a new bound-image, we would pull the bound-image into the staged root's storage. This seems to make the most sense if the additional store will be in /usr which is not supposed to change. Since we'll no longer be using the shared storage, I think we'll need to first check the booted root for the image and copy it to the staged root to avoid re-downloading it, or something to avoid re-downloading the image every upgrade.
That doesn't address the issue of how to handle floating tags though. I'm not really sure how we can make binding to :latest be predictable since it will depend on when an upgrade happens, or what was on the build system when a disk is created, etc. I think the best we could do is be clear in our docs how floating tags will behave, make bootc status clearly show which version is booted/staged, maybe some lint checks to discourage using :latest (although there could be other floating tag names). I need to think about this more.

https://gitlab.com/fedora/bootc/examples/-/merge_requests/50


After manual install: Something went wrong while loading “kap-cam”

See issue #2 for discussion.
macOS version:    Ventura (13)
Kap version:      3.6.0
Something went wrong while loading “kap-cam”

Error: Cannot find module 'execa'
Require stack:
- /Users/bradleyturek/Code/kap-cam/index.js
- /Applications/Kap.app/Contents/Resources/app.asar/dist-js/plugins/plugin.js
- /Applications/Kap.app/Contents/Resources/app.asar/dist-js/plugins/index.js
- /Applications/Kap.app/Contents/Resources/app.asar/dist-js/index.js
-
    at Function.n._resolveFilename (electron/js2c/browser_init.js:257:1128)
    at Function.f._load (electron/js2c/asar_bundle.js:5:12913)
    at Object.<anonymous> (~/Code/kap-cam/index.js:4:15)

The issue is you need to run npm i after linking the package

https://youtu.be/R7CiiWRVdBw?si=rI94QCCylwaqoKGG
I made a video regarding how to fix the issue.

For future reference, the steps are:
cd ~/Library/Application\ Support/Kap/plugins/

npm remove kap-camera

git clone https://github.com/clearlysid/kap-cam

npm link ./kap-cam

sed -i '' 's/"dependencies": {/"dependencies": {\n    "kap-cam": "latest",/' package.json

npm link

After that restart Kap and record a video to test. You will have to allow camera and microphone access to Kap.

This fork works currently and includes the necessary installation steps in the README.

That fork repo sadly fails for me on npm link with npm ERR! Cannot destructure property 'name' of '.for' as it is undefined.


Clarify how a CSRF token is required to interact with the POST /login…

Added a section to the Login Server API's document to better clarify how to POST to the /login.do endpoint.

Coverage decreased (-0.09%) to 83.876% when pulling 6430d16f69f8064806aad1a322aba26a3152d0a8 on jrbudnack:master into 0e8552c3b1e576b5c834e924c9c670fae472265d on cloudfoundry:master.

Coverage decreased (-0.3%) to 83.71% when pulling 6430d16f69f8064806aad1a322aba26a3152d0a8 on jrbudnack:master into 0e8552c3b1e576b5c834e924c9c670fae472265d on cloudfoundry:master.

FYI - This is strictly a documentation change, no code.

Hi @jrbudnack,
Thank you for contribution.  We cherry-pick your changes against develop.  Look for your changes in the next release of UAA.  In the future, please make your pull request against develop instead of master.


ClipPath is not working properly on Android without clipRule prop

Bug

Looks like ClipPath has only id prop, but at the same time code below do not working properly on android without this prop
Environment info
 System:
    OS: macOS 10.15.5
    CPU: (8) x64 Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz
    Memory: 19.82 MB / 16.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 12.2.0 - ~/.nvm/versions/node/v12.2.0/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.5 - ~/.nvm/versions/node/v12.2.0/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Managers:
    CocoaPods: 1.9.1 - /usr/local/bin/pod
  SDKs:
    iOS SDK:
      Platforms: iOS 13.5, DriverKit 19.0, macOS 10.15, tvOS 13.4, watchOS 6.2
    Android SDK: Not Found
  IDEs:
    Android Studio: 3.6 AI-192.7<IP_ADDRESS>92135
    Xcode: 11.5/11E608c - /usr/bin/xcodebuild
  Languages:
    Java: 9.0.4 - /usr/bin/javac
    Python: 2.7.16 - /usr/bin/python
  npmPackages:
    @react-native-community/cli: Not Found
    react: 16.11.0 => 16.11.0
    react-native: 0.62.2 => 0.62.2
  npmGlobalPackages:
    *react-native*: Not Found

Library version: 12.1.0
Steps To Reproduce
Issues without reproduction steps or code are likely to stall.

Use code below
Try it with // @ts-ignore clipRule={'evenodd'} and without

Describe what you expected to happen:

It should work without it OR need to fix the TS (types)

Short, Self Contained, Correct (Compilable), Example
<Svg width={'100%'} height={'100%'} viewBox={'0 0 256 340'}>
              <Defs>
                <Rect
                  id={'backgroundRect'}
                  x={-1}
                  y={-1}
                  width={258}
                  height={342}
                  fill={BACKGROUND_COLOR}
                />
                <Rect
                  id={'faceOvalRect'}
                  x={1}
                  y={1}
                  width={254}
                  height={338}
                  ry={127}
                  stroke={'#fff'}
                  strokeWidth={2}
                />

                <ClipPath
                  id={'clip'}
                  // @ts-ignore
                  clipRule={'evenodd'}
                >
                  <G>
                    <Use href={'#backgroundRect'} />

                    <Use href={'#faceOvalRect'} />
                  </G>
                </ClipPath>
              </Defs>

              <Use
                href={'#backgroundRect'}
                clipPath={'url(#clip)'}
                clipRule={'evenodd'}
              />

              <Use href={'#faceOvalRect'} />
            </Svg>

Yep, that was my problem too. Thanks for this

I tested the property and it works perfectly, just the type for this component was not added. So I opened a PR with a fix for this issue.

Fixed in<EMAIL_ADDRESS>

@magicismight
why the new version does not follow semantic version rules? is it a stable version or an RC version? (I think just 12.1.1 was better)
also, please consider updating the changelog if you have time for it. Thanks

@magicismight
why the new version does not follow semantic version rules? is it a stable version or an RC version? (I just think 12.1.1 was better)
also, please consider updating the changelog if you have time for it. Thanks

@magicismight
why the new version does not follow semantic version rules? is it a stable version or an RC version? (I just think 12.1.1 was better)
also, please consider updating the changelog if you have time for it. Thanks

It's a RC version, I will release 12.1.1 later.

it looks like it's already marked as latest on npm

@hehex9 is right, it's marked as the latest version on npm.

I finally got around this issue with an odd solution! (I also update react-native-svg to12.1.1 but no luck)
It was working fine in iOS even without clipRule parameter, so I ended up changing clipRule to its other variant whenever the props.data was changing (only when the device is android). so this is my workaround that works on both iOS and android:
    const [clipRule, setClipRule] = React.useState('evenodd')
    React.useEffect(()=>{
     if(Platform.OS === 'android') {
       setClipRule(clipRule==='evenodd' ? 'nonzero' : 'evenodd')
     }

and finally give this clipRule state as a prop to your <ClipPath/> component, like:
    <ClipPath id={"clip"} clipRule={clipRule} >
     ...
    </ClipPath>

I wish I was kidding but this works!

It worked for me, but I need to add clipRule not for ClipPath
<Defs>
  <ClipPath id="testClipPath">
    <Path d={myPath} />
  </ClipPath>
</Defs>

<Rect clipRule={Platform.isAndroid ? 'nonzero' : 'evenodd'} clipPath="url(#testClipPath)"/>

It worked for me, but I need to add clipRule not for ClipPath
<Defs>
  <ClipPath id="testClipPath">
    <Path d={myPath} />
  </ClipPath>
</Defs>

<Rect clipRule={Platform.isAndroid ? 'nonzero' : 'evenodd'} clipPath="url(#testClipPath)"/>

Does anyone know why this can be fixed by setting clipRule to nonzero


Logs saved to catalog as an option

The executor should have a configurable option:
save-logs-in-catalog: True or False
If True, we should save the logs in the catalog.
If False, we should just print it without any saving.

The logs are saved to the catalog as default. NOT customisable.


React-Query proof of concept

After discussion with WMA technical leads, react-query was proposed as an API lifecycle management hook package that can replace react-redux-saga. This requires a proof of concept of how this would work:

Write a context provider to propagate auth information
Use js-cookie to locally persist tokens between page refreshes
Restructure tapis-redux hooks to instead return react-query hooks for operations

won't do.


mixin does not accept a content block - sass

Laravel Mix Version: 1.6.1
Node Version: 8.7.0
NPM Version: 5.5.1
OS: MacOS High Sierra (10.13.1)

Description:
When compiling sass I get the following error:
Module build failed:
			@include placeholder {
           ^
      Mixin "placeholder" does not accept a content block.

Mixin definition:
@mixin placeholder {
    &::-webkit-input-placeholder {@content}
    &:-moz-placeholder           {@content}
    &::-moz-placeholder          {@content}
    &:-ms-input-placeholder      {@content}
}

Usage:
@include placeholder {
    font-style:italic;
    color: lighten($default-text-color, 20%);
}

I dont know a huge amount about sass (just the basics) and this code comes from a theme I have purchased. From what I have googled this code appears to be valid, so I am not sure if this is an issue with mix or not.

It seems to work in a codepen: https://codepen.io/anon/pen/pddqmM


Internal interfaces on class are not part of public API

See
https://twitter.com/terrajobst/status/773905057909645315
Internal interfaces declared on a class are not part of the public API.

@JakeGinnivan ping. AppVeyor build seems to fail because it can't find the solution

@JakeGinnivan would be able to get this in somehow. Please see also https://github.com/JakeGinnivan/ApiApprover/pull/22#issuecomment-252714326 I don't want to be THAT guy stressing you around.

@danielmarbach I hate to do this but I'm slammed at work right now and prob wont get back on top of my OSS emails and such for another month or so. Have added you as a contributor and owner of the nuget package. Ping me at<EMAIL_ADDRESS>if you need anything else :)

Release the 4.2.0 version and retrofitted the release for 4.1.0. Wasn't able to upload the nuget package for the Public Api Generator  since I don't have access there yet. As soon as I have it I will upload the package


Please modify the Web_Config.xml to include the Core 1.0 settings by default

As described in #114 , one has to manually add some lines to the "Web_Config.xml" file to make .NET Core websites work correctly with Let's Encrypt.
My suggestion is to include the lines directly into the "Web_Config.xml" file by default.
Currently I see no drawbacks for non-.NET-Core websites.
The benefit would be that I do not forget to add the links again in every new release.

I've just looked at Rick Strahl's blog article.
I was able to add the following lines to the "Web_Config.xml" and got it working:
<handlers>
  <clear />
  <add name="StaticFile" path="*" verb="GET" modules="StaticFileModule" resourceType="Either" />
</handlers>

So my suggestion is to add the above lines by default.

We can't do that because the <handlers> section is locked by default and therefore adding those lines would cause errors for some users. There are many problems with FileSystem validation so it's basically a legacy mode nowadays. I would advise anyone to use SelfHosting mode, or if that doesn't work IIS mode. Both of them fix the handlers problem and many others.

Thanks, @WouterTinus, I'll try that (I start right now trying to understand what these other modes actually mean).


Data discrepency

While using Api it seems that school holidays in Hessen (HE) last over two years and in Rheinland-Pfalz (RP) as well, seems like the end date is wrong for these entries, but the year information is correct.
e.g. see entries 1 and 7
Can you give me an update on it? It would be really helpful.

@paulbrejla thank you for this great API!
This issue relates to the PRs here and here. Any plans to merge them soon?

Merged them @darian-heede

Thank you @paulbrejla! Any plans on reviewing and merging the other open PRs? We still have a few errors in the data as is.

Merged all of the existing PRs.


Fix issue 357 by adding include

Fix issue 357 by adding include
Fixes #357
Task List

[x] Defined the tests that specify a complete and functioning change (It may help to create a design specification & test specification)
[x] Implemented the source code change that satisfies the tests
[x] Documented the feature by providing worked example
[x] Updated the README or other documentation
[x] Completed the pre-Request checklist below

Change Description
I added #include  to IIceAlbedo.hpp, which gives the compiler the information it needs to compile the program.
This behaviour appears to be compiler dependent, as it only appears (so far) with g++ version 12.3.0. But including the tuple header file shouldn't hurt with other compilers.

Test Description
The GitHub actions tests should cover this, but the behaviour is compiler version specific.

Documentation Impact
None

Other Details
None

Pre-Request Checklist

[x] The requirements of this pull request are fully captured in an issue or design specification and are linked and summarised in the description of this PR
[x] No new warnings are generated
[x] The documentation has been updated (or an issue has been created to track the corresponding change)
[x] Methods and Tests are commented such that they can be understood without having to obtain additional context
[x] This PR/Issue is labelled as a bug/feature/enhancement/breaking change
[x] File dates have been updated to reflect modification date
[x] This change conforms to the conventions described in the README

[] Compiles on ubuntu:rolling (g++ 12.3.0)
[] GitHub build-and-tests-on-ubuntu and -mac pass


Async await with d3 fetch functions?

Hi, is it not possible to use Async/Await with d3-fetch?
i tried doing this:
import * as d3Fetch from "d3-fetch";

async getData() {
     const india = await d3Fetch.json('/data/IND.json');

     return india;
    },

it returned a Promise instead.
PS: currently, i have to save .geojson as .json file format. Feels counter-intuitive? Any plans to add support to read .geojson files?

Async-await works great with d3-fetch and we use it in Observable regularly. Here is an example I found:
https://beta.observablehq.com/@jermspeaks/async-await


CodeLingo Setup

Hi there,
I made a PR recently that fixed some function comments. This one will make CodeLingo review your PRs and find similar issues automatically. It will find issues from the Effective Go bundle, and the Code Review Comments bundle. You just have to merge this PR and install the the CodeLingo GitHub App.
Let me know if this is useful :smile: also, let me know if there's an official channel I should go through to get this discussed properly.

if all the PRs are as useful as the earlier one, i'd vote no on this

Closing this. Please re-open if needed.


rotation matrix returned not in SO(3)

The code runs fine, but both of our solutions R1 and R2 are reflections, i.e., they are orthogonal but have -1 determinant.  The translation vectors look correct.  Could this be because IPPE thinks we are looking at the planar object from behind?  If this is the problem, how do we enforce the front-facing constraint? If not, what could it be?

That is strange because the algorithm enforces R1 and R2 are reflections. Can you please email me the input data (model points and normalized image points), and I will test with the Matlab implementation.
Thanks, Toby

Hi Toby -- I just sent an email to the gmail account listed on page 1 of the IPPE paper that I downloaded from arxiv.
-Charlie

Hi Charlie,
nice to hear from you and the kind words. I'm glad you're finding this work
useful. I'm just on my way home now. I know exactly what this is about. For
now, can you just run IPPE using 2D model points (a 2xN vector of model
points). You should do this when the model points are on the plane z=0.
It's quicker because there is no 3x3 SVD computation. If you do this, all
should be fine. I'll message you with the fix to ensure the problem you had
does not occur.
And I'm a big fan of Tesla!
Best regards, Toby
Le 23 mars 2017 6:01 PM, "cfreundlich"<EMAIL_ADDRESS>a écrit :
Hi Toby -- I just sent an email to the gmail account listed on page 1 of
the IPPE paper that I downloaded from arxiv.
-Charlie
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/royxue/ippe_py/issues/2#issuecomment-288788419, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ARe8ZU2Pjs3TzBukriQw_bI-TysWNsynks5roqVRgaJpZM4Mm9a4
.

Now the matrices are in SO(3).  Thanks!

Solved.
Issue closed ;)


Add NPI help link to facility form

Description
Users frequently have questions about the NPI field in the facility form, and we should connect them to the search functionality in the same way we do CLIA number.
Proposed solution
Add this link to the NPI field as search helper text ("Find my NPI"): https://npiregistry.cms.hhs.gov/

Look into auto populating NPI for schools


Add transform argument for Web3RpcRequest

Web3RpcRequest(
    method = "eth_sendRawTransaction",
    params = listOf(signedTransaction),
    paramsSerializer = String.serializer(),
    resultSerializer = String.serializer(),
    transform = ::TransactionHash
)

@Alex009, what do you think about such a thing?
It's useful for cases when we want to wrap request result in typed stuff like on screenshot below:

Now that works fine and I can add a request to the separate entity, but when I try to use it with a batch request, it becomes kinda verbose because I have a String output, but not a TokenCryptoCurrency? one.

@y9san9 yes, good idea

For example, the network cannot be extracted from the string and I will make custom serializer like TokenCryptoCurrencySerializer(network)


fix storageSize must have B unit.

修复storageSize配置成MB单位，在启动后会通不过k8s验证的BUG。

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.zery seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Could close the pr, it have fixed by official.


URL: /Service/PXPCommunication.asmx?WSDL not found

Here's the full trace:
Traceback (most recent call last):
  File "E:\Programming stuff\studentvue\main.py", line 3, in <module>
    sv = StudentVue('<username>', '<password>', '<domain>')
  File "C:\Users\milkyway90\AppData\Local\Programs\Python\Python310\lib\site-packages\studentvue\StudentVue.py", line 60, in __init__
    self.client = zeep.Client(
  File "C:\Users\milkyway90\AppData\Local\Programs\Python\Python310\lib\site-packages\zeep\client.py", line 76, in __init__
    self.wsdl = Document(wsdl, self.transport, settings=self.settings)
  File "C:\Users\milkyway90\AppData\Local\Programs\Python\Python310\lib\site-packages\zeep\wsdl\wsdl.py", line 92, in __init__
    self.load(location)
  File "C:\Users\milkyway90\AppData\Local\Programs\Python\Python310\lib\site-packages\zeep\wsdl\wsdl.py", line 95, in load
    document = self._get_xml_document(location)
  File "C:\Users\milkyway90\AppData\Local\Programs\Python\Python310\lib\site-packages\zeep\wsdl\wsdl.py", line 155, in _get_xml_document
    return load_external(
  File "C:\Users\milkyway90\AppData\Local\Programs\Python\Python310\lib\site-packages\zeep\loader.py", line 89, in load_external
    content = transport.load(url)
  File "C:\Users\milkyway90\AppData\Local\Programs\Python\Python310\lib\site-packages\zeep\transports.py", line 123, in load
    content = self._load_remote_data(url)
  File "C:\Users\milkyway90\AppData\Local\Programs\Python\Python310\lib\site-packages\zeep\transports.py", line 136, in _load_remote_data
    response.raise_for_status()
  File "C:\Users\milkyway90\AppData\Local\Programs\Python\Python310\lib\site-packages\requests\models.py", line 1021, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: https://<domain>/Service/PXPCommunication.asmx?WSDL

Obviously, the <username>, <password>, and <domain> are my actual username, password, and domain. In the interest of privacy, I would not like to leak my real school portal online, but I would be willing to share it with the repository owner.

Would like to clarify, my StudentVUE portal seems to use ASPX instead of ASMX. I don't know how much of a different that makes.

Tried the old, web-based version and there are still many incompatibilities with my StudentVUE: it's like a totally different service.

This repo is pretty outdated, as most of us have already graduated from the schools that the synergy information service relied on. I'm looking into ways I can try to maintain it
Get Outlook for Androidhttps://aka.ms/AAb9ysg

From: a-github-account @.>
Sent: Friday, November 25, 2022 4:37:58 PM
To: StudentVue/StudentVue.py @.>
Cc: Subscribed @.***>
Subject: Re: [StudentVue/StudentVue.py] URL: /Service/PXPCommunication.asmx?WSDL not found (Issue #16)
Tried the old, web-based version and there are still many incompatibilities with my StudentVUE: it's like a totally different service.
—
Reply to this email directly, view it on GitHubhttps://github.com/StudentVue/StudentVue.py/issues/16#issuecomment-1327941883, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGCJPZLEOADX54HLYYBBMSTWKFLWNANCNFSM6AAAAAASLV6NVM.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

note to self figure out how to remove the outlook watermark

@a-github-account chiming in here, it's likely that your school district is running an outdated version of StudentVue, which is incompatible with this API client. There's not much we can do with this project, your best approach would be attempting to reverse engineer that older version yourself.


No known class method for selector 'startListeningToKeyboard'

Hello
I am working on objective c. after i update pod i m facing following issue:

No known class method for selector 'startListeningToKeyboard'.
No visible @interface for 'DropDown' declares the selector 'setAnchorView:'
Property 'bottomOffset' not found on object of type 'DropDown '

please guide me how to resolve it.
thank you.

Any update on this.. as I'm also working on objective c project and having the same issue.

Any update on this.. as I'm also working on objective c project and having the same issue.


Prettier doesn't format svelte files

After cloning and installing, prettier didn't format svelte files inside both the app/* and packages/* folder.
js/ts files are formatted correctly.

I think I found the reason of this problem:
https://github.com/sveltejs/prettier-plugin-svelte/issues/155


Prevent runc inheriting BUILDTAGS from containerd

fixes the issue reported by @tghartland in https://github.com/containerd/containerd/pull/5036#discussion_r593332821
Both runc and containerd use BUILDTAGS to customize go build-tags.
When building containerd with custom build-tags, runc inherited
those, causing the default to be overwritten, e.g.;
make BUILDTAGS=no_btrfs cri-cni-release
(in script/setup/install-runc)

HEAD is now at 12644e61 VERSION: release 1.0.0~rc93
make[1]: Entering directory '/tmp/tmp.ZJzc2KtI0A/runc'
go build -trimpath "-mod=vendor" "-buildmode=pie"  -tags "no_btrfs" -ldflags "-X main.gitCommit="12644e614e25b05da6fd08a38ffa0cfe1903fdec" -X main.version=1.0.0-rc93 " -o runc .
                                               ^^^^^^^^^^^^^^^^

This patch brings back the BUILDTAGS make-var in the runc-install
script, which fixates the buildtags to our defaults.

Also marked for backporting, because this change was already cherry-picked in the 1.4 branch

I guess failure is not related

I guess failure is not related

Too Many Requests - Server message: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit

yay! green now


primehack.primehack version 01

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?

[x] Does your manifest conform to the 1.5 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

yes

@microsoft-github-policy-service agree [company="{decamillennium}"]
@microsoft-github-policy-service agree
@microsoft-github-policy-service agree company="Microsoft"

@microsoft-github-policy-service agree [company="{decamillennium}"] @microsoft-github-policy-service agree @microsoft-github-policy-service agree company="Microsoft"

I think you want the middle one. Please only put one so the robot doesn't get confused.


Allow findAndModify to take an options parameter: BREAKING CHANGE

The third parameter to findAndModify was previously set as the returnFieldSelector. The problem with this is that the findAndModify function in mongo takes quite a large number of optional parameters, such as the very commonly used "new" parameter.
This fix replaces the third parameter with an options argument which should take anything that can be iterated as an associative array (such as a Json or Bson object)
Example:
auto result = collection.findAndModify(
    ["_id": Bson(_id), "count": Bson(count)],
    ["$inc": Bson(["count": Bson(1)],
    ["new": true]
);

To achieve this, I have strayed away from using the CMD struct, but the struct doesn't allow for optional parameters.

With find, there is always the possibility to define the query like this:
{
  "$query": {"_id": ..., "count": ...},
  "$inc": {"count": 1"},
  "$new": true
}

I don't know if this works for findAndModify, though, possibly not. The problem is that we can't make a silent breaking change like the one here. Alternatively, adding an overload with an additional options parameter would be a workable solution.
It would also be nice to assemble the command without doing dynamic memory allocations (which Bson does when appending fields), but I don't have a handy solution for this (might require some extensions to vibe.data.serialization).

I was wanting to use findAndModify with "remove": true because findAndRemove didn't exist, but it seems neither option is possible at the moment.
+1

@vuaru, I've studied code a little. It seems to me we can invoke findAndModify by calling find with
{
    "findAndModify": "<name of the collection",
    ...
}

Haven't tested it, yet.

I've simply created a new method with a different name to make this a non-breaking change.


Lost the "+Add note" at the bottom of dataview pages AND the dark drop down on the Project NavBar

What happened?
The "+Add note" seems to not work with the dataview source.
The missing drop down on the right side of the Project NavBar seems to be missing since the last update  (it was the way I added notes to dataview source projects)
What did you expect to happen?
I had originally expected to see the "+Add note" at the bottom of my dataview table as if the source was a tag.
Overall I expected there to be a way to add  a note which was placed in the project directory per the setting. This was the case with the "add note" in the drop down.
How can we reproduce it (as minimally and precisely as possible)?
All I did was run the Project update from the Community Plugins under settings. I an running Project v1.15.0 in  Obsidian-1.1.16.AppImage. In projects using source folder or tag, the "+Add note" exists at the bottom of the table. It is not there for source dataview. With this Obsidian/Project combination the dropdown is missing.
Anything else we need to know?
No response
Plugin version
Project v1.15.0
Obsidian version
Obsidian-1.1.16.AppImage
OS
Linux

We removed the New button in the upper-right corner. You can still create notes from the views and the command palette.
Board and Calendar views need to edit metadata when adding them, which isn't supported for Dataview projects. That being said, Table and Gallery view don't need to add any metadata to new notes, so they should be allowed to add notes.
I've released 1.15.3 with a fix.

Thank you. Just updated and verified that the '+Add note' is back in the table view.
I am using a single vault as a Life OS (life manager connecting goals with activities to meet those goals and KM (pkm) to support the activities. I have found Projects to be my 'home-base' for daily use (although canvas may soon match it supporting brainstorming and navigation) after struggling with the wire&tape method you described.
Using Templater and the +Add has allowed me to customize new notes (when the notes are entered directly to the right directory, which is why this issue became an issue when the "New" button disappeared (not a complaint about the new design).

Yes, that is what I do, but it did not work from the command palette. Again, why the loss of the 'New' button was problematic.
Wire&tape:  your description of the motivation for creating Projects. I was using Tasks and dataview along with QuickAdd and MetaEdit. I haven't added a new Goal (Personal Focus => Goal =>  Projects => Tasks) with KM supporting Tasks recently so I'll probably need to update QuickAdd/MetaEdit when I do.

but it did not work from the command palette

That sounds like a bug. They should be equivalent. Let me have a look at it 🙏

I expected that the command palette didn't have access to the referring page/plugin so I did not find this to be surprising (a bug).

You're correct that when you create a note from the command palette, it doesn't know which project you want to add it to, but if you select the project from the dropdown, it should use the new-note location for that project.
The only difference between the command palette and the earlier New button was that the button could select the active project as the default.

You're helping me here! I appreciate your patience helping me understand.
Obviously, I want changes to be for the better, so if you lost your workflow, I'd like to fix it if I can :)

The 'sorry' was for needing dataview more than projects (by a little). No this workflow for Activity management is really good. I had 'automated' the creation of the flow from a goal to tasks using the more plugins before. I don't expect Projects to solve all my specialized workflows. It DOES solve my Activity ones. Actually more than that as it is also acting as my index for information associated with projects, spheres of responsibility and interests. I had started trying to document my intents at bylos.net but have become very busy and have not stabilized my process yet (I am still migrating from P.A.R.A.).


Contribution Request: Connection unit-testing

How can I contribute on this topic "Connection unit-testing"?

Oh, this feature has been released recently. My bad, I forgot to remove the TODO from the Readme.
Thanks for willing to help!


Extract class: Reifier

This refactoring encapsulates the process of reification, separating
it from the model (VersionConcern).
The ABC complexity score of VersionConcern (measured by flog) is
reduced from 750 to 362, a 52% reduction.
Finally, this refactoring provides a truely private namespace for
methods like reify_has_many_through. Such methods will no
longer be mixed into PaperTrail::Version, or end-user's version
models, if any.

Just for fun (it doesn't tell us anything flog can't), here is the Code Climate analysis of this refactoring (attached):

Yea, I will agree that the code base as a whole could definitely stand some refactoring into smaller modules and methods of less length, I've certainly allowed some of the methods to become unwieldy over time (not that I can remember it ever being super great in that regard).
Do you think it makes more sense to have this Reifier be a class or a mixin module? Any particular reasons why or why not? And could we potentially memoize the Reifier instance(s) when they are generated if we are going to stick with the class?

Do you think it makes more sense to have this Reifier be a class or a mixin module? Any particular reasons why or why not?

I'd prefer to not mix Reifier into VersionConcern. By not mixing in, we reduce our public API.

.. this refactoring provides a truly private namespace for
methods like reify_has_many_through. Such methods will no
longer be mixed into PaperTrail::Version, or end-user's version
models, if any.

Also, I think this class is easier to understand if it stands alone. It's still tightly coupled to ActiveRecord (a lot of AR methods are called) but they are all called with explicit receiver, so the coupling is more obvious.

And could we potentially memoize the Reifier instance(s) when they are generated if we are going to stick with the class?

I don't think so, not the way it's currently written. Are you concerned about memory usage? I could do some profiling fairly easily.

Mind if I merge this, Ben?

Apologies for the delayed review, I've been on vacation. I'll take a closer look this afternoon.

Sorry I've been slow on reviewing this, just started a new job, I'll try to go through it more thoroughly in the next few days, looks good on the surface.

Thanks. Don't rush your review (it's a big change!) but there is going to be a conflict with https://github.com/airblade/paper_trail/pull/596 so it would be great if I didn't have to rebase this too many times.  Git conflicts aren't a big deal, but let's not let this get stale if it is something you're interested in.  Thanks.

Ben, this is ready for another review.  I've changed it from a class to a module as we discussed and I've rebased, resolving the conflict with https://github.com/airblade/paper_trail/pull/596

Mind if I merge this? I'm getting a little antsy because I had to fix another conflict today, sorry.

Sorry Jared, was away on a trip with limited access to wifi for the last 5 days. This looks good to me, and it is aligned with what we discussed during our conversation. :+1:

Sorry Jared, was away on a trip with limited access to internet for the last 5 days.

No worries, thanks for the review, I know it was a big one!


New version: StaticKernels v0.2.2

Registering package: StaticKernels
Repository: https://github.com/stev47/StaticKernels.jl
Created by: @stev47
Version: v0.2.2
Commit: dc6b8c92774c4cd969c4dd0f4690a59c45e15a58
Reviewed by: @stev47
Reference: https://github.com/stev47/StaticKernels.jl/commit/dc6b8c92774c4cd969c4dd0f4690a59c45e15a58#commitcomment-38599713

I cannot register 0.2.0 or 0.2.1 anymore since the tagged commits are apparently broken, may I skip to 0.2.2?


api.accessToken.addScope is not working

Checklist

[X] The issue can be reproduced in the auth0-react sample app (or N/A).
[X] I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
[X] I have looked into the API documentation and have not found a suitable solution or answer.
[X] I have searched the issues and have not found a suitable solution or answer.
[X] I have searched the Auth0 Community forums and have not found a suitable solution or answer.
[X] I agree to the terms within the Auth0 Code of Conduct.

Description
In the Actions flow, if you want to modify the accessToken using api.accessToken.addScope, the token remais the same. Action that I used as example:
exports.onExecutePostLogin = async (event, api) => {
    const appMetadata = event.user.app_metadata;
    var permissions = appMetadata?.authorization?.permissions;

    var requestedScopes = event.request.body.scope || event.request.query.scope;
    var parsedScopes = requestedScopes.split(" ");

    var allScopes = parsedScopes.concat(permissions);

    allScopes.forEach(scope => api.accessToken.addScope(scope));
};

NOTE: if you run the "same code" in Auth Pipeline > Rules, it works! 🎉
Reproduction

Create a Custom Action
Adds the new action created in the Post Login Flow
Fill the login form with your credentials
Submit Form

So if you inspect the token retrieved after login, the scopes remains unchanged
Additional context
No response
auth0-react version
2.2.4
React version
18.2.0
Which browsers have you tested in?
Chrome

I have the same behavior, no scopes are added even though the login flow completed successfully.

I am also facing same issue. Has anybody found a resolution?


Improvements to VRS/Foveated rendering

This PR extracts the improvements to the fragment rate shading improvements from https://github.com/godotengine/godot/pull/85824, I wanted to extract these as I'm still having issues with the density map extension and will likely lift that to 4.4 while I'd like these changes to still make it into 4.3.
This also applies a few fixes I missed, makes the map we provide with VRS_XR match the format for VRS_TEXTURE, and adds controls to adjust the VRS map creates for VRS_XR by default.

Note as already is the case, VRS only works on the Vulkan renderer though I think we're close to adding support for DirectX and Metal. With DirectX its interesting that in multiview, we can't have separate shading rate maps per eye. We'll need to make our vrs.glsl copy function capable of combining the views and output a unified map. Currently no plans exist to add support for OpenGL/WebGL

Our default fallback implementation in XRInterface has now been moved into a helper object and is only implemented for MobileVRInterface and OpenXRInterface. It has been greatly improved over the older version.

Note we found out that Quest 3 now supports the fragment shading rate extension and this feature can be used and can be tested on Quest 3. Older Quests only support the fragment density map extension and require #85824 to be completed.
The improvements here should show a serious performance improvement on Quest 3, we already tested this without the improvements in control.

I've created an example Godot project that allows you to play with this without requiring XR hardware:

TestStereoVRS.zip

@DarioSamo this is giving me a:
ERROR: VALIDATION - Message Id Number:<PHONE_NUMBER> | Message Id Name: UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout
        Validation Error: [ UNASSIGNED-CoreValidation-DrawState-InvalidImageLayout ] Object 0: handle = 0x1ff941e8660, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x4dae5635 | vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] command buffer VkCommandBuffer 0x1ff941e8660[] expects VkImage 0x6969c50000000b79[RenderBuffer VRS/texture] (subresource: aspectMask 0x1 array layer 1, mip level 0) to be in layout VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL--instead, current layout is VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL.
        Objects - 1
                Object[0] - VK_OBJECT_TYPE_COMMAND_BUFFER, Handle<PHONE_NUMBER>704
        Command Buffer Labels - 20
                Label[0] -  (L-1){ 0, 0, 0, 1 }
                Label[1] - Command graph (L10) (Draw){ 1, 1, 1, 1 }
                Label[2] - Command graph (L9) (Draw){ 1, 1, 1, 1 }
                Label[3] - Command graph (L8) (Draw){ 1, 1, 1, 1 }
                Label[4] - Shadow Render (L7) (Draw){ 1, 1, 1, 1 }
                Label[5] - Shadow Render (L6) (Draw){ 1, 1, 1, 1 }
                Label[6] - Render Opaque (L5) (Copy){ 1, 1, 1, 1 }
                Label[7] - Shadow Render (L5) (Draw){ 1, 1, 1, 1 }
                Label[8] - Shadow Render (L4) (Draw){ 1, 1, 1, 1 }
                Label[9] - Shadow Setup (L3) (Copy){ 1, 1, 1, 1 }
                Label[10] - Shadow Setup (L2) (Copy){ 1, 1, 1, 1 }
                Label[11] - Shadow Setup (L1) (Copy){ 1, 1, 1, 1 }
                Label[12] - Command graph (L0) (Draw){ 1, 1, 1, 1 }
                Label[13] - VRS Setup (L0) (Draw){ 1, 1, 1, 1 }
                Label[14] - Command graph (L0) (Copy){ 1, 1, 1, 1 }
                Label[15] - Shadow Setup (L0) (Copy){ 1, 1, 1, 1 }
                Label[16] - Setup Sky (L0) (Copy){ 1, 1, 1, 1 }
                Label[17] - Render Setup (L0) (Copy){ 1, 1, 1, 1 }
                Label[18] - Command graph (L0) (Copy){ 1, 1, 1, 1 }
                Label[19] - Command graph (L-1){ 1, 1, 1, 1 }

Any chance you can have a look at that? May be an existing validation error for VRS but just noticed it working on this. I think this may be caused by the ARG not recognising the VRS texture being used as a VRS attachment and not marking it as being read from in that pass?

I'm still not crazy about storing the VRS data on XRInterface and the default implementation in get_vrs_texture(). It would make more sense to me to put that on XRServer or some other central place, and then if VRS is enabled and get_vrs_texture() returns an invalid RID, call XRServer::get_default_vrs_texture() or something like that. To my mind, XRInterface should be only empty virtual methods that are filled in by the XR platform. Having it store data and provide default functionality feels wrong to me.
That said, it's not a hill I'm willing to die on. :-)

I tested this on Quest 3 using the demo project linked from PR https://github.com/godotengine/godot/pull/85824. I'm still seeing the same frame time gains that I saw when testing that issue, but I'm getting some weird flickering (even with VRS turned off) that I didn't get when I tested that PR a month or so ago. I tried switching to master and I'm seeing the same flickering, so I don't think it's caused by this PR, it seems like something unrelated.
So, in summary, testing seems good :-)

That said, it's not a hill I'm willing to die on. :-)

I get what you're saying, and maybe that is a nicer way to do it. What irks me is that this will likely always be the code path. It's kind of a weird one because it doesn't really belong to the XR implementation, it's a graphics implementation related to XR.

I tested this on Quest 3 using the demo project linked from PR #85824. I'm still seeing the same frame time gains that I saw when testing that issue, but I'm getting some weird flickering (even with VRS turned off) that I didn't get when I tested that PR a month or so ago. I tried switching to master and I'm seeing the same flickering, so I don't think it's caused by this PR, it seems like something unrelated.

This is a bug that is unique to the Quest 3 and that has been plaguing us since the Q3 came out. Its sporadic but I think our recent improvements to the rendering engine has made it more noticeable.

@dsnopek mind giving this another look? I've moved the logic into a helper object which solves your issue. I've also fixed a few things so it works well now.
@Malcolmnixon if you have time for it as well, that would be great, this solves how strong the default VRS is currently.
I've also added support for adjusting the VRS based on focus if the eye gaze interaction extension is available. Sadly we can't test this on Quest Pro yet as it requires the work in #85824 to be finished.
VRS does work nicely on Quest 3. You can use the following project to test:
https://github.com/BastiaanOlij/godot_openxr_demo/tree/add_more_testing
Note that I have changed the defaults in that project to play around with things so you may want to disable that code in its start_vr.gd script to see what things look like by default.

Thanks!


Run post_upstream_clone immediately when updating

The specfile may be generated during post_upstream_clone. This means
that getting the version from the spec could fail, hence we always need
to do post_upstream_clone first.
Signed-off-by: František Nečas<EMAIL_ADDRESS>@jkonecny12 Would you mind giving this a quick spin? Your reproducer seems to work for me now locally.

Fixes #1413

Thanks for the fix. Sorry for not testing it before, I wasn't able to get to the GitHub.
Local test works great for this. I'm encountering another issue but that seems to be the configuration issue.

Local test works great for this. I'm encountering another issue but that seems to be the configuration issue.

Nice, let us know if you need some help.

Just FYI, the another issue is not packit but Anitya which is used by rebase-helper. It's correct now.


Code format: provide keyboard shortcut

Provide shift+(cmd/ctrl)+F as a keyboard shortcut, and indicate in toolbar button tooltip.
Possible to do this without adding another handler to ace2_inner.js? Maybe the setup in ode_file.js can register the shortcut.
(Imported from Bitbucket #26 reported by maxg on 2010-06-22)

(Changed status from new to open.)
(phy on 2010-07-07)

Added keyboard shortcut by adding another handler to ace2_inner.js. Have not marked issue resolved because would like to do it in ode_file.js.
(phy on 2010-07-22)

(Changed status from open to resolved.)
(phy on 2010-08-31)


REST APIs for Snippets Plugin

Implemented APIs for:

Add Snippet
Delete Snippet
Update Snippet
Get Snippets (global or user owned)
Search Snippets

I updated the web UI to use the new commands for Add, Update, Delete.

@dregad I addressed your comments. Please have another look.