Launch Implementer Version of the Specification

This issue is to work towards deliver of an implementer version of the Workflows Specification that can be used by interested vendors (or community members) to build prototype tooling and feedback to the SIG on aspects of the specification.
How a bill becomes law?
We'll work with the OAS TDC to identify the steps needed to release and communicate on an initial implementer spec version. These discussions will also cover how the SIG Workflows group should also function moving forward (perhaps follow IETF process/approach for working groups).
Planned timelines and activities

Work towards addressing or deciding on the following issues:

[x] Add components section to improve reusability through referencing within the spec
[x] Harden the Runtime Expression section within the spec
[x] Determine engagement/overlap with the CNCF Serverless Workflows initiative
[x] Determine if Aliases are required in the spec
[x] #71
[ ] Create dedicated preamble for the pretty print site specification
[x] Determine process (if any) with the OAS TSC

By end of year, we'll aim to have an implementer spec version release (unless explicit reasons not too from the TDC)

From Neal Caidin on ability to host the Workflows Specification under the OAI:

Hello all. I asked LF if our charter covered adopting a new spec, like the Workflow spec. I hope I asked the right question? Here is the answer - As long as the new specification relates to "providing technical metadata for APIs" then it would appear to fall within the scope of the OpenAPI project. Please note, however, that the license for Specifications is the Apache-2.0 license. We now have various alternatives, and if the community would like to understand what open specification licenses are available to them, please let us know.

Link to slack conversation: https://open-api.slack.com/archives/C1137F8HF/p1683808672092199

Section Data Types: link to the Formats Registry, ideally per format.

The info.version property is defined as the version of the "Description" which could be composed of multiple documents.  In OpenAPI the info.version is defined as the version of the document.  Was this different intentional?

Workflows Specification Object Example, step
  - stepId: getPetStep
    description: retrieve a pet by status from the GET pets endpoint
    operationRef: https://petstore3.swagger.io/api/v3/openapi.json#/paths/users/~findbystatus~1{status}/get
    dependsOn: loginStep
    parameters:
      - name: status
        in: query
        value: 'available'
      - name: Authorization
        in: header
        value: $steps.loginUser.outputs.sessionToken

Assuming the sessionToken output of the previous step loginUser is a "raw" token, then the Authorization header is probably of the form
Authorization: Bearer <sessionToken>

How would such a concatenation of the prefix Bearer  and an output value be expressed?
I'll look for it in the remainder of the document, but it would be nice if the example already told me 😄.

The literals description includes string but the table does not.  It would be good to clarify whether single and/or double quotes are supported for strings. https://github.com/OAI/sig-workflows/blob/main/versions/1.0.0.md#literals

It appears that in the OpenAPI spec we did a particularly bad job of specifying how to use $statusCode in an expression.  Most of the examples in workflows treat statusCode as a numeric value during comparison.  However, there is an example here https://github.com/OAI/sig-workflows/blob/main/versions/1.0.0.md#fixed-fields-10 that treats it as a string.  This might be fine but it set off my spidey senses.

The successCriteria property is a list of Criterion Objects that all must be satisfied. It might be worthwhile providing some guidance as to when to use an AND (&&) operator in a single criterion Object vs multiple criterionObjects.  e.g. Will a list of criteron Objects "short circuit" if one fails?

Is this
- condition: $statusCode == 200

the same as
-  context: $statusCode
   condition: 200
   type: simple

?
If so, what is the value of type simple?

the retryAfter field in the Failure Action Object is described as "A non-negative decimal indicating the milliseconds delay". Is this really supposed to say Decimal?  i.e. someone can define fractions of a millisecond?  Is there a strong reason to deviate from the HTTP standard of using seconds for retryAfter?

It would be valuable to have some examples and discussion around the onSuccess property.  It would be good to move the Note about what happens when there are multiple success actions, up into the onSuccess property.  It is the behavior of the array of success actions, not the success action itself that is being defined by the note.
https://github.com/OAI/sig-workflows/blob/main/versions/1.0.0.md#fixed-fields-6

Section Step Object, field operationRef

A complete URI Template SHOULD be used.

The examples show a JSON Pointer with a fragment containing a path through the paths object, the URI template, ending at the operation object.
I find the examples convincing and am unable to deduce them from the field description.

Section Workflow Object, field inputs:

A JSON Schema 2020-12 object representing the input parameters used by this workflow.

Are there any cases where this JSON Schema object wouldn't say type: object?

defined as the version of the "Description"

Thanks @darrelmiller - this is being fixed via https://github.com/OAI/sig-workflows/pull/98

Workflows Specification Object Example, step
  - stepId: getPetStep
    description: retrieve a pet by status from the GET pets endpoint
    operationRef: https://petstore3.swagger.io/api/v3/openapi.json#/paths/users/~findbystatus~1{status}/get
    dependsOn: loginStep
    parameters:
      - name: status
        in: query
        value: 'available'
      - name: Authorization
        in: header
        value: $steps.loginUser.outputs.sessionToken

Assuming the sessionToken output of the previous step loginUser is a "raw" token, then the Authorization header is probably of the form
Authorization: Bearer <sessionToken>

How would such a concatenation of the prefix Bearer  and an output value be expressed?
I'll look for it in the remainder of the document, but it would be nice if the example already told me 😄.

String functions representations like concatenation are not currently supported. If we deem it worthwhile, then I would propose that we handle in the same manner as a Criterion.condition in so far as literals can be combined with runtime expressions and also leverage and extended set of operators. Alternatively, we'd need to introduce a limited set of functions (this is thread if we pull at it).
I'd tend to treat this as an enhancement for a future minor rev.

It appears that in the OpenAPI spec we did a particularly bad job of specifying how to use $statusCode in an expression. Most of the examples in workflows treat statusCode as a numeric value during comparison. However, there is an example here https://github.com/OAI/sig-workflows/blob/main/versions/1.0.0.md#fixed-fields-10 that treats it as a string. This might be fine but it set off my spidey senses.

I don't see it as a big issue, but perhaps we could provide a little more clarity for implementors to take appropriate parsing responsibility before evaluating such a condition

the retryAfter field in the Failure Action Object is described as "A non-negative decimal indicating the milliseconds delay". Is this really supposed to say Decimal? i.e. someone can define fractions of a millisecond? Is there a strong reason to deviate from the HTTP standard of using seconds for retryAfter?

Thanks @darrelmiller - Issue #100 created for this. I've no idea how I deviated here......... I will keep the decimal description unless you think the Retry-After header should also be adjusted: "A delay-seconds value is a non-negative decimal integer, representing time in seconds"

https://github.com/OAI/sig-workflows/blob/main/versions/1.0.0.md#fixed-fields-4
The successCriteria property is a list of Criterion Objects that all must be satisfied. It might be worthwhile providing some guidance as to when to use an AND (&&) operator in a single criterion Object vs multiple criterionObjects. e.g. Will a list of criteron Objects "short circuit" if one fails?

I think it's self explanatory but happy to add an example if needed. However I'm not sure how prescriptive I want to be here for authors. The general rule of thumb is that if you have assertions which can not easily fit into a single Criterion Object (e.g. you may need to check a status code as well as apply some JSONPath expressions to check response body information).
Yes, if one criterion fails, then the step is deemed as unsuccessful. That may trigger other actions depending on the presence of the onFailure fixed field

Is this
- condition: $statusCode == 200

the same as
-  context: $statusCode
   condition: 200
   type: simple

? If so, what is the value of type simple?

This made me smile, which is good!
Yes, they are effectively the same but somewhat unexpected usage. And the following is also the same:
- condition: $statusCode == 200
  type: simple

'type' simple is to support those who want to be verbose in their expressiveness of the criterion. Most often, I would expect where short handed approaches to be leveraged for simple conditions.
Example:
- condition: $statusCode == 200 && $response.body != null

This would not be very clear if represented as the following IMHO as $statusCode is not the only context being evaluated
-  context: $statusCode
   condition: 200 && $response.body != null
   type: simple

Open to suggestions as to how to harden/clarify

Section Workflow Object, field inputs:

A JSON Schema 2020-12 object representing the input parameters used by this workflow.

Are there any cases where this JSON Schema object wouldn't say type: object? What do I have to expect/accept as a tool implementor?
How would inputs be referenced if that schema isn't of type: object? The Runtime Expressions only allow
"$inputs." name

which seems to require type: object.

@ralfhandl Thanks for raising. Yes, I would recommend that we restrict what we expect here. My expectation is type: object.

As @ralfhandl noted:

Section Workflow Object, field inputs:

A JSON Schema 2020-12 object representing the input parameters used by this workflow.

Is the support requirement strictly for JSON Schema 2020-12 rather than OAS 3.1's extensions to 2020-12?  I do not care either way, I was just a bit surprised.
If it's not tracked elsewhere already (and my apologies if it is- GitHub search ignores the $ in $schema which makes it hard to search for in issues), you might want to add a note that while $schema is supported as a keyword, handling values other than the standard 2020-12 metaschema (or the OAS 3.1 dialect metaschema?) only MAY be supported.  Or something like that.

Section Parameter Object says

There are five possible locations specified by the in field:

followed by a list of six values.
If the step has a workflowId I assume that all parameters must have in: workflow. In which case it would be easier to just omit the in field and remove the value workflow from the list, bringing it back to five possible values.

Section Parameter Object, fixed field target says

Can be useful for targeting specific request body part.

Seems that I MUST provide exactly one parameter that is in: body and does not have a target to have a body whose parts I can then modify with further parameters that have a target.
If target is present, MUST I then specify in: body? Or is there an unmentioned in value if bodyPart?
An example would be helpful.

Section Reference Object, field $ref says

This MUST be in the form of a URI.

Which is only half of the truth: the fragment part - if present - apparently MUST be in the form of a JSON Pointer URI Fragment Identifier Representation.
Otherwise how is an implementation supposed to interpret the fragment part?

Section Criterion Object says

String comparisons SHOULD be case insensitive.

Please make this a MUST for either sensitive or insensitive, don't care much which.
Different behavior across different workflow execution engines would be a nuisance.

Section Runtime Expressions, ABNF rules message-header-reference and message-payload-reference: are these leftovers from deleted text or "sneak previews" of things to come?
Either way I'd remove them from this specification version.

Section IANA COnsiderations, vnd. prefix:

This prefix is for vendors, whereas standards don't require a prefix.

I see OAI in the standards category, not in the vendors category.

@ralfhandl

Which is only half of the truth: the fragment part - if present - apparently MUST be in the form of a JSON Pointer URI Fragment Identifier Representation.

Unless the reference points to a JSON Schema in which case plain name fragments are also supported.  The validity of a given fragment syntax is determined entirely by the media type of the target representation, so it shouldn't need to be further specified (although an informative reminder probably wouldn't hurt).

@ralfhandl thanks for catching that!  However, the inputs field takes a JSON Schema draft 2020-12 object inline, with no restrictions documented, which would allow for plain name fragments within a Workflows document.
And yes, the media type registration must define fragment syntax and semantics in order for them to work (technically... we know it's quite common to disregard such things, but if we're registering media types we might as well do it right).

Section Parameter Object, fixed field target says

Can be useful for targeting specific request body part.

Seems that I MUST provide exactly one parameter that is in: body and does not have a target to have a body whose parts I can then modify with further parameters that have a target.

@ralfhandl - I tend to agree with you here. We should perhaps make that explicit in the wording (or wording + examples).

If target is present, MUST I then specify in: body? Or is there an unmentioned in value if bodyPart?
An example would be helpful.

In the spirit it was written, in:body was expected in such scenarios. There is no bodyPart value. The expectation would be that you'd target specific locations should you wish.
There are some examples (which could be improved) at:

https://github.com/OAI/sig-workflows/blob/main/examples/1.0.0/pet-coupons.workflow.yaml#L116
https://github.com/OAI/sig-workflows/blob/main/examples/1.0.0/FAPI-PAR.workflow.yaml#L151

Sections Success Action Object and Failure Action Object, field stepID say

The referenced stepId SHOULD be within the current workflow.

If the step is in a different workflow, how do I provide values for the inputs of that other workflow?
Section Step Object, field stepId says

The id SHOULD be unique amongst all steps described in the workflow.

So I can have the same step id within one workflow, and I definitely can have the same step id within different workflows.
Which of these identically named steps is to be executed? All of them? The first? A randomly chosen one?
As an implementor I'd prefer to have a "MUST" in these three sentences to unambiguously identify the step to go to.

@ralfhandl #105 created to address the most pressing part of this feedback

Section Step Object, field stepId says

The id SHOULD be unique amongst all steps described in the workflow.

Workflow prefixing can be used to enable the ability to locate the desired step should a situation arise where there is a need to have a step with the same id within two described workflows. I'm OK living with this one.

The Table of Contents has multiple issues:

"Criterion Object" is listed before "Reference Object", and the corresponding sections have the opposite order
Workflows Specification - Version 1.0.0 looks odd, which may be caused by "Workflows Specification" being heading level 1 and "Version 1.0.0" being heading level 4 - where are the two intermediate levels?
Same for Definitions - Workflows Description: "Definitions" is heading level 2, "Workflows Description" is heading level 5
Sections "Security Considerations" and "IANA Considerations" are not listed
Appendix B is not listed

@ralfhandl #106 created to address this feedback

Section Reference Object, field $ref says

This MUST be in the form of a URI.

Which is only half of the truth: the fragment part - if present - apparently MUST be in the form of a JSON Pointer URI Fragment Identifier Representation.
Otherwise how is an implementation supposed to interpret the fragment part?

@ralfhandl I'll look to update the media type registrations to specify JSON Pointer as the fragment identifier mechanism, and add some additional text also into the section to clarify

Section Criterion Object says

String comparisons SHOULD be case insensitive.

Please make this a MUST for either sensitive or insensitive, don't care much which.
Different behavior across different workflow execution engines would be a nuisance.

@ralfhandl #108 created for this feedback

Section Runtime Expressions, ABNF rules message-header-reference and message-payload-reference: are these leftovers from deleted text or "sneak previews" of things to come?
Either way I'd remove them from this specification version.

@ralfhandl a sneak preview indeed. Created #109 to tidy up

Section IANA COnsiderations, vnd. prefix:

This prefix is for vendors, whereas standards don't require a prefix.

I see OAI in the standards category, not in the vendors category.

@darrelmiller any comment here? I was following along from the old comment on media types for OAS but I tend to agree with @ralfhandl that we should not be flagging these as vendor specific.
I'm happy to submit a change request on the registrations based on your feedback.

@frankkilcommins that comment about vnd. media types long predates the more recent OAS media type draft RFC.

It would be valuable to have some examples and discussion around the onSuccess property. It would be good to move the Note about what happens when there are multiple success actions, up into the onSuccess property. It is the behavior of the array of success actions, not the success action itself that is being defined by the note.
https://github.com/OAI/sig-workflows/blob/main/versions/1.0.0.md#fixed-fields-6

@darrelmiller #118 created to move the notes up to the Step onSuccess and onFailure fixed fields.

Section Parameter Object says

There are five possible locations specified by the in field:

followed by a list of six values.
If the step has a workflowId I assume that all parameters must have in: workflow. In which case it would be easier to just omit the in field and remove the value workflow from the list, bringing it back to five possible values.

@ralfhandl Issue #119 created to review/harden based on this feedback

Section IANA COnsiderations, vnd. prefix:

This prefix is for vendors, whereas standards don't require a prefix.

I see OAI in the standards category, not in the vendors category.

@ralfhandl just closing off this issue comment. Please see here for current status/context.

Section Step Object, field operationId

If more than one (non workflowsSpec type) source description is defined within a Workflows Description, then the operationId specified MUST be prefixed with the source name to avoid ambiguity or potential clashes.

How prefixed? Just prepend without separator character? An example would be useful.
Same with field workflowId.

@ralfhandl issue #124 created to address this feedback


Mixing Python and Javascript?

Hi,
I have an application that looks like this:

A main PyWidget object that acts like a hub widget,  with some smaller widgets and a StackLayout for displaying Page widgets
Many Page widgets that are used to display some widgets, with each having read/update Python functions

Now if I make the page a Widget, it is displayed correctly but I cannot use the Python read/update functions.
But if I make it a PyWidget, there is nothing displayed inside the main StackLayout when I show a Page inside it.
Is there a way to make this work without breaking up the Page widget into two?
Thanks,
Matic

My current working solution is to have two objects (one JS on Py) and a creation function like so:
class JsPage(flx.Widget):
    py_page = flx.AnyProp(None, settable=True)

    def init(self, py_page):
        self.py_page = py_page
        # Create all widgets

    @flx.action
    def set_value_of_widget_0(self, value):
        # Set value

    @flx.action
    def set_value_of_widget_1(self, value):
        # Set another value

    ...

class PyPage(flx.PyComponent):
    def set_js_page(self, js_page):
        self.js_page= js_page

    def read(self):
        # Read and store all data

   def update(self):
       self.js_page.set_value_of_widget_0(self.data[0])
       self.js_page.set_value_of_widget_1(self.data[1])
       ...

def create_page():
    py_page = PyPage()
    js_page = Agregat(py_page)
    worker.set_js_page(js_page )
    return js_page

Why does the JsPage have a reference to a PyPage? Because I want to access everything from a single object, the JsPage object:
# Create
page = create_page()
# Read
page.py_page.read()
# Update
page.py_page.update()

Is there a simple way of integrating the JsPage and the PyPage as one?
Thanks

This should work:
from flexx import flx

class MainPage(flx.PyWidget):

    def init(self):

        with flx.TabLayout():
            Page("page 1")
            Page("page 2")
            Page("page 3")

class Page(flx.PyWidget):

    def init(self, name):
        flx.Button(text=name)

m = flx.launch(MainPage, "chrome-browser")
flx.run()

Yes, that works. But this does not:
from flexx import flx, event

class MainPage(flx.PyWidget):

    def init(self):
        with flx.HBox():
            with flx.VBox():
                self.buta = flx.Button(text='1')
                self.butb = flx.Button(text='2')
                self.butc = flx.Button(text='3')
                flx.Widget(flex=1)
            with flx.StackLayout(flex=1) as self.sl:
                self.buta.w = Page("page 1")
                self.butb.w = Page("page 2")
                self.butc.w = Page("page 3")

    @event.reaction('buta.pointer_down', 'butb.pointer_down', 'butc.pointer_down')
    def _stacked_current(self, *events):
        button = events[-1].source
        print(button.w)
        self.sl.set_current(button.w)

class Page(flx.PyWidget):

    def init(self, name):
        flx.Button(text=name)

m = flx.launch(MainPage, "firefox-browser")
flx.run()

When a button from 1 to 3 on the left side is pushed, an empty widget is displayed in the StackLayout instead of the corresponding page, even though the page object is printed correctly in the event? print(button.w) in the above code
Any Ideas?

Aah, this is because technically a PyWidget is a PyComponent that wraps a Widget. It works if you change it to self.sl.set_current(button.w._jswidget).
This is a bit of a hack (using the private attribute), so we'd need to do something to make this work correctly. Maybe simply exposing the subwidget with a public attribute. Or convert when serializing a PyWidget. mmm, this needs some thoughts ...


remove unnecessary method to create SriovOperatorConfig

This method seems to be unnecessary as the SriovOperatorConfig Reconciler method is already creating the CR when not already specified.
See here

Hi @tariq1890 , I'm not sure which piece of code is the one that creates the default SriovOperatorConfig.
I think Reconcile method is not being called if the user doesn't create any resources, right? Did you try these changes in a clean installation?

@zeeke Great question, and you're right! The Reconciler will only run if the default SriovOperatorConfig CR is created.
What is actually unnecessary is the block of code that Creates the SriovOperatorConfig CR within the Reconcile method. If you look at the Reconcile method it is only actually designed to response to changes of the SriovOperatorConfigs named default and located in the configured Namespace. So it doesn't make sense to have the create logic within the Reconcile method

@zeeke Great question, and you're right! The Reconciler will only run if the default SriovOperatorConfig CR is created.
What is actually unnecessary is the block of code that Creates the SriovOperatorConfig CR within the Reconcile method. If you look at the Reconcile method it is only actually designed to respond to changes of the SriovOperatorConfigs named default and located in the configured Namespace. So it doesn't make sense to have the create logic within the Reconcile method

Hey, what about a flow that someone delete the default  SriovOperatorConfig CR after the pod created it?
I think that the code you removed would have created it again.
WDYT?

I was going to comment the same thing as @rollandf :)

Hey all, sorry I didn't reply sooner. From the review comments and code, here's what I have learnt so far
i) The SriovOperatorConfig Reconciler is only aimed at reconciling against one specific CR named default. If this is the case, why should this even be a CR or have a reconcile loop? Shouldn't this just be a ConfigMap?
ii) Ar argument for not deleting the method, is that you want the reconcile method to re-create the SriovOperatorConfig resource on an unintended delete. So a permanence of the Operator config is desired here. Is a reconciler really the best solution for this? Wouldn't it just be better to have a set of environment variables to determine the config of the sriov-network-operator? This way, the config shares the lifetime of the operator.
iii) When iterating on this PR, I've realised that e2e tests always pass. It does seem like the e2e tests should be catching something if we consider this method necessary
Overall, I do feel it's a bit iffy the way SriovOperatorConfig is designed

@tariq1890
I think that the main thinking is about supporting dynamical changes to the operator configuration.
If this is the case, having a configmap will need also code to watch changes, and environment variables changes requires restart of the Pod.
I assume that e2e tests are not covering 100% of the code flows. Adding more tests is always welcomed.

Hi @tariq1890 thanks for the comment!
btw another reason to have this as a CRD and not a config map is the validation we can do on it and the documentation we can add in the CRD description instead of just text the is super prune to errors from the user

Thanks @rollandf @SchSeba !
I will close the PR


1.2.2

The latest update after execute protect , the apk unable to install. Probably broken like before  #19

I tested with different apk, and I can not reproduce your issue. Please share your unprotected apk or log  on  adb install

No response going to close it


RHOAIENG-4500 Model registry Operator Deployment

Test Model registry operator deployment in ODH

Tested on Jenkins: https://opendatascience-jenkins-csb-rhods.apps.ocp-c1.prod.psi.redhat.com/job/odh/job/odh-smoke/43/console


[QUESTION] Is it possible to use the layers to make this GHA reuse previously published image versions?

Question
Hi, I've seen an interesting trick at https://github.com/pyca/infra/blob/d52c449/.github/workflows/build-docker-images.yml#L58 where they use docker build --cache-from=... to have Docker reuse some of the layer cache from an earlier image version IIUC.
When I saw https://github.com/redhat-actions/buildah-build/pull/43 / https://github.com/redhat-actions/buildah-build/issues/42, I thought — would it be possible to do the same with podman/buildah? What would be required? Would podman pull coupled with layers: true be enough? Is there something I'm misunderstanding in how buildah works? (there probably is)
I know that podman's --cache-from is no-op but  I thought maybe it is possible to achieve somehow on the buildah level?

@divyansh42 @tetchel @lstocchi any comments?

Hey @webknjaz, apologies for the delayed response.
I've checked this, buildah doesn't support --cache-from yet. However, there is an open issue for that.

Yeah, I've seen some related issues but I still don't understand if that is something that direct invocations of buildah maybe support.

In particular, I was curious if that layers option does this.

After v1.27.0, buildah support --cache-to and --cache-from.

Can I use this GitHub Action and have a newer buildah version

GitHub Actions Images all use whatever is in the Ubuntu repos. When Lunar Lobster drops in a month, we'll get a newer version of buildah/podman/etc. If you'd like, you can use quay.io/buildah/stable:latest. I use something like this:
    runs-on: ubuntu-latest
    container:
      image: quay.io/buildah/stable:latest
      options: --privileged

Although it's finicky, it gives you the latest version of buildah and dnf (but not podman?).

hhh well you can specify cache-to and cache-from now, but you need a system to make the right calls to the GitHub cache API (which i was trying to do) https://github.com/tonistiigi/go-actions-cache/blob/master/api.md and that system does not exist in buildah-build like it does in Docker's https://docs.docker.com/build/ci/github-actions/cache/#github-cache , so you might as well just use Docker's if you want caching

This seems to be fixed now


Elevate Error of API

Meta in their API has specific code for each type error, you can read this error, code and raise exception that we can catch, to know that is wrong in the send message because the error is silent.
2023-04-24 10:04:53,261 - root - INFO - Image not sent to<PHONE_NUMBER>3 2023-04-24 10:04:53,261 - root - INFO - Status code: 400 2023-04-24 10:04:53,262 - root - ERROR - {'error': {'message': '(#131030) Recipient phone number not in allowed list', 'type': 'OAuthException', 'code': 131030,  'error_data': {'messaging_product': 'whatsapp', 'details': 'El número de teléfono del destinatario no está en la lista de autorizados: Agrega el número de teléfono del destinatario a la lista de destinatarios y vuelve a intentarlo.'}, 'fbtrace_id': 'A4yeLb3JmDl2ZvQMvBgCANu'}}
ObjectIdException
	"error": {
		"message": "Unsupported post request. Object with ID '118130101241809' does not exist, cannot be loaded due to missing permissions, or does not support this operation. Please read the Graph API documentation at https:\/\/developers.facebook.com\/docs\/graph-api",
		"type": "GraphMethodException",
		"code": 100,
		"error_subcode": 33,
		"fbtrace_id": "A2H9tBUK0RHUB91NwUjrY23"
	}
}

RecipientPhoneNumberException
	"error": {
		"message": "(#131030) Recipient phone number not in allowed list",
		"type": "OAuthException",
		"code": 131030,
		"error_data": {
			"messaging_product": "whatsapp",
			"details": "El número de teléfono del destinatario no está en la lista de autorizados: Agrega el número de teléfono del destinatario a la lista de destinatarios y vuelve a intentarlo."
		},
		"fbtrace_id": "AguKtar08vzPr310wo-jcjY"
	}
}

Nice idea. I'll try to implement this asap!

Well, the only actual issue with this is that a full map of the Meta API errors should be created, and there are thousands of them (including sub-codes ofc).

Your actual listed errors might not be the right one: I mean, there are many codes that can mean the same (or almost) error.

I think a general ``WhatsAppErrorwould be good for now. It would have fields likemessage, type. code, error_data, fbtrace_id`. The challenge currently is, that you can not handle exceptions because they are just silent and not raised in the code.

Yeah that's the point. I opened #88 to also be able to create a better handler at the beginning: in fact, as FB says, version 16 of the API removes subcodes and only has major general codes.
I suggest updating the API version first, then we can try to implement an error handler.


V0.2

Pull Request Test Coverage Report for Build 89

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 69.699%

Totals

Change from base Build 88:
0.0%

Covered Lines:
835

Relevant Lines:
1198

💛  - Coveralls

Pull Request Test Coverage Report for Build 89

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 69.699%

Totals

Change from base Build 88:
0.0%

Covered Lines:
835

Relevant Lines:
1198

💛  - Coveralls


Entity life cycle listener tutorial / example documentation

@sai-pullabhotla  This is an awesome framework.  I have been trying to determine if the framework has event listeners and from reading through the project description it clearly does here.  I have read through the API documentation but I'm a newbie and I'm still not 100% clear on how to actually implement a listener via Catatumbo.  I searched through the website and the documentation on GitHub as well as plain old google searches and couldn't find any tutorials or examples.  Would it be possible to add an example to your website or wiki that shows the basics of how these listeners are utilized?  That would be super helpful!  Keep up the great work!

@Jboonie - Thanks! I would recommend taking a look at some of the JUnit tests around Entity Listeners. That should give you a good idea on how to implement listeners. Here are some tests...
https://github.com/sai-pullabhotla/catatumbo/blob/master/src/test/java/com/jmethods/catatumbo/ExternalListenerTest.java
https://github.com/sai-pullabhotla/catatumbo/blob/master/src/test/java/com/jmethods/catatumbo/DefaultListenerTest.java
https://github.com/sai-pullabhotla/catatumbo/blob/master/src/test/java/com/jmethods/catatumbo/DefaultAndExternalListenersTest.java
https://github.com/sai-pullabhotla/catatumbo/blob/master/src/test/java/com/jmethods/catatumbo/ExcludeDefaultListenerTest.java
https://github.com/sai-pullabhotla/catatumbo/blob/master/src/test/java/com/jmethods/catatumbo/InternalListenerTest.java


fix: use<EMAIL_ADDRESS>

<EMAIL_ADDRESS>appears to have been removed from npm, use 0.14.1

closes #17

Fast!  Thanks!

@SpainTrain Thanks for the contribution. I published it to npm as socketcluster-sever v5.10.2 and socketcluster v5.9.1.


Other View Link not Showing

Hi,
I have customed another link but it is not working. It is returning only the first instance. Rest are returning as default.
`private function resolveModelViewLink(Model $model)
{
// Here we list down all the alternative model-link mappings
// if we dont have a record here, will default to /{model-name}/{model_id}
$mapping = [
Recipe::class => 'recipe/{recipe_number}',
User::class => 'users/{username}',
];
    // getting the Fully Qualified Class Name of model
    $modelClass = get_class($model);

    // converting model name to kebab case
    $modelName = Str::plural(Arr::last(explode('\\', $modelClass)));
    $modelName = Str::kebab(Str::camel($modelName));

    // attempt to get from $mapping. We assume every entry has an `{id}` for us to replace
    if(Arr::has($mapping, $modelClass)){
        return str_replace('{recipe_number}', $model->recipe_number, $mapping[$modelClass]);
        return str_replace('{username}', $model->username, $mapping[$modelClass]);
    }
    // assume /{model-name}/{model_id}
    return URL::to('/' . strtolower($modelName) . '/' . $model->recipe_number);
    return URL::to('/' . strtolower($modelName) . '/' . $model->username);
} `

This question is not related to the package. Please refrain from asking questions about your personal project here.

Please remove this piece of sh*t on Github. People are wasting their time using this and in the end, it is completely useless.


Overhaul text-wrapping using revery-text-wrap library

This commit replaces the text wrapping code in TextWrapping.re with
my new implementation from revery-text-wrap.
This new code should be much faster, performing wrapping in O(n) time.
However, there are currently some limitations: this doesn't dynamically
check the width of the line while wrapping, which means that certain
glyphs will be the wrong size, since unicode-combined characters and ligatures aren't
understood by the library (yet). However, the actual wrapping looks much
better, with most of the known bugs fixed from the old implementation.

Resolves #617

Thanks for reviewing!

Why does it use a functor?

That's actually a question I was asking myself at the time when I was writing the library. There's 2 (small) reasons behind that, but I'm not sure either is a great answer.

It made the code a little simpler since I could avoid passing the width_of_char function to the width_of_token function (and before refactoring the code there were some other dependencies). It may also be useful for tokenization to have access to the "configuration" in one way or another. However, this can also be solved by passing around some of the state either directly or as part of a configuration record.

The other reason is that I imagine the use-case of this as having a few modules around for different environments. For example, if you had a rich text editor, it would be nice to have a CodeBlockWrap module and a TextWrap module that you could switch between easily. These would already differ in terms of the font used & the wrapping style (whether to hyphenate, whether to overflow, whether to remove extra whitespace, etc.), but in the future we could also pass in custom rules for when to break & such (let decide = (~token, ~lastToken, ~position, ...) => [Break | Hyphenate(position) | AutoHyphenate | Ignore | Continue]`). Either way, the functor does make it a little easier to juggle the different states in that case.

With both of those reasons in mind, I'm still not sure whether functors are the right decision here so just wanted to bring the reasoning into the conversation so I can hear some more thoughts on this. Shouldn't be a difficult change to make it use records or something else, so happy to change it if that seems important.

Why depend on Batteries?

Right, this is also a good question. There were some places where performance seemed better (originally I was using Batteries' substring module which is a lot faster at slicing) but I do want to get rid of the dependency either way. I started refactoring some of the code to depend less on batteries, just didn't get to removing String.slice yet.

AppendList looks like it's basically just a Queue, or a Deque if you eventually also need to prepend

Lol I'm so used to avoiding the stdlib's data structures in OCaml that I just assumed the Queue implementation would not be performant enough. Looking at the code it should be fine, so I'll refactor to use that.

Went ahead and changed all 3 of those things. Cut down a ton on code and one less dependency :)

if you had a rich text editor, it would be nice to have a CodeBlockWrap module and a TextWrap module that you could switch between easily. These would already differ in terms of the font used & the wrapping style (whether to hyphenate, whether to overflow, whether to remove extra whitespace, etc.), but in the future we could also pass in custom rules for when to break & such

You can also do this with plain function arguments using partial application. But it might definitely be more natural to use a functor once you add configurable rules, since you'll probably want to configure that only once project-wide.

Yeah, a big part of the question here is how general should I really make this library, since Revery's needs are probably a little bit simpler I could just make the library fit those directly. But if I implement things like custom rules the library becomes much larger in scope & it becomes less specific to Revery. For now I went with just parameters for those options but will probably reevaluate the decision based on where the library goes in the near future.

So this actually causes a regression in the calculator example. Looking into that real quick

Fixed that bug & improved the text example a little bit. It doesn't refresh when switching hyphenation mode (because that doesn't trigger a measure) but other than that looks pretty good. Hyphenation is still a bit wonky so I'll look into that, but it seems like it has to do with the measured character widths not lining up with the actual character width (due to kerning/ligature weirdness). One solution to this might be making the text wrapping a 2-pass process where the first wrap measures based on the assumed width of each character and then the second pass goes back and adjusts based on the measured width of the entire line. Regardless, that seems a little out of scope right now since hyphenation is disabled by default.

To fix the CI failure you need to update and commit the lockfiles for the sub-projects. Run esy @test i && esy @bench i && esy @doc i, then commit and push.

To fix the CI failure you need to update and commit the lockfiles for the sub-projects. Run esy @test i && esy @bench i && esy @doc i, then commit and push.

@glennsl or use this shell script https://github.com/revery-ui/revery/blob/master/update-lockfiles.sh 🙃
Maybe I can add what I proposed for brisk-reconciler https://github.com/briskml/brisk-reconciler/pull/70 (i.e. it auto submit new lockdirs)

Hmm.. doesn't look like the lock-files fixed that... any idea why?

Oh, you need to run esy @js i too (or just run ./update-lockfiles.sh). Sorry I missed that.
You also might have to run esy format if you haven't.


Request object should be explicit enumerable

per comment at https://github.com/bitinn/node-fetch/pull/265#issuecomment-293778093

Unfortunately, yeah. This means we can't use class syntax, at least not without further tweaking :(

This was fixed in v2.0.0.


Fish bites not showing up in Fish Window

Fish bites are not appearing in the fishing window despite having caught several fish already in the same fishing hole. Bait has been consistent in all catches.

This shows your perception as 0, which may invalidate the log entries, possibly. Try getting at least one perception, I guess.

I have the same issue, however non-regular hooks (double/triple hook, precision and powerful hookset) are being counted. I have a normal amount of perception also.

that's not the same issue then, is it?


Combining @nuxtjs/robots with @nuxtjs/sitemap causes pre-generation to fail on sitemap

Describe the bug
Steps to reproduce

Use Nuxt 3 with config defined below
Try to visit /sitemap.xml

You get this error
500
Cannot read properties of undefined (reading 'req')

at getRequestHeader (/xxx/node_modules/h3/dist/index.mjs:316:19)
at getPathRobotConfig (/xxx/node_modules/@nuxtjs/robots/dist/runtime/nitro/composables/getPathRobotConfig.js:19:43)
at  (/xxx/node_modules/@nuxtjs/sitemap/dist/runtime/nitro/sitemap/urlset/filter.js:21:10)
at Array.filter ()
at filterSitemapUrls (/xxx/node_modules/@nuxtjs/sitemap/dist/runtime/nitro/sitemap/urlset/filter.js:9:16)
at buildSitemap (/xxx/node_modules/@nuxtjs/sitemap/dist/runtime/nitro/sitemap/builder/sitemap.js:80:24)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at createSitemap (/xxx/node_modules/@nuxtjs/sitemap/dist/runtime/nitro/sitemap/nitro.js:25:17)
at async /xxx/node_modules/h3/dist/index.mjs:1980:19

This seems to happen because we are trying to get user agent from h3 but the event is not a valid request event, it's of the shape { loc: 'string', _key: 'string'}  so it can't find the headers
Steps to fix
For now I patched the dependency with this code
diff --git a/dist/runtime/nitro/composables/getPathRobotConfig.js b/dist/runtime/nitro/composables/getPathRobotConfig.js
index 38f02344ce9a122b72d02046a66d5dcffa5102b0..79f375aa33d3e49665814a0dec7f3e202ee18e70 100644
--- a/dist/runtime/nitro/composables/getPathRobotConfig.js
+++ b/dist/runtime/nitro/composables/getPathRobotConfig.js
@@ -16,7 +16,7 @@ export function getPathRobotConfig(e, options) {
     }
   }
   const path = options?.path || e.path;
-  const userAgent = options?.userAgent || getRequestHeader(e, "User-Agent");
+  const userAgent = options?.userAgent || (e.node ? getRequestHeader(e, "User-Agent") : 'na');
   const nitroApp = useNitroApp();
   const groups = [
     // run explicit user agent matching first

Nuxt Config
export default defineNuxtConfig({
	modules: [
		"@nuxtjs/robots",
		"@nuxtjs/sitemap",
	],

	experimental: {
		inlineRouteRules: true
	},

	robots: process.env.APP_ENV?.includes("prod")
		? { allow: "/" }
		: { disallow: "/" },

	site: {
		name: "XXX",
		url: process.env.URL
	},

	nitro: {
		prerender: {
			crawlLinks: true,
			routes: ["/sitemap.xml"]
		}
	},

	compatibilityDate: "2024-07-31"
});

Reproduction
No response
System / Nuxt Info
"nuxt": "^3.12.4"
"@nuxtjs/sitemap": "^5.3.5"
"@nuxtjs/robots": "^4.0.2"

Same error.

Hi, could you try the v6 beta for the sitemap module? It may fix this, it had a massive internal refactor. I'll try to ship it as stable either tomorrow or the day after.

@harlan-zw I tried on the beta but the same error persists. (Cleared Nuxt cache .nuxt .output etc).
 ERROR  [nuxt] [request error] [unhandled] [500] Cannot read properties of undefined (reading 'req')              23:11:37
  at getRequestHeaders (/xxx/h3/dist/index.mjs:303:32)
  at getRequestHeader (/xxx/h3/dist/index.mjs:311:19)
  at getPathRobotConfig (./.nuxt/prerender/chunks/runtime.mjs:1663:43)
  at ./.nuxt/prerender/chunks/runtime.mjs:2514:10
  at Array.filter (<anonymous>)
  at filterSitemapUrls (./.nuxt/prerender/chunks/runtime.mjs:2503:16)
  at buildSitemap (./.nuxt/prerender/chunks/runtime.mjs:2852:24)
  at async createSitemap (./.nuxt/prerender/chunks/runtime.mjs:2981:17)
  at async Object.handler (/xxx/h3/dist/index.mjs:1975:19)
  at async toNodeHandle (/xxx/h3/dist/index.mjs:2266:7)

I'm also facing this issue


Bump uuid version to 1.2.1

https://docs.rs/getrandom/latest/getrandom/#webassembly-support

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
19 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.01%) to 97.865%

Files with Coverage Reduction
New Missed Lines
%

test-suite/src/tester/mod.rs
19
87.5%

Totals

Change from base Build<PHONE_NUMBER>:
-0.01%

Covered Lines:
38238

Relevant Lines:
39072

💛  - Coveralls


Revert "Use mainline etcd and skydns for helios-solo"

Reverts spotify/helios#452 based on what @drewcsillag pointed out:
https://github.com/spotify/helios/pull/452#issuecomment-83663219

Actually we shouldn't need this. See #452 for discussion.


solve conflict with PyJWT

A kind of solution for https://github.com/GehirnInc/python-jwt/issues/36

See https://github.com/GehirnInc/python-jwt/issues/9#issuecomment-414175635 and https://github.com/GehirnInc/python-jwt/issues/36#issuecomment-760959282.

See https://github.com/GehirnInc/python-jwt/issues/9#issuecomment-414175635 and https://github.com/GehirnInc/python-jwt/issues/36#issuecomment-760959282.


energy display glitch

energy display does not give accurate reading

shield and gate active^

gate only^

shield only^

And what's wrong?
The Gate recharges the small energy amounts very fast. Why should the gate loose energy?
Cause the fast recharge, there is no difference in energy storage.

And what's wrong? The Gate recharges the small energy amounts very fast. Why should the gate loose energy? Cause the fast recharge, there is no difference in energy storage.

first i will addmit that i was confused and thought what i am guessing is time till close was rf\t after doubling back and double checking the gate doesn't show a rf\t power draw it say it isn't drawing any power even when it is 527 rf\t with gate and shield 27 rf\t for just the gate before time limit and 500 rf\t for just the shield

the bar shows diference between input power and output power basically


Move config secrets to environment variables

Storage account keys need to be secret, but right now they are stored in the config.py file.

Moved to env.conf


Node hostname issues when Amazon/AWS cloud provider is configured

When cloud provider is configured to AWS, the node resource name is set to the internal DNS name of the AWS instance.
This should be fixed by https://github.com/rancher/rancher/issues/22849 but reproduced with the following version

Rancher v2.3.2
Cloud Provider AWS

I have same issue with Rancher version 2.3.6

The behavior is not a bug, its how the cloud provider works. The issue referenced when was restarting nodes, they wouldn't get the certificates back because the nodename was not recognized as it differs from initial registration. The fix for that went in v2.3.3.
If you encounter any issues, please describe the steps to reproduce and the error situation you are seeing. The screenshot does not show an error situation, the names set by cloud provider is how the AWS cloud provider works. See https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#aws


Add new lnInvoicePaymentSend use case

Description
This PR will eventually zero in on the changes for implementing the various Ln send payment use-case methods.
It will start with the same diff from #568 and then commits will progressively drop from the diff as the smaller PRs from list below get merged.
Starting diff is: 8785250..e15dcce
(force-push to rebase to tip of main and resolve conflicts just after PR was opened)
For reviewers
This branch is now ready for review.

the only big open question remaining is how we'd like to translate/handle the domain errors being returned from the use-case to the Application errors that graphql expects

old pay method and related methods need to be removed once the review process is finished (I'm keeping them around for now to test things against)

there is a fair amount of duplicated code between ln-send-payment.ts and intraledger-send-payment.ts that I deliberately didn't try de-duplicate since we've previously discussed that we should avoid premature de-duping

PRs to be merged

[x] #580
[x] #581
[x] #582
[x] #583
[x] #586
[x] #591
[x] #592
[x] #594
[x] #598
[x] #622

Open TODOs

[x] ~Double-check in this PR and against all the PRs above to make sure we're sending forward properly formatted Error messages~ (errors accounted for in all prior PRs; see #583 for explicit domain-to-application error handling)
[x] Connect domain errors to applications errors for new use-case
[x] Implement existing graphql errors in a new file within the graphql dir with any cleanups required to the error classes (no imports from core)
[ ] Required migration (https://github.com/GaloyMoney/galoy/pull/588#discussion_r727378681)
[ ] Check if we need a follow-up PR for potential user DB conflict Juan flagged

Update
This branch is now ready for review.

the only big open question remaining is how we'd like to translate/handle the domain errors being returned from the use-case to the Application errors that graphql expects
old pay method and related methods need to be removed once the review process is finished (I'm keeping them around for now to test things against)

Update
This branch is now ready for review.

the only big open question remaining is how we'd like to translate/handle the domain errors being returned from the use-case to the Application errors that graphql expects

old pay method and related methods need to be removed once the review process is finished (I'm keeping them around for now to test things against)

there is a fair amount of duplicated code between ln-send-payment.ts and intraledger-send-payment.ts that I deliberately didn't try de-duplicate since we've previously discussed that we should avoid premature de-duping

force-push (here) to add suggested changes to tests

force-push (here) to add WIP domain-to-application error mapping work
force-push (here) to re-add lnNoAmountInvoiceSend amount non-zero validation

force-push (here) to update to latest main

force-push (here and here) to add friendly error messages to error app and refactor domain errors to support this. At this point, all the prior error messages from the existing pay method should be accounted for in the map.

force-push (here & here) to rebase new changes from main and to add "remaining limit" helper functions

force-push (here) to ensure 'remaining limits' cannot be less than 0 in test helper methods

force-push (here) to fix unit tests

force-push (here) to assign more skipped domain errors in error map

check code test is failing on the PR here but make check-code works (and breaks) perfectly locally and in-VS-code linting also works well for the error-map exhaustiveness switch that is causing the break on here (introduced in https://github.com/GaloyMoney/galoy/pull/588/commits/eb67965aa6d930ae1ae7311ba832ee354aab438c)


API-Gateway module CR blocking deletion

Description
Changes proposed in this pull request:

API-Gateway module CR blocking deletion

Related issue(s)

https://github.com/kyma-project/api-gateway/issues/559

/test pull-api-gateway-test


Update crate owners

Because I saved the name bitcoin-io I am showing up as an owner (on crates.io) of the new bitcoin-io crate. This, IMO, is not correct. If anyone should be an additional owner that crate it should be @TheBlueMatt since he wrote it.
Furthermore, we should revise the crate ownership of all the crates in the rust-bitcoin repository with the following in mind:

Have multiple owners to mitigate the bus factor
Have owners with long standing in the Bitcoin community

I personally do not want to be an owner of any of the crates in the rust-bitcoin org unless I specifically wrote them (eg, rust-ordered) because I have not been a part of the Bitcoin community for long enough.

Ok, of the 22 repos in this org I have identified the following as "core" crates that should have multiple owners:

base58ck
bitcoin
bitcoinconsensus
hashes
hex
internals
io
ordered
secp256k1

We then have miniscript co-owned by me an Sanket which I think is correct, bitcoind owned by Riccardo and Leo which also seems correct, bech32 owned by Clark and Matt and me, and bitcoincore-rpc owned by Steven and @tcharding (which sounds like @tcharding took one for the team to increase the bus factor on a thankless and frustrating crate :P).
We also have the website repo which I don't think is a crate.
You're welcome to check my work, but I believe everything else is unmaintained (including 4 which are explicitly archived on Github). As a separate issue we may want to audit these and decide whether we should explicitly mark them on RUSTSEC as being unmaintained as a warning to users.
With the the exception of secp, which I like to keep a close grip on, I think it's reasonable that all of these should be co-owned by me, @sanket1729, @tcharding, and possibly @Kixunil and @TheBlueMatt if they are willing.
I appreciate that @tcharding has only been around for a couple of years. On the other hand, our crazy lockfile system and general crates.io inflexibility mean that I'm really not worried about him (or anyone) publishing a rogue version of these crates without being noticed very quickly and having their reputation permanently destroyed. (I am also confident that everyone listed is a single individual using a name that they widely use professionally, and is not some ephemeral pseudonym ready to be torched.)
Though I guess, it would be reasonable fo us to have a top-level manifest somewhere with the latest versions of all tools, and a script to verify against crates.io if that changes. I might set up a local cronjob which emails me if this ever changes. It'd be an extra annoying thing to maintain but OTOH it's not the end of the world if we're slow about it, it just means we'd get some warning emails around release time. (This tool would maybe also be useful for planning/tracking releases, which involves coordinating a tree of dependencies that AFAICT isn't explicitly drawn out anywhere.)

Missing

units (current owners Andrew)

I'm going to go ahead and file a RustSec advisory for rust-wallet because it has an issue already that can be used in the filing: https://github.com/rust-bitcoin/rust-wallet/issues/36

I'm really not worried about him (or anyone) publishing a rogue version

I can actually do this without ownership of any other crates because I'm owner of ordered. If I was malicious or compromised I could push an exploit as part of a point release to ordered and then anyone using that feature would run the code soon as cargo automatically pulled down the new point release. Same applies for other devs with publish rights to any crate depended on by rust-bitcoin.
I agree we should have some system in place that notifies when new releases are pushed to crates.io - the versions to check against likely should be kept locally on devs machines otherwise if in a file online that file just becomes part of the attack. This is starting to sound like a general software development issue that someone else should have already solved.
Since most applications are using ~3000 other random dependencies it might not be worth the additional bother to lock rust-bitcoin down too much more than that. But at  some stage in the future perhaps we should?

I think it's reasonable that all of these should be co-owned by me, @sanket1729, @tcharding, and possibly @Kixunil and @TheBlueMatt if they are willing.

As long as there are at least 3 owners on each crate then I am willing to taking on that responsibility.

If the purpose of having keys is primarily redundancy; sign me up. I can assure that I don't intend to use any of push permission and I won't even register a new token for pushing stuff to rust bitcoin or miniscript org.
Any push from my account should be by default considered compromised unless we discuss otherwise beforehand.
w.r.t supply chain attacks, I don't think they fall in the scope of this issue. Users might vendor code or actively review what is published and downloaded.

I agree we should have some system in place that notifies when new releases are pushed to crates.io - the versions to check against likely should be kept locally on devs machines otherwise if in a file online that file just becomes part of the attack. This is starting to sound like a general software development issue that someone else should have already solved.

Well, crates.io solved it to the extent that they will publish on their website when dependencies get updated. But it's on us to fetch that data and do something useful for us as far as sending notifications. Though it may be that crates.io itself has a way for us to be emailed when new stuff is released..
I think it's fine to have the reference be in a git repo on github. Yes, in theory somebody could just push to this (though we can prevent direct pushes in github and add a one-ack rule for pull requests), but that wouldn't immediately update anyone's machines and it would be very visible when they did.

Since most applications are using ~3000 other random dependencies it might not be worth the additional bother to lock rust-bitcoin down too much more than that. But at some stage in the future perhaps we should?

I don't think we should compare ourselves to "most applications" :).

Oh that is a good idea, we can both declare that our publish permissions are only for the case where @apoelstra is AWOL, assumed dead, or certified mad. Then any publish by me or @sanket1729 can be assumed malicious. I like it!

Lol, that's a good point. We can easily script that (assuming we have scripts to notice updates at all).

I don't think we should compare ourselves to "most applications" :).

Woops, I meant most applications that use rust-bitcoin ie., even if rust-bitcoin is locked down they likely have a ton of other dependencies that can be attacked.

I'm willing to be a co-owner, I'll just need to take more time to improve opsec which I wanted already but this would be a strong motivation.
@sanket1729 oh it's really cool we can issue tokens for specific crates now! That might help.
Also can we publish signatures of the crate hashes somewhere? That'd be much stronger than trusting crates.io and much harder to compromise if people start requiring multiple of them. Note that I'm aware of crev, it's just super large and complicated with tons of dependencies so there's a bootsrapping problem.

even if rust-bitcoin is locked down they likely have a ton of other dependencies that can be attacked.

Am I the only one who took extreme caution around dependencies when writing security-critical code?

Another topic to perhaps discuss at the summit?


Video Recording Stutters Heavily at Beginning

Video stops or shows dropped frames during playback at beginning of recorded session. Converted the video into a gif to try to give an example.

@masonvscode,
Can you please share the code you're using to begin and end recording a video.
Also, can you specify what device are you testing on?
-Ahmed

iPhone X and iPhone 7, seems to be more prevalent on iPhone X

The above recording came from using the example project that comes with this library, unchanged.
On the iPhone X, I'm running iOS 11.2.1. Thanks!


Stop allowing None in add_profile

Both implementations allow passing None (at runtime) but this functionality isn't used.

This function was removed.


How can I add the sitemap to asp.net core MVC project there is no web.conffig file? Thanks

How can I add the sitemap to asp.net core MVC project there is no web.conffig file? Thanks

Hello! Thanks for contacting us. This sounds like a general question about using ASP.NET Core. While we try to look at and respond to all issues, for questions like this we recommend posting to a community support group like Stack Overflow with the asp.net-core tag.


haskell.packages.ghcjs: misc fixes

Various fixes I needed to build a project that depends on lens.

Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

@ncfavier Thanks!
Since this is changing pkgs/development/haskell-modules/configuration-common.nix, I think it'd be safer to have this go into haskell-updates.
Maybe @dfordivam would be able to review this?


New Issue, Goosey trying to execute a .exe with python and i cant make the gui version of the tool work.

🐛 Summary
When i configure the config file, and i click Start to start to extract logs with the goose-gui, it gives me the error that it doesnt find the goose-gui file in the directory .venv\Scripts\goosey-gui. I think its because the tool is trying to open a .exe with python, how can i solve it? or its a native bug? Its crazy, cause when i use the DIR command in cmd, it shows me a .exe, but when i open the directly in windows gui its a python file.  (And the problem is not the language of the name of the directory of the desktop, cause i have the same error using english language)
Steps to reproduce the behavior:

I configure the config file
I click at Start

Expected behavior
Extract the logs and create the file.
Any helpful log output or screenshots

@victoriawallace-cisa @h-m-f-t @sangling

Thanks, I'll take a look at replicating the issue. It looks like you installed Python using the Microsoft store, so I should be able to replicate it soon.

@thebrainiak We've fixed the issue in the latest update of Untitled Goose Tool. Please update the tool, re-install it, and try it again and let us know how it goes.


Fatal: Mix manifest not found

Mix manifest not found at: /Users/efb/Sites/statablog/public/mix-manifest.json
"Did you forget to run npm install && npm run dev?"
To reproduce: installing through CLI
statamic new Sites/statablog
Installing a starter kit? yes
statamic/starter-kit-starters-creek
Environment
Application Name: Statamic
Laravel Version: 10.28.0
PHP Version: 8.2.11
Composer Version: 2.6.5
Environment: local
Debug Mode: ENABLED
URL: statablog.test
Maintenance Mode: OFF
Cache
Config: NOT CACHED
Events: NOT CACHED
Routes: NOT CACHED
Views: NOT CACHED
Drivers
Broadcasting: log
Cache: statamic
Database: mysql
Logs: stack / single
Mail: smtp
Queue: sync
Session: file
Statamic
Addons: 0
Antlers: runtime
Stache Watcher: Enabled
Static Caching: Disabled
Version: 4.30.0 Solo

Could I get some help on installing this starter kit? I think it does not play well with the latest Tailwind CSS, too.

Finally closed with the solution found in #13


update on Document

read and approve

I ran this branch on readthedocs and it looks great. Thanks!


LP-119 Add initial api spec

Jira: https://companieshouse.atlassian.net/browse/LP-119
Add spec with supposed create endpoint, this is based on the initialisation of the spec for roe.
Added mongo, related timezone post construct as it was requested for LP-111 and there is no mongo subtask.

In the Dev workshop earlier, Mike's design document has the endpoints with /limited-partnership/ (no s)
https://companieshouse.atlassian.net/wiki/spaces/Arch/pages/4722491429/LP+Service+Design

Updated the schema to reflect https://companieshouse.atlassian.net/wiki/spaces/Arch/pages/4722491429/LP+Service+Design
As we do not have schema details yet that will have to be added later.

LGTM


traefik_route_k8s lib should be owned by traefik-k8s-operator

Enhancement Proposal
Most of the issues we're getting for traefik_route_k8s library are reported in this repository, although officially it's traefik-route-k8s-operator  that owns this charm library.
There was a fix we did in traefik_route_k8s by accident on this repository (see #325) and it wasn't noticed so this fix also was never released.
It looks like owning traefik_route_k8s by this charm might be closer to the real use and reduce confusion.

This is done.


Ensure pictures taken with CALF VR180 are supported

My Wordpress site is stripping the metadata and it results in an error after parsing the EXIF and other headers:
Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'GPano')
    at parseVR (stereo-img.js:23:19)
    at async HTMLElement.parse (stereo-img.js:218:25)
    at async HTMLElement.parseImageAndInitialize3DScene (stereo-img.js:275:5)
    at async HTMLElement.init (stereo-img.js:292:5)

A simple null-coalesce should solve the problem, or just short-circuiting and going with defaults if exif is undefined.

I've continued working on this a bit. I made sure the original photo with metadata was being returned and I'm still getting the error. Your demo page loads it from my local machine, but I can't get it to work on my remote image URL. Here it is in case it helps. Here's my embed if it helps:

Note that the image is 10MB. Not sure if it matters. It appears to load fine and parse ok, just not the EXIF metadata.

Is the image served from the same origin (domain) as the page?
It is a requirement that it does. See https://github.com/steren/stereo-img/issues/14

Yes. It's the same domain, same site.
On Sun, Oct 22, 2023, 11:47 AM Steren @.***> wrote:

Is the image served from the same origin (domain) as the page?
It is a requirement that it does. See #14
https://github.com/steren/stereo-img/issues/14
—
Reply to this email directly, view it on GitHub
https://github.com/steren/stereo-img/issues/20#issuecomment-1774141370,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYMEEV5376PRKZRC4YK2F3YAVEZJAVCNFSM6AAAAAA6KTJ3ASVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZUGE2DCMZXGA
.
You are receiving this because you authored the thread.Message ID:
@.***>

I put a test page up:
https://www.vrvoyaging.com/stereo-image-test/
password: stereo
I got it to render the image correctly once when I had an unclosed quote somewhere. I didn't take note of it closely enough so I'm not sure what it is.

I see you are using an absolute URL with the domain, try using a relative URL.  In my example, the URL is examples/vr180-lenovo-mirage.vr.jpg

I changed it to a relative url (/wp-content/uploads/2023/10/V1000064.jpg). Same result

Can you try with an example at https://github.com/steren/stereo-img/tree/main/examples to be sure that the issue doesn't come from your image?

In other words: please try to troubleshoot the root cause with more testing

It must be the images. These are coming straight from the new Calf VR180 camera. It might be good to see what's different about them as it's a popular camera (in VR180 circles) right now. I wonder if it's because it's expecting a single image in the main image section and the other eye in the metadata like the Lenovo was. This is L-R but also fisheye. Does it require new maybe?
I wrote a review on the camera and link to a zip file with some sample photos (it produces fisheye L-R 3D and flat SBS images in addition to video).
Article: https://www.vrvoyaging.com/calf-3d-camera-powerful-tech-at-a-mid-range-price/
Samples: https://drive.google.com/file/d/1FSjZVGfc-0Ax_yJiT2-pnuRj-nvPcRq0/view?usp=share_link

Nice, I didn't know about the Calf VR180 camera, I might get one! (It's definitely less than going with a Canon EOS R5 + Dual Fisheye Lens)
Thanks for the samples. Are you OK if I add one of them to the examples folder?

On the demo website, I am able to

load the samples if I use the file picker
load the image from the URL if I add it to examples and use <stereo-img src="examples/V1000064.jpg" type="left-right", angle="180"></stereo-img>

So the problem seems to come from how you embed these images on your website. Can you try on your website to display this image (we're sure that it works)

Also, I am curious can you share more details how each file has been created?
For example, V1000060.jpg and V1000064.jpg do not seem to be using the same technique / format, as they don't have the same aspect ratio and one seems to be more fisheye than the other

Here are some additional samples right off the camera. These aren't ok to distribute, but you're welcome to use what's in the original sample zip as samples in this repo. I can provide more for that purpose if you need.
I must have been tripping. I could have sworn there was a panorama or some other picture mode, but I'm only seeing the VR180 and flattened options now.
Still images
https://drive.google.com/file/d/1B0Aeoa55B4lylHsG7Ug-4cGrS0_BUCfk/view?usp=drive_link
Videos
https://drive.google.com/file/d/1E1PFi8KbouNMI7HZOnSw1dLiBRmZrxaN/view?usp=drive_link

Thanks.
That's interesting that VR180 images from CALF are left-right images. VR180 images produced by Google VR180 cameras or apps (Cardboard Camera, or Lenovo Mirage Camera) are storing the right eye pixels in the exif of the image, so that on a regular viewer, only the left eye is showed. This is what stereo-viewer is doing: it extracts right eye from the GImage exif.
In the case of CALF, it looks like it just stores left and right, which still works with stereo-img.

Back to your problem: it looks like https://www.vrvoyaging.com/stereo-image-test/ doesn't serve stereo-img anymore. Is it intentional?

It's still using it. Just on the first image, not on the second. If I use type="left-right" and angle="180" is that actually going to be the correct projection? There's the question of equirectangular vs fisheye.

using <stereo-img src="examples/V1000064.jpg" type="left-right", angle="180"></stereo-img>, were you able to have the image work on your website?
I am not able to see any content on https://www.vrvoyaging.com/stereo-image-test/

Sorry, I changed the visibility of it and thought you'd still see it. You can try again. Yes, left-right and 180 works, but I'm not positive the projection is right.

Great to know. Have you figured out what the problem was?
I'll keep this issue open to track any bug with your example files

Looking at the spec, I'm not actually convinced that VR180 requires using metadata for the right image. it looks like left-right SBS could be considered conforming. it seems to leave lots of leeway really, other than fisheye (no reprojecting), motion stream (for correcting/compensating later), and lots of metadata fields to ensure correct decoding.
in Windows, it's weird to me that Explorer shows mono fisheye thumbnail preview for the Calf MP4 files, but Calf images are all fisheye SBS. My old Lenovo Mirage video files are mono fisheye thumbnail, while the images are mono equirect projection (though the image files were indeed right-image-as-metadata in the full file).
So either Calf is being generous calling it "vr180" or it's just a variant to support. Regardless, hopefully its metadata gives enough clues to be able to handle it without needing to set very specific type and angle properties.

The spec you pointed to seems to say it applies to "Videos"
As far as I know, spec for images is here, notably, see the GImage exif.
Like you, from my experience with VR180 generated via Lenovo Mirage Camera are:

side to side for videos
right eye in exif for images

I need to inspect the exif of the files produced by Calf, it's likely they contain the many metadata that I need to extract (e.g. pitch and roll, which I only extract in the case of type="vr").
I'll update this issue with my findings.
Thanks a lot for the samples.

anything else I can help with? there seems to be a total lack of exif data which makes it pretty tough... maybe it would be helpful to engage with the devs on Discord

I haven't found the time yet to dive into this issue, I might around winter holidays.

Wow, it seems that the sample images you shared have absioltly no exif data (try for yourself at https://mutiny.cz/exifr/)
This is going to be a problem. It means that this component will never be able to auto-detect these images. Usually, by looking at the make, model, lens model or exif, I can infer the type of stereo image, and also use the focal length to create theappropriate field of view
Here, there's absolutely nothing. Yes, engaging with the developers would help. Do you want to do this?

Update: I bought a Canon EOS R5 with the dual fisheye lens. I will be adding support for it first (see #21), I will try to add support for CALF shortly after, as the work seems very similar

Both pictures are working fine:
For the left-right:  <stereo-img src="examples/calf-left-right.jpg" type="left-right"></stereo-img>
For the "VR180":  <stereo-img src="examples/calf-vr180.jpg" angle="180"></stereo-img>
Note that you should not use type="vr" since the picture does not conform to Google's VR Photo format


How to modify policy for 1.12 compatibility

Kyverno Version
1.10.x
Kubernetes Version
1.26.x
Kubernetes Platform
EKS
Description
Hi when we updated from 1.11 to 1.12 this policy stopped working
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: prevent-label-on-other-images
spec:
  validationFailureAction: Enforce
  background: false
  rules:
  - name: check-label-on-non-code-server-pods
    match:
      resources:
        kinds:
        - Pod
    preconditions:
      all:
      - key: "{{ request.object.metadata.labels.\"ssh-enabled\" | to_string(@) }}"
        operator: In
        value: ["true", ""]
    validate:
      message: "The label 'ssh-enabled' is only allowed on pods with the 'alpine' image."
      pattern:
        spec:
          containers:
          - image: "alpine*"

Steps to reproduce

Copy and past the policy and try to run it, we do also have an istio side car, however this wasn't stopping anything before.

You're welcome to use this one liner:
kubectl run testimage --image alpine:3.18.5 --labels="ssh-enabled=true"
Error from server: admission webhook "validate.kyverno.svc-fail" denied the request:
resource Pod/test/testimage was blocked due to the following policies
prevent-label-on-other-images:
check-label-on-non-code-server-pods: 'validation error: The label ''ssh-enabled''
is only allowed on pods with the ''alpine''
image. rule check-label-on-non-code-server-pods failed at path /spec/containers/0/image/'
Expected behavior
i expect the wildcard to allow any version of alpine to run. if i did this wrong for 1.11.2 let me know
Updated here: typo'd 1.12
Screenshots
No response
Kyverno logs
No response
Slack discussion
No response
Troubleshooting

[X] I have read and followed the documentation AND the troubleshooting guide.
[X] I have searched other issues in this repository and mine is not recorded.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: prevent-label-on-other-images
spec:
  validationFailureAction: Enforce
  background: false
  rules:
  - name: check-label-on-non-code-server-pods
    match:
      any:
      - resources:
          kinds:
          - Pod
    preconditions:
      all:
      - key: "{{ request.object.metadata.labels.\"ssh-enabled\" || '' }}"
        operator: AnyIn
        value:
        - "true"
        - ""
    validate:
      message: "The label 'ssh-enabled' is only allowed on pods with the 'alpine' image."
      pattern:
        spec:
          containers:
          - image: "alpine*"

did you try to deploy with the policy? I really appreciate the quick response but i see the same error with the policy edit to the preconditions you've provided:
kubectl run testimage --image=alpine:3 --labels="ssh-enabled=true"
Error from server: admission webhook "validate.kyverno.svc-fail" denied the request:

resource Pod/test/testimage was blocked due to the following policies

prevent-label-on-other-images:
  check-label-on-non-code-server-pods: 'validation error: The label ''ssh-enabled''
    is only allowed on pods with the ''alpine'' image. rule check-label-on-non-code-server-pods
    failed at path /spec/containers/1/image/'

should i be trying a regex split in the pattern section? I am not sure the right way to do this, but it seems like a bug if the intention is for the wildcard to work

I tested this on 1.11. It should be no different for 1.12 which is still in development.

I copied and pasted your yaml and tested just to make sure before answering
The first error is more concerning where if the label doesn't exist it won't let pods launch at all, so i had to turn this policy to audit for now:
kubectl run testimage --image=alpine alpine
Error from server: admission webhook "validate.kyverno.svc-fail" denied the request:

resource Pod/test/testimage was blocked due to the following policies

prevent-label-on-other-images:
  check-label-on-non-code-server-pods: 'failed to evaluate preconditions: failed to
    substitute variables in condition key: failed to resolve request.object.metadata.labels."ssh-enabled"
    at path : JMESPath query failed: Unknown key "ssh-enabled" in path'

and
kubectl run testimage --image=alpine --labels="ssh-enabled=true"
Error from server: admission webhook "validate.kyverno.svc-fail" denied the request:

resource Pod/test/testimage was blocked due to the following policies

prevent-label-on-other-images:
  check-label-on-non-code-server-pods: 'validation error: The label ssh-enabled is
    only allowed on pods with the alpine image. rule check-label-on-non-code-server-pods
    failed at path /spec/containers/1/image/'

In the second error perhaps containers/1/image means it is accounting for my sidecar (it didn't use to). are you running 1.11.2 or 1.11.1, i had to upgrade because the of the bug that caused all the update requests to never delete, degrading the cluster performance over time.

How exactly are you installing Kyverno and with what method to see these results? The policy I provided above was tested on 1.11.1 and with your kubectl run command.

I just check checked this policy on the latest state of development by installing the experimental manifest and it works. Here is a better version:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: prevent-label-on-other-images
spec:
  validationFailureAction: Enforce
  background: false
  rules:
  - name: check-label-on-non-code-server-pods
    match:
      any:
      - resources:
          kinds:
          - Pod
    preconditions:
      all:
      - key: "{{ request.object.metadata.labels.\"ssh-enabled\" || '' }}"
        operator: Equals
        value: "true"
    validate:
      message: "The label 'ssh-enabled' is only allowed on pods with the 'alpine' image."
      pattern:
        spec:
          containers:
          - image: "alpine*"

This policy can be simplified still (yet autogen will be implicitly disabled):
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: prevent-label-on-other-images
spec:
  validationFailureAction: Enforce
  background: false
  rules:
  - name: check-label-on-non-code-server-pods
    match:
      any:
      - resources:
          kinds:
          - Pod
          selector:
            matchLabels:
              ssh-enabled: "true"
    validate:
      message: "The label 'ssh-enabled' is only allowed on pods with the 'alpine' image."
      pattern:
        spec:
          containers:
          - image: "alpine*"

Yeah i don't think the issue is in the precondition, i think the issue is manifesting in the pattern section. I tried the following policy and i was able to launch an istio container, which launched with an istio side car (two containers in the pod same image) but i was not able to launch an alpine container (so istio side car, and alpine container in the same pod). I also temporarily rolled my deployment back to 1.11.1 so we're on the same policy engine. How do I make the pattern matching or?
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: prevent-label-on-other-images
spec:
  validationFailureAction: Enforce
  background: false
  rules:
  - name: check-label-on-non-code-server-pods
    match:
      resources:
        kinds:
        - Pod
    preconditions:
      all:
      - key: "{{ request.object.metadata.labels.\"ssh-enabled\" || '' }}"
        operator: AnyIn
        value:
        - "true"
        - ""
    validate:
      message: "The label 'ssh-enabled' is only allowed on pods with the 'alpine' or 'docker.io/istio/proxyv2' images."
      anyPattern:
        - spec:
            containers:
              - image: "alpine*"
        - spec:
            containers:
              - image: "docker.io/istio/proxyv2*"

Since you don't have istio installed I assume, here is a deployment yaml you can copy and paste:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: alpine-istio-deployment
  labels:
    app: alpine-istio
spec:
  replicas: 1
  selector:
    matchLabels:
      app: alpine-istio
  template:
    metadata:
      labels:
        app: alpine-istio
        ssh-enabled: "true"
    spec:
      containers:
      - name: alpine-container
        image: alpine
        command: ["/bin/sh", "-c", "while true; do sleep 60; done"]
      - name: istio-proxy-container
        image: docker.io/istio/proxyv2:1.20.1
        # The following are example settings, customize these as needed.
        env:
          - name: ISTIO_META_WORKLOAD_NAME
            value: "alpine-istio-workload"
          - name: ISTIO_META_OWNER
            value: "kubernetes://api/apps/v1/namespaces/default/deployment/alpine-istio-deployment"
        securityContext:
          runAsUser: 1337
        # Additional configuration for the Istio proxy container goes here.

Try this instead:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: prevent-label-on-other-images
spec:
  validationFailureAction: Enforce
  background: false
  rules:
  - name: check-label-on-non-code-server-pods
    match:
      any:
      - resources:
          kinds:
          - Pod
    preconditions:
      all:
      - key: "{{ request.object.metadata.labels.\"ssh-enabled\" || '' }}"
        operator: Equals
        value: "true"
    validate:
      message: "The label 'ssh-enabled' is only allowed on pods with the 'alpine' image."
      pattern:
        spec:
          ^(containers):
          - image: "alpine*"

That works! i really appreciate the help i have no idea how i would have figured that out. But does that mean that someone could list the image as part of a set of images in the pod/replicaset/deployment/statefulset spec but then simply list and use their own image instead (basically use the alpine image as a dummy while they do whatever they want with their own container in the pod and ssh to that. We're trying to enforce that people can only ssh to our specific container in the pod image.
its seems like malicious compliance issues and concerns could still be in play, which is why we wanted to only allow one of two images (our container and the side car) as allowed to have that ssh-enabled label. Does this make sense? Any guidance for handling this?
for context here is the auth policy that we have:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: generate-istio-auth-policy-for-ssh
spec:
  rules:
  - name: generate-istio-auth-policy
    match:
      resources:
        kinds:
        - Pod
        selector:
          matchLabels:
            ssh-enabled: "true"
    generate:
      kind: AuthorizationPolicy
      apiVersion: security.istio.io/v1beta1
      name: allow-ssh
      namespace: "{{request.object.metadata.namespace}}"
      data:
        metadata:
          labels:
            ssh-enabled: "true"
        spec:
          selector:
            matchLabels:
              ssh-enabled: "true"
          action: ALLOW
          rules:
          - to:
            - operation:
                ports: ["22"]

I could compliment these policies with the following?
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: limit-containers-in-ssh-enabled-pods
spec:
  validationFailureAction: Enforce
  rules:
  - name: max-two-containers-for-ssh-enabled
    match:
      resources:
        kinds:
        - Pod
    preconditions:
      all:
      - key: "{{ request.object.metadata.labels.\"ssh-enabled\" }}"
        operator: Equals
        value: "true"
    validate:
      message: "A pod with 'ssh-enabled' set to true may have no more than two containers."
      deny:
        conditions:
        - key: "{{ request.object.spec.containers | length }}"
          operator: GreaterThan
          value: 2

to ensure just in our specific case that people can't list more containers since in our system we're making a special exception we don't want to be subverted? but if there is a more straight forward way to do this in the original image checking policy it would be fine to collapse it all down into one policy. Might just be a limitation of kyverno though, which if fine we can use our brains and write more policy rules to cover ourselves.

But does that mean that someone could list the image as part of a set of images in the pod/replicaset/deployment/statefulset spec but then simply list and use their own image instead (basically use the alpine image as a dummy while they do whatever they want with their own container in the pod and ssh to that. We're trying to enforce that people can only ssh to our specific container in the pod image.

The above policy means, "if you see the label ssh-enabled: true on a Pod then that Pod must have at least one container with an image beginning with the string alpine." That's all it expresses. So if you want something different you'll have to define those intentions.
Also, I've noticed in your samples you keep omitting any/all blocks from match/exclude and deny.conditions.  You need to specify one or the other. To not do so is not only deprecated but has known issues. This works all the way back to about 1.6 or so.

This policy appears to compress them both down appropriately and ensures that if ssh is to be allowed and an authpolicy supporting an ssh connection is enabled, it would require that our ssh container (in this case alpine as our example) and only our ssh container be listed in the pod spec:
The modular control is nice once you get the hang of it. Much appreciated!
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: enforce-ssh-on-specific-container-with-sidecar
spec:
  validationFailureAction: Enforce
  background: false
  rules:
  - name: ssh-enabled-container-check-with-sidecar
    match:
      any:
      - resources:
          kinds:
          - Pod
    preconditions:
      all:
      - key: "{{ request.object.metadata.labels.\"ssh-enabled\" }}"
        operator: Equals
        value: "true"
    validate:
      message: "When 'ssh-enabled' is 'true', the pod must have exactly two containers, one of which must be 'alpine:*'."
      deny:
        conditions:
        - key: "{{ request.object.spec.containers | length }}"
          operator: NotEquals
          value: 2
        - key: "{{ request.object.spec.containers[0].image }}"
          operator: NotEquals
          value: "alpine*"

That will only work if the first image in the list of containers is alpine which probably isn't a good idea.


Sometimes the model (or ollama) returns nothing - model: llama 3.1 8B

What is the issue?
In a simple conversation, 50/40% of the time it returns nothing. I just run the model normally:
ollama run llama3.1
And after a successful start, I make some random questions. Sometimes it responds. Some times it returns empty.
This is not happening with llama3 8B model.
My NVIDIA has 12GB and the PC has 32GB.
OS
Linux
GPU
Nvidia
CPU
Intel
Ollama version
0.2.5

it is ok for me on MAC. m3 max 128GB

I updated to ollama 0.2.7. Now it's working fine.


Support similar solution as AVRO-1642

Right now. if the avro schema contain too many field,  Java will complain  error: code too large for the builder function. We have to manually delete builder class in these cases. It will be helpful to have a option to turn off generating two builder function.

My understanding of the history of https://issues.apache.org/jira/plugins/servlet/mobile#issue/AVRO-1642 is that the Avro compiler was enhanced to not generate the all argument constructor above a certain limit. If that's the case, it can be used with this plugin simply by using the appropriate version of Avro as part of the compilation process. If 1.8.2 contains the enhancement, the latest version of this plugin should already work. If you're looking for a different behavior that the compiler doesn't expose as an option, you'll need to get that included upstream in the Avro project before I'm able to do anything about it.

I see the issue is because of builder() function. No invalid constructor has been generated.  I will open a issue in Avro project to discuss that.


Hash mismatch prevents building with GOPROXY=direct

Describe the bug
I generally run go with GOPROXY=direct, which bypasses the Google-run module cache and downloads modules sources directly from their repos. Terragrunt fails to be built with this option set, due to a hash mismatch on an indirect dependency.
To Reproduce
I ran these commands in a current golang docker container, to make sure nothing in my environment was causing (additional) issues:
docker pull golang:latest
docker run -it golang:latest

$ git clone --depth=1 https://github.com/gruntwork-io/terragrunt.git
[...]
$ cd terragrunt
$ git rev-parse HEAD
419ea3a485aafc79dd5ca89da615d06b6fd0f991
$ GOPROXY=direct go build main.go
go: downloading github.com/gruntwork-io/go-commons v0.17.1
[...]
go: downloading github.com/hashicorp/hcl v1.0.1-vault
go: downloading github.com/zclconf/go-cty v1.13.2
verifying<EMAIL_ADDRESS>checksum mismatch
	downloaded: h1:/JhJsLUPC73zeqSbkZApgsofP4iB++zgDHS5t6ZL0Lc=
	go.sum:     h1:UiJeEzCWAYdVaJr8Xo4lBkTozlW1+1yxVUnpbS1xVEk=

SECURITY ERROR
This download does NOT match an earlier download recorded in go.sum.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

For more information, see 'go help module-auth'.

Expected behavior
This build should succeed.
Additional context
I'm not a go packaging expert, so take all this with a healthy grain of salt :) My understanding is that go's tooling all makes the (reasonable) assumption that a tagged release will not change. However, it turns out that 1.0.1-vault is in fact a branch, not a tag, and it has moved. proxy.golang.org, being a caching proxy, provides the first seen version of 1.0.1-vault (which I believe to be https://github.com/hashicorp/hcl/commit/809e678c39ec71ae0b37a792de60b7e10e571dfe), while an install with GOPROXY=direct fetches the tip of the branch from its repo, which is https://github.com/hashicorp/hcl/commit/cf4c4bf2466d28b8fd0e9953ee5eb7caa3af5418.
It doesn't seem to me like there's an obvious way to make the<EMAIL_ADDRESS>dependency work; either I leave it with an outdated hash so that it works with the proxy (and presumably, for the majority of Go users who don't override the default GOPROXY option), or I update the hash and it works for me but breaks for anyone who uses the default proxy.
However, a fairly straightforward fix would be to either upgrade or downgrade the version of the indirect dependency; it appears to be required only by https://github.com/hashicorp/terraform-config-inspect/blob/master/go.mod#L6C1-L6C61 which merely requires a version greater than v0.0.0-20170504190234-a4b07c25de5f and less than 2.0, so any of the versions listed at https://pkg.go.dev/github.com/hashicorp/hcl?tab=versions (which are all tags, except v1.0.1-vault which we had the bad luck to land on) should work.

If either a downgrade to<EMAIL_ADDRESS>or an upgrade to<EMAIL_ADDRESS>(the newest 1.x version) or something else entirely makes sense, I'd be happy to open a PR for such! But I figured I'd make sure that made sense before making and testing a PR.


Figura crashes with FFAPI and Connector

Mod Name
Figura
Mod Homepage
https://modrinth.com/mod/figura
Describe the bug
Crashes when loading/ creating a new world
Steps to reproduce

install Figura and Connector and FFAPI
load or create a world
crash
...

Logs
https://mclo.gs/7pZgbN7
Additional context
Figura loads on beta 27 but crashes when wearing any armor while having custom avatar selected: log
crashes when loading/ creating a new world on beta 28

Same issue as https://github.com/Sinytra/Connector/issues/571


[Snyk] Upgrade @navikt/aksel-icons from 2.8.16 to 2.9.0

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade @navikt/aksel-icons from 2.8.16 to 2.9.0.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 1 version ahead of your current version.
The recommended version was released 21 days ago, on 2023-04-26.

Release notes

Package name: @navikt/aksel-icons

2.9.0 - 2023-04-26

2.8.16 - 2023-04-24

    from @navikt/aksel-icons GitHub release notes

Commit messages

Package name: @navikt/aksel-icons

d5c040d Version Packages (#1942)
250d6c5 :arrow_up: Yarn lock
de69c6c :bug: Sync ds-css version with CLI
657b7f3 Fragmentert CSS + CLI-verktøy `@ navikt/aksel` (#1941)
00697c7 :coffin: Fjernet Snyk-scans fra workflows (#1940)
a556ac6 :coffin: Fjernet Snyk-scans fra workflows (#1940)

Compare

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Oppgradert andre steder


Use dependencies instead of stageDependencies in stage to stage variable references.

stageDependencies is for jobs to reference results from other stages, to my knowledge.

@juliakm - can you review the proposed changes?
IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


Enable multiple entry points with webpack

We have two example modules that can be run in the browser (soon there will be three). It would be nice if we could have multiple entry points configured through webpack to run different examples. Defining multiple entry points itself is not particularly hard,  but we need to get it to work nicely with the bundler and dev server

We've changed the way we use webpack, so we don't really need to worry about this anymore


Replace usage of old variables where identical

For more Information see: #1195

@oliverschuerch I'm inclined to close this as a duplicate of #1195, what do you think?

Duplicates #1195


Add anchor links to the documentation subheaders

What happened?

What were you attempting to do?
I wanted to link to a subsection in the docs and could not because those headers don't have anchor tags.

What did you expect to happen?
I expected there to be an anchor I could link to.

This has been addressed. Check out, for instance: https://paketo.io/docs/howto/dotnet-core/#build-a-sample-app


Hub, PivotBarItem and other components missing

Hey there,
thanks for building this sample repo - much apprecheated.
We were using the undocumented vss-ui package and for now it seems we can't switch to the azure-devops-ui package as some copmonents like Hub and PivotBarItem are missing in the new package.
Will those eventually be added to azure-devops-ui ?

The older internal vss-ui package was much more heavily based on Office Fabric, so some of the components have been replaced with others:
Hub was replaced by the Page component.
PivotBar was replaced by the TabBar component.


Roll Engine from fbed11637817 to 38fabd1c5170 (5 revisions)

https://github.com/flutter/engine/compare/fbed11637817...38fabd1c5170
2022-04-29<EMAIL_ADDRESS>fix impellerc on windows (flutter/engine#33003)
2022-04-29<EMAIL_ADDRESS>Remove Windows UWP Engine target (flutter/engine#33012)
2022-04-29<EMAIL_ADDRESS>use new DlObjects throughout the DisplayList code (flutter/engine#32896)
2022-04-29<EMAIL_ADDRESS>allow either host_debug or host_debug_unopt for pre-push verification (flutter/engine#33000)
2022-04-29<EMAIL_ADDRESS>Mac trackpad gestures (flutter/engine#31593)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

This roll will fail due to being based on a bad framework commit. Closing to trigger a new one.

Commit queue failed; closing this roll.