Teams Tab which is connected to SharePoint Page containing an SPFx component which uses AadHttpclient fails with Token Expiry

Hi Everyone,
We have a Teams Personal Tab which is connected to a SharePoint Page. This page contains an SPFx app which inturn uses AadHttpclient to contact Azure Function App. The setup works most of the time, however, we have a Conditional Access policy by which they need to relogin after 1 hour (for testing).
Due to this, whenever they use the Teams Personal Tab, the SharePoint page loads fine, however the functionality which needs to connect to Azure Function App fails with the below error message.
AADSTS70043: The refresh token has expired or is invalid due to sign-in frequency checks by conditional access. The token was issued on 2022-09-22T12:41:41.2700000Z and the maximum allowed lifetime for this request is 3600.
Teams doesn't seem to renew the token which it uses to call the Azure Function App.

@wizneeraj , thanks. How did you create the Teams manifest? did you use SPO App Catalog "sync to Teams"? or it is a manual manifest? If it is the latter, can you please past here the manually created manifest?
Thanks!

Thanks for the reply @lucabandMSFT . Please find below the web part manifest and the Teams Tab manifest as well.
Web Part Manifest
`{
"$schema": "https://developer.microsoft.com/json-schemas/spfx/client-side-web-part-manifest.schema.json",
"id": "03b625b0-3bb2-4bf5-h65d-7cd982895102",
"alias": "ProductRequestWebPart",
"componentType": "WebPart",
// The "" signifies that the version should be taken from the package.json
"version": "",
"manifestVersion": 2,
// If true, the component can only be installed on sites where Custom Script is allowed.
// Components that allow authors to embed arbitrary script code should set this to true.
// https://support.office.com/en-us/article/Turn-scripting-capabilities-on-or-off-1f2c515f-5d7e-448a-9fd7-835da935584f
"requiresCustomScript": false,
"supportedHosts": ["SharePointWebPart", "TeamsTab"],
"preconfiguredEntries": [{
"groupId": "5c03119e-3074-46fd-976b-c60198311f70", // Other
"group": { "default": "Other" },
"title": { "default": "Product Request" },
"description": { "default": "Self-service Solution Product Request WebPart" },
"officeFabricIconFontName": "Page",
"properties": {
"description": "Product Request"
}
}]
}`
Teams Tab Manifest
{   "$schema": "https://developer.microsoft.com/en-us/json-schemas/teams/v1.9/MicrosoftTeams.schema.json",   "version": "1.1.0",   "manifestVersion": "1.9",   "id": "44fe58ff-5bd8-4fdd-9710-122956a659c7",   "packageName": "com.package.name",   "name": {     "short": "Request Portal",     "full": "Request Portal"   },   "developer": {     "name": "Some Company",     "mpnId": "",     "websiteUrl": "https://www.somecompany.com",     "privacyUrl": "https://www.somecompany.com/privacy-statements",     "termsOfUseUrl": "https://www.somecompany.com/terms-of-use"   },   "description": {     "short": "Request Portal",     "full": "Request Portal"   },   "icons": {     "outline": "outline.png",     "color": "color.png"   },   "accentColor": "#ffffff",   "staticTabs": [     {       "entityId": "efaf3049-445a-4420-96bc-be0f2d09b441",       "name": "Collab Request",       "contentUrl": "https://contoso.sharepoint.com/sites/requestportal/_layouts/15/teamslogon.aspx?spfx=true&dest=https%3A%2F%2Fcontoso.sharepoint.com%2Fsites%2Frequestportal",       "websiteUrl": "https://contoso.sharepoint.com/sites/requestportal",       "scopes": [         "personal"       ]     },     {       "entityId": "b14b1afd-6975-4c75-996c-6c1d3ccea7bf",       "name": "Modern Workplace Tool",       "contentUrl": "https://contoso.sharepoint.com/sites/MWPT/_layouts/15/teamslogon.aspx?spfx=true&dest=https%3A%2F%2Fcontoso.sharepoint.com%2Fsites%2FMWPT",       "websiteUrl": "https://contoso.sharepoint.com/sites/MWPT",       "scopes": [         "personal"       ]     },     {       "entityId": "about",       "scopes": [         "personal"       ]     }   ],   "validDomains": [     "contoso.sharepoint.com"   ],   "webApplicationInfo": {     "id": "00000003-0000-0ff1-ce00-000000000000",     "resource": "https://contoso.sharepoint.com"   } }

@wizneeraj , thanks.
looks like the "webApplicationInfo" portion of the Teams manifest is not correct. Can you please change it following the guidelines on this article? https://learn.microsoft.com/en-us/sharepoint/dev/spfx/deployment-spfx-teams-solutions
Specifically for this part:
Important
in the Teams app manifest ensure you add the following entry:
JSON
Copy
"webApplicationInfo": {
"resource": "https://{teamSiteDomain}",
"id": "00000003-0000-0ff1-ce00-000000000000"
}
That is required to ensure any API call in the component will succeed from Microsoft Teams rich clients. teamSiteDomain will be the same tenant that the Teams client is using, this will not work cross-tenant/cross-domain so you cannot hardcode another domain in.

@lucabandMSFT - This is the webapplicationinfo being used. I have used contoso.sharepoint.com as an example for posting this issue. In reality, I am using my teamSiteDomain for my tenant.
"webApplicationInfo": { "id": "00000003-0000-0ff1-ce00-000000000000", "resource": "https://contoso.sharepoint.com" } }

@wizneeraj , thanks.
I want to be sure tho: you don't have to use your team site domain, but instead, you have to literarily use the world "{teamsitedomain}" including the "{" brackets inside the manifest.
Is that what you are doing?
Thx,
Luca


Error Generating python client

I'm trying to generate a client (from the VsCode extension), and I'm getting:
error generating the client: One or more errors occurred. (One or more errors occurred. (Specified argument was out of the range of valid values. (Parameter 'properties')))
Here is the output from the log:
The TL;DR seems to be:
Error: Unable to find method 'Info/2' on {no object} for the following reasons: kiota.Rpc.Server.Info() parameter(s) (excluding any CancellationToken): 0 - 0, but the request supplies 2
Users\UUUU\source\repos\XXXX\extensions\MYAPI\Willow.AzureDigitalTwins.Api\swagger.json"'
    at c:\Users\UUUU\.vscode\extensions\ms-graph.kiota-1.5.999999999\dist\extension.js:1:151821
    at ne (c:\Users\UUUU\.vscode\extensions\ms-graph.kiota-1.5.999999999\dist\extension.js:1:152115)
    at c:\Users\UUUU\.vscode\extensions\ms-graph.kiota-1.5.999999999\dist\extension.js:1:146899
    at Immediate.<anonymous> (c:\Users\UUUU\.vscode\extensions\ms-graph.kiota-1.5.999999999\dist\extension.js:1:146919)
    at processImmediate (node:internal/timers:466:21)
2023-08-08 13:00:27.338 [error] [Extension Host] Error: Unable to find method 'Info/2' on {no object} for the following reasons: kiota.Rpc.Server.Info() parameter(s) (excluding any CancellationToken): 0 - 0, but the request supplies 2
    at c:\Users\UUUU\.vscode\extensions\ms-graph.kiota-1.5.999999999\dist\extension.js:1:151821
    at ne (c:\Users\UUUU\.vscode\extensions\ms-graph.kiota-1.5.999999999\dist\extension.js:1:152115)
    at c:\Users\UUUU\.vscode\extensions\ms-graph.kiota-1.5.999999999\dist\extension.js:1:146899
    at Immediate.<anonymous> (c:\Users\UUUU\.vscode\extensions\ms-graph.kiota-1.5.999999999\dist\extension.js:1:146919)
    at processImmediate (node:internal/timers:466:21)

I'm not even sure which endpoint it was trying to generate at the time, but I guess I can try and bisect that.

Hi @thelazydogsback,
Thanks for trying kiota and for reporting this.
Could you please:

Make sure you're using the latest version of kiota (1.5.1) and retry if it wasn't the case?
Share the OpenAPI description you're trying to generate a client for
Share which language you're trying to generate a client for
Try to isolate and share the faulty endpoint.

Thanks!

Make sure you're using the latest version of kiota (1.5.1) and retry if it wasn't the case?
According to the VSCode plugin: Microsoft Kiota: Last updated 2023-8-8, 12:49:24

Share the OpenAPI description you're trying to generate a client for
Sorry, can't do that.

Share which language you're trying to generate a client for
Per issue title, the client language is Python.

Try to isolate and share the faulty endpoint.
It's a pretty big surface, but I'll try

Thanks for sharing the details.
You might want to try version 1.5.199999999 (we've had an issue with our versioning scheme which will be fixed on the next minor version)


Errors in doc?

Hi
I believe there are some errors in the document under "Transfer an enterprise account to a new enrollment". In the Prerequisite section, The following are referring to Enrollment Transfers not Account Transfers:
The account transfer transfers all services, subscriptions, accounts, departments, and the entire enrollment structure, including all EA department administrators.
The account transfer sets the source enrollment status to Transferred. The transferred account is available for historic usage reporting purposes only.
You can't add roles or subscriptions to an enrollment with transferred status. The status prevents additional usage against the enrollment.
Any remaining monetary commitment balance in the source agreement is lost, including future terms.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 97154f08-4e08-e3b9-bd7f-b399aeb763ef
Version Independent ID: 56c611c8-ce10-caa0-f48c-41237c5a8151
Content: Azure EA portal administration
Content Source: articles/billing/billing-ea-portal-administration.md
Service: billing
GitHub Login: @bandersmsft
Microsoft Alias: banders

@nroberts16 Thanks for the feedback. We are investigating into the issue and will update you shortly.

@bandersmsft To review the documentation and update as required.

@nroberts16 Thanks for the feedback. I'm investigating this with the EA Portal enginnering team. I'll reply here when I have more info.
#in-process

@nroberts16 Yes, you pointed out a few errors. We're in the process of updating the article for accurracy. Again, thanks for this catch! The article will get updated shortly.
#please-close

@nroberts16 The updated article will get refreshed live tomorrow morning.

Awesome thanks Bill. FYI I'm actually an MS FTE :)
On Mon, Oct 7, 2019 at 7:49 PM Bill Anderson<EMAIL_ADDRESS>wrote:

@nroberts16 https://github.com/nroberts16 The updated article will get
refreshed live tomorrow morning.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/azure-docs/issues/40192?email_source=notifications&email_token=AE6I4RQ3YUJO6YSZXG4BVLLQNPDI7A5CNFSM4I54FWHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEASFLYQ#issuecomment-539252194,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE6I4RSP2FSXKWO33H7INDLQNPDI7ANCNFSM4I54FWHA
.


add pytorch transformer embedding operator

add embedding output in vit model
add pytorch_transformer_embedding_operator.py
add test_pytroch_transformer_embedding_operator.py

Codecov Report

Merging #142 (54fd368) into main (bd2a34b) will increase coverage by 0.24%.
The diff coverage is 95.23%.

@@            Coverage Diff             @@
##             main     #142      +/-   ##
==========================================
+ Coverage   77.08%   77.32%   +0.24%
==========================================
  Files          85       87       +2
  Lines        3125     3167      +42
  Branches      321      323       +2
==========================================
+ Hits         2409     2449      +40
- Misses        591      592       +1
- Partials      125      126       +1

Impacted Files
Coverage Δ

...operators/test_pytorch_transformer_vec_operator.py
91.30% <91.30%> (ø)

towhee/tests/mock_operators/__init__.py
82.35% <100.00%> (+1.10%)
:arrow_up:

...r_vec_operator/pytorch_transformer_vec_operator.py
100.00% <100.00%> (ø)

towhee/trainer/models/vit/vit.py
75.00% <100.00%> (+1.08%)
:arrow_up:

Continue to review full report at Codecov.

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


Click events from Overlay

I created a simple popup (using ol.Overlay), that displays a box above the selected feature with additional information. There is also a button, to which I assign ClickHandler, but it never gets called. I tried setting setStopEvent to false on OverlayOptions, but that just makes the map receive some event, but it never gets to my click handler.
I can see that my SelectFeature is receiving this click (even though it is a click on a button in an overlay, so no select at all), but the handler I add to the button by btn.addClickHandler(event -> doSomeStuff()) is not called.
I can see that other people have this issue, so it is not probably an issue with this wrapper, but with OL in general, but just how to register my button so that it will react to click?

I tried your example with and without "setStopEvent" set on my overlay. If false, nothing gets called. With it set to true, SelectFeature gets this click, but again not this EventListener. Can't it be because when I set an Element to an overlay, it gets all its browser events removed?

@ezpzlmnsqz1337 setStopEvent isn't relevant for this listener. I added a temporary branch overlay_click with an modified working example. See commit https://github.com/TDesjardins/gwt-ol3/commit/49e6fff9b427ad3695bc9cc919237ab9a4509980 .
Could you check if it works for you?

Thanks you! It was the Event.sinkEvents that I was missing :) Sorry, not experienced with it, never used it before. From the name of the method I would expect that it 'sinks' them, like "put them down" or "remove" :D Now it works fine, just this one line of code was missing. Thanks.

So I think this can be closed. Please reopen if necessary. I will remove the temporary branch.


Improves error handling

Description
This PR attempts to improve the error handling of the exporter. It does so by batching the records - partially pre-serializing them to reduce the cost of retries - and on error will retry them instead of closing the exporter.
How it works
The general idea is similar to how it previously was. There is now a RecordBatch which has a configurable maximum size (in bytes). That size is a soft upper limit; in order to handle large records which wouldn't fit in a batch by themselves, it's necessary to accept the batch be potentially bigger than the given maximum size. Furthermore, when calculating the size of a record before batching it, we only compute an estimated size, as there is some overhead that Kafka will add when producing the record. As such, it really is a soft upper bound, so users should configure it conservatively and expect it that it may be greater.
When a record is given to the exporter via Exporter#export(Record), there are two cases:

The batch is full; in this case, the exporter will block up to a configurable time out and wait for some space to be made. This will happen if at least one record is acknowledged by the Kafka endpoint, at which point it can be safely removed from the batch.
The batch is not full; in this case, the record is partially serialized, sent to Kafka (via Producer#send(ProducerRecord)), and added to the batch.

As before, there is also a scheduled task (with a configurable interval) which will regularly check if any record in the batch have been completed; if they have been, it will update the exporter position and will remove the record from the batch, making space for new records.
If at any point a record fails to be sent to Kafka, the following logic kicks in:

If the request was cancelled, this means the exporter explicitly cancelled it (either directly or via Producer#close). At this point, it's safe to ignore, as retrying the record is handled wherever we've explicitly cancelled the request (or closed the producer). One exception is when the exporter is closing; there we cancel all requests, but obviously will not retry them.
If the thread timed out waiting for the request to complete, an exception is thrown. This is because of how exporters are run in Zeebe; by throwing an exception which bubbles up to the Zeebe ExporterDirector, we ensure that we will retry the current operation, but we also will yield control of the current thread for a little bit, letting other tasks be executed.
If the thread was interrupted, as we never explicitly interrupt it ourselves, it means the exporter is probably shutting down, at which point there's nothing to do (in the exporter anyway).
If an ExecutionException was thrown, this could mean a number of thing, and this is where things get interesting. According to the Kafka documentation (see Callback), there's only a subset of recoverable exceptions where it makes sense to retry the same request. For most of these, as the exporter uses an idempotent producer, we should never actually see them here - this is because an idempotent will retry records "forever" (relatively speaking) for these recoverable exceptions. In the case of non-recoverable exceptions, the producer is closed and recreated. In the case of both recoverable and non-recoverable exceptions, all records - starting at the failed record - are cancelled, and retried. This means that even though we use an idempotent producer, the semantics go back to at least once - this is because idempotency in Kafka is per producer session, not overall. So you may see the same records twice; this is also in line with Zeebe which also follows a at least once model. However, if the producer sent 1, 2, 3, 4, and failed at 2, you will again get 2, 3, 4 - the ordering is still relatively consistent in this way.

Related issues
Closes #28

Are there plans to merge this soon ?

Sorry, I'm on holidays again 😅 This is primarily missing automated tests; so far I mostly manually tested it. I will continue when I'm back.

No worries, enjoy your break.


Delta full line background not working in preview window

Checklist

[X] I have read through the manual page (man fzf)
[X] I have searched through the existing issues
[X] For bug reports, I have checked if the bug is reproducible in the latest version of fzf

Output of fzf --version
0.55.0 (fc693080)
OS

[X] Linux
[ ] macOS
[ ] Windows
[ ] Etc.

Shell

[X] bash
[ ] zsh
[ ] fish

Problem / Steps to reproduce
When using delta for preview, the background color only shows behind the text instead of on the whole line.
normal delta output:

fzf preview:

It's related to the ANSI code \x1b[0K used by delta for the line background. There is this old issue #2249 when support for it was implemented, and that version works correctly, but the latest master does not. Git bisect shows that this commit is reintroducing the issue: 3c34dd82750ca61a1ee7f329ed47fe01e6d1ee30.
It only happens when there are no characters after \x1b[0K and before the end of the line:

but if you add a single space before the end of the line it works:

Thanks, a24eb9967919c75bf19406c390ec0ae62f0ddb18 should fix the problem.

Thanks for the quick fix! It's working now.


method overloading for classes/interfaces marked 'native("jvm")'

The Ceylon typechecker and Java backend have supported method overloading for rather a long time, since Ceylon code needs to be able to:

call overloaded Java methods, and
implement Java types with overloaded methods.

However, the typechecker rejects code with overloaded methods, except when overriding a Java method.
We've very often discussed relaxing this restriction in some sort of limited way, but never came up with anything very satisfying. Objections include:

A natural mapping of overloading to Java means inheriting Java's pretty messed-up rules about what is a legal overload. One could come up with a less natural mapping, but it's difficult to come up with one that would result in reasonable semantics for binary compatibility across API changes.
Similarly, it's difficult to map overloading to JavaScript in a way that would result in reasonable semantics for binary compatibility across API changes.

@vietj has been complaining for literally years now that he wants Ceylon to support overloading in order to be able to do API generation in Vert.x. It turns out that in this use-case:

the "natural" mapping is by nature just perfect, and
we don't care about JavaScript.

Finally, it has occurred to me that we could support overloading—with Java's rules about what is a legal overload—just for classes and interfaces marked native("jvm"). This neatly sidesteps the objections above.
This should be rather easy to implement.

Note that this proposal affects the typechecker only, and, AFAIK doesn't require any changes to the backends.

I think it would be nice to have an overload annotation for this, to gently discourage its use and prevent mistakes w/accidental overloading.

I think it would be nice to have an overload annotation for this

I agree it would be nice, but the problem is: where would we put it? I don't think it rightly belongs in ceylon.language.

As it is only for native("jvm") classes, it may belong to ceylon.interop.java (as there is no interop.jvm)

No, I'm trying really hard to get away from the use of that module. It's especially inappropriate for enabling what is essentially a language feature.
If anything, the annotation would make most sense in java.base.

I guess an alternative to overloaded would be suppressWarnings("overloading"). That's an even stronger discouragement.

I've done the hard part of implementing this, the last thing to decide is whether we should stick with using native("jvm") to turn this on, or whether we should add a overloaded annotation to java.lang. Either approach serves the purpose of ensuring that this feature can only be enabled for Java-specific types.

Is there any overlap between this feature and the limited overloading proposal from a while ago?

@fwgreen well the concepts are pretty different. The thing proposed in that older issue is really just a syntax sugar for something you can pretty much already write today. For example:
String fun(String s) => s;
String fun(Integer i, Integer j) => i.string.repeat(j);

would be essentially the same as this:
Callable<String,[String]|[Integer, Integer]> fun
    = flatten(([String]|[Integer, Integer] _)
        => switch (_)
        case ([String s]) s
        case ([Integer i, Integer j]) i.string.repeat(j));

On the other hand, what I've implemented here includes cases that simply can't be mapped to a single Callable in Ceylon's type system, and what you really have is two completely distinct functions with different names, that are disambiguated at compile time by looking at argument types.

So one thing I don't really love about the 'overloaded' annotation is that I have to specify it more than once to declare an overloaded function.

Do you think warnings would get people to reconsider using overloading? Or will people just throw in suppressWarnings in an overly routinely fashion? I think it is perhaps a thing that is better communicated in the Ceylon tour/etc than through a warning..
Nevertheless I think there is value in bringing readers' attention to functions being overloaded, and in this respect I think an overloaded annotation would serve best. After all isn't it so that you can suppress warnings in an outer scope to avoid having to repeat it on every instance? Iff yes then the overloaded methods will not stand out in any way (except perhaps in an IDE which can show fancy icons in the left "lane").

I think there is value in bringing readers' attention to functions being overloaded, and in this respect I think an overloaded annotation would serve best

My thought exactly.
Although I've grown to really dislike overloading, I do acknowledge that it is very nice sometimes when writing code. I think its real harm is when reading, using, and maintaining code. An overload annotation would help, to highlight to readers/consumers that they probably need to review the other functions with the same name to really understand what's going on.
Secondarily, when writing code, requiring each overload to be marked will help avoid accidental overloads, and overload is much easier to type and remember than the suppressed warnings annotation. (And, I think it just makes more sense than a warning.)
Both of these points are more important for Ceylon code, since the Ceylon mindset is that overloading doesn't exist, so when both reading and writing code, you tend to be less aware of the potential for problems relating to overloading.

OK, well fine, that is what I have implemented. Except #7143.

Secondarily, when writing code, requiring each overload to be marked will help avoid accidental overloads

Yeah, upon reflection, I guess that this argument is correct.

@FroMage we should add a couple of simple Java backend tests for this feature.

Done.

Thanks Stef!

I think it would be an intuitive and consisteng solution to follow the ocaml approach
instead of the the java approach
let nameOfFunction = function
| (x: int, y: float) -> "this"
| (x: string, y: char) -> "that"
| _ -> "otherwise";;
and in ceylon:
function nameOfFunction = case (Integer x, Float) "this"
case(String x, Char y) "that"
else "otherwise";

@welopino sure, but that's what's proposed in #3964, which as we've said is a different feature.

It's not a completely different feature when seen in context. See: https://github.com/ceylon/ceylon/issues/7150.

@welopino right, that's just a syntax sugar for something you can already write in Ceylon using the flatten() function, and is essentially what is proposed in #3964.
But again: it's a different feature—it can't handle all the cases that Java-style overloading can handle (at least not without some pretty heavy-duty support for arbitrary type functions). And it would map to something completely different at the bytecode level.
It's a different feature, as I said.


Arguments order of the logging methods

[x] I've read the docs of nestjs-pino
[x] I've read the docs of pino
[x] I couldn't find the same question about nestjs-pino
Question
As described in the NestJS docs, the logging methods receive message as the first argument and the optional additional parameters (e.g . additional logging context) as the rest arguments.
I also understand that Pino uses the reverse order: the logging context (mergingObject) as the first argument and the message as the second one.
Given the fact that this library implements a custom logger for Nest.js, what's the reason for using the order of the arguments from Pino instead of a native order from Nest?
In my practice, it confuses developers who read the Nest docs and/or try to see the logging method signature in Nest's type definition and they often provide the arguments in the native Nest order that gives unexpected results in logs.
Please mention other relevant information such as Node.js version and Operating System.
N/A

and the optional additional parameters (e.g . additional logging context) as the rest arguments

this was in previous major version on nest if I'm not mistaken, but now there is nothing in nest docs about context as additional argument for logging method.

what's the reason for using the order of the arguments from Pino instead of a native order from Nest

could you please provide example for both loggers with more detailed explanation?

@iamolegga sorry for the late response.

this was in previous major version on nest if I'm not mistaken, but now there is nothing in nest docs about context as additional argument for logging method.

You're right.
By saying context I mean not the class name where the logging method was called but some additional logging data such as method arguments, computation result, etc. There's nothing about it in the Nest.js docs.
In Nest.js 8 the default logger logs each of the passed arguments in a separate log record in the order they were given to a logging method.
I was confused because the Nest.js logging examples show the message as the first argument but nestjs-pino follows the arguments' order from Pino and receives a message as the second parameter if we want to provide any mergingObject.
I was expecting that nestjs-pino always receives a message in the first place but now understand that then it wouldn't be possible to distinguish between the merging object and interpolation values that are also supported by Pino but not by Nest.js default logger.
Seems like this issue can be closed.

@okovpashko did you maybe find a way to use the correct interface on the imported Logger class from Nest?
I am getting very confused by using the interface in the wrong way...
Nestjs logger interface:
Logger.log(message: any, context?: string | undefined): void

The only way to make it work correctly is calling it like this:
this.logger.log({ customData: 'test' }, 'real log message');

This is the single way to make the framework work well with pino. And I believe nestjs authors did not accidentally make that message: any in version 8 which adds support for other logger implementations to fit nest logger interface with their own types order
Please check the pino library interpolations, you can do something like info({foo: "bar"}, %s %o, "baz", {qux: 42}). How would you do that in not confusing nest-way? The only way is to accept args the same way as pino does. Any other way of changing args positions would be even more confusing and much more complex internally


Trim shell prefix

Hi, thank you for building and publishing this fascinating cli app.
I had a tiny issue with suggest command. llama puts a shell prefix such as $ or ❯ sometimes, like below.
❯ tlm s 'create secret'
┃ > Thinking... (3.875119084s)
┃ > $ openssl rand -base64 32
┃ > Executing...

bash: $: command not found

It's not very often but it's disrupting the experience since you can't execute the command right after the suggestion when it happens.
I made a small solution simply by trimming the shell prefix if exists. I think it can be more developed like adding below method.
func (s *Suggest) refineCommand(command string) string {
  // refine the generated command, such as trimming shell prefix or removing possible mistakes
}

Because the generated commands are not always perfect, it would be helpful to handle known/possible issues.

Thanks for your kind words and your contribution. Would you be interested in writing a unit test for func (s *Suggest) refineCommand(command string) string as well? This is what I'm gonna do before approving it.

Sure, I just added it. Note that I had to write it in suggest package instead of suggest_test, because the refineCommand method is not exported.

Thank you for your contribution! ❤


PostInstallScript and PostRemoveScript properties not respecting Condition

I noticed that the conditions for scripts are not being respected and are not adding the content. The only way to add data in the scripts is to remove the condition attribute altogether. Also tried to use the Path attribute to add a separate file script as mentioned in this issue but getting error MSB4066: The attribute "Path" in element <PostRemoveScript> is unrecognized.
 <PostRemoveScript Condition="$(InstallService.Equals('true', StringComparison.OrdinalIgnoreCase))">systemctl daemon-reload;</PostRemoveScript>

Also tried only with PostInstallScript  and PostRemoveScript so I don't know if this is affecting pre scripts as well.

There is a substitute for the not working path attribute at the script tag.
To read files you can use $([System.IO.File]::ReadAllText($path"))
Example:
<PreInstallScript>$([System.IO.File]::ReadAllText("preinst"))</PreInstallScript> <PostInstallScript>$([System.IO.File]::ReadAllText("postinst"))</PostInstallScript> <PreRemoveScript>$([System.IO.File]::ReadAllText("prerm"))</PreRemoveScript> <PostRemoveScript>$([System.IO.File]::ReadAllText("postrm"))</PostRemoveScript>


Handling missing scan segments in HST data

I took some time today to work out how to properly NaN pad all the relevant arrays in order to resolve #649. I've tested it on the same dataset as @jbrande was using before and find that the code now works well for me - please test it too Yoni.
While testing everything out, I found an unrelated issue with Fig 3308 for WFC3 spatial scanning data; since this figure is made before the 2D drift correction, the figure ends up look pretty awful. This might also end up affecting the optimal spectral extraction if meddata was used, but I'm not totally sure. I tried messing around with things to fix that issue as well, but nothing obvious that I tried worked. I tried running optspex.clean_median_flux after inst.correct_drift2D for WFC3 data, and the Fig 3308 figure looked differently bad, but still bad.

I'll wait to merge this until I get Yoni's review which he said should be done sometime today


Redirect to home page if /search2 is missing term= query param

This commit ports over the current behavior of /search without a q= query param.
ticket: https://artsyproduct.atlassian.net/browse/DISCO-894 :lock:

Warnings

:warning:
The staging version of Metaphysics has breaking changes, this might not affect your build, but could mean your queries don't work the way you expect. See below for breaking changes:

:warning: Field 'AnalyticsPartnerStatsType.artworksPublished' changed type from '[AnalyticsArtworksPublishedTimeSeriesStats!]' to 'AnalyticsArtworksPublishedStats'
:warning: Argument 'period: AnalyticsQueryPeriodEnum!' added to field 'AnalyticsPartnerStatsType.artworksPublished'
:warning: Argument 'period: AnalyticsQueryPeriodEnum!' added to field 'AnalyticsPartnerStatsType.uniqueVisitors'
:warning: Field 'partnerId' was removed from object type 'AnalyticsArtworksPublishedTimeSeriesStats'
:warning: Field 'partnerId' was removed from object type 'AnalyticsPartnerTimeSeriesStatsType'

  Generated by :no_entry_sign: dangerJS against c072fa58bbcd8c580b148abd710045a0a6c0415f


Sam at luther/add private optimization

This PR uses functionality provided by https://github.com/luthersystems/substrate/pull/4


Default for TLS_PEER_VERIFY socket option are set to required, may lead to confusion when running samples against self-signed certs

Describe the bug
samples/sockets/big_http_download
To Reproduce
Steps to reproduce the behavior:

cd samples/sockets/big_http_download
mkdir build  && cd build
cmake -DBOARD=qemu_x86 -DOVERLAY_CONFIG=overlay-tls.conf ..
make run

Expected behavior
HTTPS request made to https://www.7-zip.org/a/7z1805.exe and file is fetched
Impact
We have no verified cases that TLS works
Screenshots or console output
SeaBIOS (version rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org)
Booting from ROM..***** Booting Zephyr OS v1.14.0-rc1-1247-gb3eb510f5c3a *****
[00:00:00.010,000]  net_ctx.net_context_bind: (0x004106c0): Context 0x0040f620 binding to UDP <IP_ADDRESS>:59111 i0
[00:00:00.070,000]  net_sock_tls: No entropy device on the system, TLS communication may be insecure!
[00:00:00.080,000]  net_config: Initializing network
[00:00:00.080,000]  net_config: IPv4 address: <IP_ADDRESS>
[00:00:00.080,000]  net_config: Running dhcpv4 client...
Preparing HTTP GET request for https://www.7-zip.org:443/a/7z1805.exe
addrinfo @0x424008: ai_family=1, ai_socktype=1, ai_protocol=6, sa_family=1, sin_port=bb01
sock = 0
[00:00:03.130,000]  net_sock_addr.dns_resolve_cb: (0x0040fc98): dns status: -100
[00:00:03.130,000]  net_sock_addr.dns_resolve_cb: (0x0040fc98): dns status: -103
[00:00:03.130,000]  net_sock_tls.tls_alloc: (0x004106c0): Allocated TLS context, 0x00400580
[00:00:03.130,000]  net_ctx.net_context_bind: (0x004106c0): Context 0x0040f6c0 binding to TCP <IP_ADDRESS>:52357 i0
Environment (please complete the following information):
Linux
0.10.0 SDK
Additional info
The problem is consistent independently of the URL. Regular fetching of the URL works.
The problem does not seem to be related to the server certificate as the symptoms are identical for self-signed and proper certificates.

Assigning a bug to many persons does not usually work as expected as then it is not really known who will look at it. As this looks like a socket TLS issue and @rlubos is the main expert there, I am reassigning this to him atm.

I actually tried this too in qemu_x86 with local https server (using overlay-tls.conf and overlay-e1000.conf), the log looks like this:
[00:00:00.010,000] <wrn> net_sock_tls: No entropy device on the system, TLS communication may be inse!
[00:00:00.010,000] <inf> net_config: Initializing network
[00:00:00.010,000] <inf> net_config: IPv4 address: <IP_ADDRESS>
[00:00:00.010,000] <inf> net_config: Running dhcpv4 client...
Preparing HTTP GET request for https://<IP_ADDRESS>:4443/foobar
addrinfo @0x426008: ai_family=1, ai_socktype=1, ai_protocol=6, sa_family=1, sin_port=5b11
sock = 0
[00:00:03.030,000] <dbg> net_sock_addr.dns_resolve_cb: (0x00410780): dns status: -100
[00:00:03.030,000] <dbg> net_sock_addr.dns_resolve_cb: (0x00410780): dns status: -103
[00:00:03.040,000] <dbg> net_sock_tls.tls_alloc: (0x00410780): Allocated TLS context, 0x00400580
Error: connect(sock, ai->ai_addr, ai->ai_addrlen)
exit

@rlubos if you think this is not TLS related, please feel to reassing to me for example.
The connectivity works ok without https.

Thanks, I'll try to reproduce/debug.

Hmm tried to reproduce, but the sample works out of the box for me :|
SeaBIOS (version rel-1.11.2-0-gf9626ccb91-prebuilt.qemu-project.org)
Booting from ROM..***** Booting Zephyr OS v1.14.0-rc1-1276-g932a33ad7502 *****
[00:00:00.060,000] <wrn> net_sock_tls: No entropy device on the system, TLS communication may be insecure!
[00:00:00.060,000] <inf> net_config: Initializing network
[00:00:00.060,000] <inf> net_config: IPv4 address: <IP_ADDRESS>
[00:00:00.060,000] <inf> net_config: Running dhcpv4 client...
Preparing HTTP GET request for https://www.7-zip.org:443/a/7z1805.exe
addrinfo @0x424008: ai_family=1, ai_socktype=1, ai_protocol=6, sa_family=1, sin_port=bb01
sock = 0
1181017 bytes
Hash: 647a9a621162cd7a5008934a08e23ff7c1135d6f1261689fd954aa17d50f9729
Total downloaded so far: 1MB
sock = 0
294657 bytes

As you see the sample did connect and downloaded the file, next download is in progress... Perhaps some wireshark pcap or mbedTLS logs could be helpful to identify whether it's a problem with TLS handshake.

Confirming @rlubos's results with f4c8e3ff3197d36773d68b4b4802daabc401f918 and build completely OOB (the original report contains changes at least to logging config):
SeaBIOS (version rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org)
Booting from ROM..***** Booting Zephyr OS v1.14.0-rc1-1277-gf4c8e3ff3197 *****
[00:00:00.170,000] <err> slip: [0x00400b00] cannot allocate pkt
--- 87 messages dropped ---
[00:00:00.170,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.170,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.170,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.170,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.170,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.170,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.170,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.170,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.170,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.170,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.180,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.180,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.180,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.180,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.180,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.180,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.180,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.180,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.180,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.180,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.180,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.190,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.190,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.190,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.190,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.200,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.200,000] <err> slip: [0x00400b00] cannot allocate pkt
[00:00:00.220,000] <wrn> net_sock_tls: No entropy device on the system, TLS communication may be insecure!
[00:00:00.220,000] <inf> net_config: Initializing network
[00:00:00.220,000] <inf> net_config: IPv4 address: <IP_ADDRESS>
[00:00:00.220,000] <inf> net_config: Running dhcpv4 client...
Preparing HTTP GET request for https://www.7-zip.org:443/a/7z1805.exe
addrinfo @0x424008: ai_family=1, ai_socktype=1, ai_protocol=6, sa_family=1, sin_port=bb01
sock = 0
1181017 bytes
Hash: 647a9a621162cd7a5008934a08e23ff7c1135d6f1261689fd954aa17d50f9729
Total downloaded so far: 1MB
sock = 0
114433 bytes

("slip: [0x00400b00] cannot allocate pkt" eyecandy is from https://github.com/zephyrproject-rtos/zephyr/issues/13991).

Okay. Turns out that the tests were failing in our environment because self-signed certs are not accepted by default.   The following code snippet enabled the test (big_http_download.c:163):
#if defined(CONFIG_NET_TLS_PEER_NOVERIFY)
/* Allowing self-signed certificate, for testing with local httpd /
{
int peer_verify = 0 ;
CHECK(setsockopt(sock, SOL_TLS, TLS_PEER_VERIFY,
&peer_verify, sizeof(peer_verify)));
}
#endif / CONFIG_NET_TLS_PEER_NOVERIFY */

So, the best option going forward would be to enable the option to allow self-signed certificates (with appropriate disclaimers of course) for development time. But everything works now.
Hence, downgrading the priority and changing type from bug to enhancement.

So, the best option going forward would be to enable the option to allow self-signed certificates (with appropriate disclaimers of course) for development time.

I'd be +1 for enabled this option for this sample (big_http_download) with appropriate notice to README. Doubt we would enable it in Zephyr config by default, guys like @d3zd3z actually call for more stringent default setup of security-related things, not less than what we have now. But I found the "for development time" phrase resounding with what I have in mind - I wonder if we could/would/should have different Kconfig defaults for official releases vs just git master. That would be chory/cumbersome and likely confusing, so would need good discussion and consideration.

@rlubos, so you may want to check re: error reporting in such cases (I would say that's the only thing which can be distilled from this report in the meantime, unfortunately, it's not clear if that's the issue or not, as now the ticket title, description, and console dump don't correspond to each other).

TLS_PEER_VERIFY was added mostly to make developers life easier, not having to be concerned about certificate contents during development. I guess we could go a step further, and configure the default behavior thorough Kconfig, but we should at least pritnt out the warning in case the 'unsafe' default behavior is enabled (just as we do when no good entropy source is present in the system).
As for the error reporting - we alredy print the error code that mbedTLS produce in case of handshake failue (at socket log level) - what more could we make? Limited errno space is not helpinig here either.
@jukkar I'm trying to understand what exactly is wrong with the self-signed certificate that you use. We are actively using certificates available in net-tools repository, aren't they self-signed as well?
What comes to my mind is that it is very likely that we have a hostname mismatch here. The certificate should have assigned a hostname (called Common Name, CA), and we enforce it's verification in TLS sockets, see TLS_HOSTNAME option. If the name we provide does not match the name configured in the certificate, the handshake will fail. Not sure though how would mbedTLS behave in case there is no CA bound to the certificate.
The hostname check can be disabled by providing NULL for TLS_HOSTNAME option.

As for the error reporting - we alredy print the error code that mbedTLS produce in case of handshake failue (at socket log level)

Which level exactly?

what more could we make?

Well, as this report is against big_http_download, then to make sure it prints an error (using printf). @laperie logdump shows as if it hanged. (But then it also shows https://www.7-zip.org/a/7z1805.exe, while it turns out the report is actually about accessing something different with self-signed cert, as apparently https://www.7-zip.org doesn't have self-signed cert).
So, all in all, I just suggest that the behavior of big_http_download is checked when run against URL which doesn't have a proper cert, to make sure that this behavior isn't too confusing (i.e. it either works, or error is printed, extra points for clear enough error).

Which level exactly?

https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/net/lib/sockets/sockets_tls.c#L12
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/net/lib/sockets/sockets_tls.c#L801


feat(TransactionQuery): Add transaction reference input as query argument

Project: https://github.com/opencollective/opencollective/issues/7343
For https://github.com/opencollective/opencollective/issues/7396 to enable using the legacyId as the primary identifier in the drawer (and in the query)

#10087  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @gustavlrsn and the rest of your teammates on  Graphite

Already synced with @kewitz on Slack; just noting for future posterity this is implementing the pattern used by ExpenseQuery, OrderQuery, UpdateQuery and others, where an input reference type is used to hold the arguments.


Unwanted auto direct scroll to top on mobile

Hello,
First thanks for this great plugin ! I've been using it on several project now !
Unfortunatly, on my last project, I found a very unconfortable bug wich happens only on mobiles :
When I load the page, if I make a quick scroll down (by touching the screen), it directly reset the scroll (without smooth scrolling or something), and I'm back at the top of page.
Here is the link : www.chuuut-annecy.com
Thank you for your help,
Thomas

Hi Thomas,
I am mobile challenged and will not be of much help with a mobile issue. Maybe I can try a simulator when I get a chance to see if I can reproduce your results.
Sorry and best of luck!
Sincerely,
Joe


Change desktop packaging script to run merge_libraries in parallel.

By far the slowest part of C++ desktop packaging is running merge_libraries, especially on Windows. This PR allows the merge_libraries step -- which uses Linux runners to merge Windows libraries - to run in parallel as long as the "parallel" command is installed on the machine.
To enable this change, a bit of code is added to merge_libraries.py to lock and unlock the cache file (which is used across merge_libraries instances) using flock(). It requests a shared lock while reading, and an exclusive lock while writing. The flock() call will block until the process can obtain the lock.
This change saves nearly an hour in packaging time for the longest packaging platform, Windows Debug X64 Static (and Dynamic).

Added an optimization to run the longest job first (after the initial cache population), basically to give Firestore the maximum amount of time to do its packaging while the other jobs run.


⚠ Feedaty widget has degraded performance

In 749fa9e, Feedaty widget (https://widget.feedaty.com/public/js/feedaty.js?merchant=10213975&style_ver=2021&data-sku=36263) experienced degraded performance:

HTTP code: 200
Response time: 8743 ms

Resolved: Feedaty widget performance has improved in 0438b27 after 10 minutes.


exporting ClientInfo functions for better reusability

Codecov Report

Merging #5152 (4d3193f) into dev (e2e8e8c) will not change coverage.
The diff coverage is 100.00%.

Flag
Coverage Δ

*Carryforward flag

msal-angular
96.50% <ø> (ø)

Carriedforward from e2e8e8c

msal-browser
86.69% <ø> (ø)

msal-common
85.79% <100.00%> (ø)

Carriedforward from e2e8e8c

msal-core
82.84% <ø> (ø)

Carriedforward from e2e8e8c

msal-node
82.99% <ø> (ø)

Carriedforward from e2e8e8c

msal-node-extensions
76.03% <ø> (ø)

Carriedforward from e2e8e8c

msal-react
94.50% <ø> (ø)

Carriedforward from e2e8e8c

node-token-validation
88.88% <ø> (ø)

Carriedforward from e2e8e8c

*This pull request uses carry forward flags. Click here to find out more.

Impacted Files
Coverage Δ

...e-extensions/src/persistence/PersistenceCreator.ts
91.17% <ø> (ø)

lib/msal-common/src/index.ts
100.00% <ø> (ø)

lib/msal-common/src/account/ClientInfo.ts
100.00% <100.00%> (ø)

lib/msal-common/src/utils/Constants.ts
100.00% <100.00%> (ø)


xScheduledTask: Move strings to localization file and HQRM - fixes #125

Pull Request (PR) description
Convert xScheduledTask to HQRM and move strings to Localization File. Also correct message produced when existing scheduled task trigger type is not recognized.
This Pull Request (PR) fixes the following issues:

Fixes #125
Fixes #121

Task list:

[x] Change details added to Unreleased section of CHANGELOG.md?
[x] Added/updated documentation, comment-based help and descriptions in .schema.mof files where appropriate?
[x] Examples appropriately updated?
[x] New/changed code adheres to Style Guidelines?
[x] Unit and (optional) Integration tests created/updated where possible?

@johlju - this is the last HQRM change required to this module. Would you mind reviewing if you get a chance? I can then get onto the rename and starting work on adding features again.

This change is

Reviewed 3 of 3 files at r1.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

DSCResources/MSFT_xScheduledTask/en-US/MSFT_xScheduledTask.strings.psd1, line 9 at r1 (raw file):

0

Minor, no-blocking: Maybe change to '...zero (0)...'? This and the one below.

Comments from Reviewable

All done - could you sign off for me? :grin: Thanks again @johlju!

Review status: 2 of 3 files reviewed at latest revision, 1 unresolved discussion.

DSCResources/MSFT_xScheduledTask/en-US/MSFT_xScheduledTask.strings.psd1, line 9 at r1 (raw file):
Previously, johlju (Johan Ljunggren) wrote…

0

Minor, no-blocking: Maybe change to '...zero (0)...'? This and the one below.

Done.

Comments from Reviewable

Reviewed 1 of 1 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Thanks again @johlju


kustomize resource "grafana-rawDashboardDefinitions.yaml" missing on master

To reproduce:
ref="master"
kustomize build "github.com/coreos/kube-prometheus?ref=${ref}"

error:
Error: accumulating resources: accumulating resources from './manifests/grafana-rawDashboardDefinitions.yaml': evalsymlink failure on '/private/var/folders/w4/c24yvdzn7qb7lfbn03mwnx8nhjh8lv/T/kustomize-666221288/manifests/grafana-rawDashboardDefinitions.yaml' : lstat /private/var/folders/w4/c24yvdzn7qb7lfbn03mwnx8nhjh8lv/T/kustomize-666221288/manifests/grafana-rawDashboardDefinitions.yaml: no such file or directory

It worked previous to https://github.com/coreos/kube-prometheus/commit/e7c3ca314da6823fb6cdcb666403c05bb76dbe55 where grafana-rawDashboardDefinitions.yaml was added to kustomization.yaml

This file is only potentially there if you build the stack using jsonnet. I think this shouldn't be in the kustomize file. Could you remove it?

Closing due to staleness. Please reopen if you think this is still relevant.


lice: 0.4 -> 0.6

Credits to @mat8913 (https://github.com/NixOS/nixpkgs/issues/75521#issuecomment-566013855).
Motivation for this change
lice 0.4 is old and in nixpkgs broken: fixes #75521
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after) +3.6 MB
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 112895 at 9bc90032 run on x86_64-linux 1

1 package built:

lice

2 suggestions:

warning: no-uri-literals
URI literals are deprecated.
Near pkgs/tools/misc/lice/default.nix:25:16:
   |
25 |     homepage = https://github.com/licenses/lice;
   |                ^

warning: python-explicit-check-phase
Consider using pytestCheckHook in checkInputs rather than checkPhase = "pytest";.
Near pkgs/tools/misc/lice/default.nix:21:3:
   |
21 |   checkPhase = "pytest";
   |   ^

Result of nixpkgs-review pr 112895 at 9bc90032 run on aarch64-linux 1

1 package built:

lice

2 suggestions:

warning: no-uri-literals
URI literals are deprecated.
Near pkgs/tools/misc/lice/default.nix:25:16:
   |
25 |     homepage = https://github.com/licenses/lice;
   |                ^

warning: python-explicit-check-phase
Consider using pytestCheckHook in checkInputs rather than checkPhase = "pytest";.
Near pkgs/tools/misc/lice/default.nix:21:3:
   |
21 |   checkPhase = "pytest";
   |   ^


Update TextBoxHelper.cs - Keep Binding

Use the SetCurrentValue method to prevent the binding from being released.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: unjong sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: unjong sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

@unjong your changes have been merged, thanks for your contribution 👍


fix: rimraf path

When generating the 'api-client' package, the rimraf command does not properly delete the files, which could result in models that have been removed from the openapi.json still existing in src/models.

Tested locally and works fine


Vineyard fails when compiling with Arrow 15.0.0

Describe your problem
I released Arrow 15.0.0 a couple of days ago. I am following up distribution of the package and it seems the Homebrew PR is blocked because Vineyard is not compatible with Arrow 15.0.0: https://github.com/Homebrew/homebrew-core/pull/160553#issuecomment-1903649716
  In file included from /tmp/vineyard-20240122-87256-on1dbr/v6d-0.20.2/modules/basic/ds/arrow_shim/concatenate.cc:67:
  /opt/homebrew/include/arrow/visit_type_inline.h:54:34: error: no matching member function for call to 'Visit'
      ARROW_GENERATE_FOR_ALL_TYPES(TYPE_VISIT_INLINE);
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
  /opt/homebrew/include/arrow/visitor_generate.h:43:3: note: expanded from macro 'ARROW_GENERATE_FOR_ALL_TYPES'
    ACTION(StringView);                           \
    ^~~~~~~~~~~~~~~~~~
  /opt/homebrew/include/arrow/visit_type_inline.h:29:21: note: expanded from macro 'TYPE_VISIT_INLINE'
      return visitor->Visit(internal::checked_cast<const TYPE_CLASS##Type&>(type), \
             ~~~~~~~~~^~~~~
  /tmp/vineyard-20240122-87256-on1dbr/v6d-0.20.2/modules/basic/ds/arrow_shim/concatenate.cc:255:19: note: in instantiation of function template specialization 'arrow::VisitTypeInline<vineyard::arrow_shim::(anonymous namespace)::ConcatenateImpl>' requested here
      RETURN_NOT_OK(VisitTypeInline(*out_->type, this));
                    ^
  /tmp/vineyard-20240122-87256-on1dbr/v6d-0.20.2/modules/basic/ds/arrow_shim/concatenate.cc:260:10: note: candidate function not viable: no known conversion from 'const arrow::StringViewType' to 'const NullType' for 1st argument
    Status Visit(const NullType&) { return Status::OK(); }
           ^

I can't give much details apart from adding compatibility with Arrow 15.

Thanks for reporting. Working on it.

Hi @raulcd, I have just uploaded a new release to github: https://github.com/v6d-io/v6d/releases/tag/v0.20.3.
Please bump up the version of vineyard in homebrew. Thanks!

Thank you very much for the prompt response @sighingnow !

Thanks @sighingnow! ❤


[addon] Cloud Commander Port 8000 in-use

Which addon?

Cloud Commander
name: Feature request
about: Suggest an idea for this project
title: 'Allow listening port to be configurable'
labels: ''
assignees: ''

Which addon?

Cloud Commander add-on
Addon or app?

Add-on
Describe the solution you'd like

Allow the port to be configurable. 8000 is a fairly common port that's already in use and not changeable. The add-on will not load unless this container port is available on the host, despite using ingress.
Describe alternatives you've considered

Tried disabling the webui port with the intention of relying solely on ingress, but that made no difference. Also the add-on says it's required. Changed host port to a known available port "9999" but the add-on will still not load because port 8000 is in use.
Additional context

Starting...
/etc/cont-init.d/00-aaa_dockerfile_backup.sh: executing
/etc/cont-init.d/00-banner.sh: executing
hello
curl: (7) Couldn't connect to server
[14:39:18] ERROR: Something went wrong contacting the API
/etc/cont-init.d/92-local_mounts.sh: executing
curl: (7) Couldn't connect to server
[14:39:18] ERROR: Something went wrong contacting the API
/etc/cont-init.d/92-smb_mounts.sh: executing
/etc/cont-init.d/99-run.sh: executing
curl: (7) Couldn't connect to server
[14:39:18] ERROR: Something went wrong contacting the API
[14:39:18] INFO: Starting...
cloudcmd --port: listen EACCES: permission denied <IP_ADDRESS>:8000

Hi, I'm sorry but something is wrong in your system, I two addons exposé their internal ports... What is your system?

Setting a fixed ip in the supervisor could help with some curl issues

Hi, I remember our discussions on qbittorrent! I'll add the apparmor fix let's see if it helps.

That fixed it! Thank you

Great, thanks!


Visual Studio 16.8 dependency rebuild

Error when building T+ with new VS 16.8 Community Edition:
'..TemplePlus\dependencies\lib\python27.lib' was created by a different version of the compiler than other objects like '..\TemplePlus\Release\EASTL.lib'; rebuild all objects and libraries with the same compiler.
@shartte FYI

Please try the new build of dependencies found here:
https://github.com/GrognardsFromHell/Dependencies/releases/tag/v1.7
(And remember to fully clean/rebuild)


Key feature not working

Description
Key features page is not working properly

Steps to Reproduce
i will make it using cards . and it looks  proper.
Expected Behavior
No response
Actual Behavior
No response
Screenshots
No response
Additional Information
No response
What browser are you seeing the problem on?

[ ] Firefox
[X] Chrome
[ ] Safari
[ ] Microsoft Edge

Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I want to work on this issue. (optional)

i want to fix this please assign this to me

this issue has been solved, so we are closing this issue.


Refactor the tests

I wasn't quite happy with our tests so I decided to make a few changes, most centre around refocusing the examples directory on sample code rather than trying to piggy-back on it for end-to-end tests. This comes as a few separate commits which may be easier to review separately.
Here are the changes that have been made and why:
Purpose of examples
The purpose of the examples folder wasn't clear, and we were adding in code specifically used for testing rather than showing users how to use Reliability Kit. I think this was a smell. It also meant we had to explicitly drop our 100% coverage requirement because it's not realistic for an example which includes a lot of boilerplate.
I've deleted the tests in this directory. I'm confident doing this because actually all we were testing was:

The serialize-error and serialize-request packages, which already have good tests and 100% coverage.
Their unit tests are enough

That our mock JSON error render was working, and this isn't something we're shipping or expecting users to add

We can add actual integration tests for each package that needs them, as outline below

Integration tests in packages
I've updated all the package unit tests to be in a test/unit folder rather than just under test. This paves the way for adding integration tests on a per-package basis, which I think we're lacking in a few cases. To illustrate how we can write better integration tests for modules I added a new test for the logging middleware.
This new test is far better than the original Express test, which still mocked @financial-times/n-logger so it could verify that logging was being performed. The new test spins up an Express app in a child process and collects the actual logs which end up in stderr. This means we now have a true end-to-end test which will fail if there's an unexpected API change in n-logger or n-express.

Thanks Andy, I'll attempt to answer these.
On child_process

I've not seen child_process used for an end-to-end test before - is that a Node.js native function?

Yep child_process is built-in to Node.js. Many other modules which run commands from Node.js use this under the hood.

What are the benefits of using this over something like supertest or chai-http (in addition to having one less dependency)? Would the tests you've written even be possible with those packages (they are modifying the child process in a way I have not seen done in tests before)?

I did originally write the test like this, but it made it near-impossible to inspect the console output in a way that didn't involve mocking @financial-times/n-logger. The reason I'm using child_process here is because it means our Express app runs in a completely different Node.js process and we can capture the logs as they reach process.stderr. That's what we're doing in this code here:
child.stderr.on('data', (chunk) => {
    stderr += chunk.toString();
});

This means that the tests are verifying that the logs reach the console (and thus Heroku's log drains), and anything that happens across the stack of dependencies which change the way this works will cause the test to fail. I don't think it'd be possible to ensure this with Supertest or Chai HTTP.
On definitions

I think there are varying definitions of integration and end-to-end tests, with some definitions conflating the two.

Yeah I think this actually maps to my understanding of these terms too, in which case integration might be the wrong name for these tests because it does ensure that things work fully end-to-end with no mocking. I named it integration out of habit because I rarely end up writing end-to-end tests for library code. Are you happy for me to change the path to test/end-to-end?

Are you happy for me to change the path to test/end-to-end?

Yes 😄


[New game]: Piano Tiles

🎮 Game Request
Game logic and basic description
It is a musical game in which quick fingers and musical rhythm is a must! You need to press all of the tiles before they disappear from the screen to make sure that the songs continue to play beautifully with every note hit.
Point down the features
Game points

There will be a timer and the number of tiles hit within that time interval would be displayed as a score.
There would be some beautiful rhythm on every hit.

Select program in which you are contributing
GSSoC23
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Hey @dishamodi0910 !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

Hey @dishamodi0910 we are looking forward to have your contribution 🚀

Hello @dishamodi0910, Time's Uppp!⏰
Sorry for closing your issue!
But it's more than a week since we haven't received anything from your side 😢 .
Come up with new ideas, create a new issue and make sure you finish it within a week! 🔥
All the best! 🚀
Happy Hacking! 💗

Hey @dishamodi0910 ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇


updated to warg 0.7.0

updated Warg to v0.7.0 that enables federation (also supports .well-known config and needed to make somethings async)
made registry in the config optional, where it could use the Warg global config

LGTM, tested locally, working well and the recommendation is working as well!


Feature/template

Template for starting with CoreEx
Things to complete:

[ ] Readme file for the template
[ ] Readme file for Azure DevOps pipelines
[ ] Github actions workflows - most likely to be completed in another PR

@chullybun can you check if template project has been added correctly?

@karpikpl - i built the solution from this branch, deployed all packages locally, installed the dotnet template, then executed to create Foo.Bar, opened the .sln in Visual Studio 2022, and ran the included unit tests all successfully - nice work👍
Pulumi, infra, etc. testing I will get to probably next week - we have Adi looking into that.
Was there anything else you wanted me to validate?

I think that's it.
What wasn't working for me, was the running the template from nugget package due to OS permissions.
I've added a checklist on top on what is still pending.

If there's a risk of code going out of sync. maybe this can be merged and I can add other things as separate PRs?


How do I access version 9 credentials with the new custom App screen on shopify?

Issue summary
We are not ready to update to version 10 as it looks like a lot has changed. How do I create a private app to onboard a new developer on the team so I can do the following:
shop_url =<EMAIL_ADDRESS>ShopifyAPI::Base.site = shop_url
ShopifyAPI::Base.api_version = "2020-04"

Currently on version 9
This is what I see:

But the credentials dont work for the shop_url method
thanks!

Still using 2020-4?


Correctly document ReduceLROnPlateau

📚 Documentation
It seems that torch.optim.lr_scheduler.ReduceLROnPlateau can not be used in configure_optimizers because scheduler.step() does not receive the loss, see #673, #98 and others.
However, it is used as an example: https://pytorch-lightning.readthedocs.io/en/latest/optimizers.html#learning-rate-scheduling
Furthermore, the required parameter optimizer is not passed in the example.

The correct usage can be found in the tests: https://github.com/PyTorchLightning/pytorch-lightning/blob/master/tests/base/mixins.py#L698-L705

ReduceLROnPlateau can be used, please see here:
https://github.com/PyTorchLightning/pytorch-lightning/blob/7857a73710d8e63eded0e3a970a03b14d84e12f5/pytorch_lightning/trainer/training_loop.py#L775-L785
the step function does indeed get conditioned on the value of monitor_val.
However, I do agree that the documentation does not make it clear that each learning rate scheduler should receive its corresponding optimizer as input.

anyone want to submit a PR for doc updates on this?


Normalizing namespace

Getting rid of the _ :)

Sure, I will change it and uodate the PR

@celluj34 there you go, needed to rebase I think that's fine

Thank you very much.
Was removing the dashes of the test method names intended?
My previous test method naming was probably not perfect, but there are naming strategies containing dashes (https://stackoverflow.com/questions/155436/unit-test-naming-best-practices) and Microsoft recommends a naming strategy with dashes, too: https://docs.microsoft.com/en-us/dotnet/core/testing/unit-testing-best-practices
I think, they are harder to read without the dash(es).

Sure @ndsvw I can certainly refactor it! Give me some moment and I will correct it for you.

@ndsvw as you can see first commit changes the namespace while the second just move files around folders, let me know your thoughts

You created the new files but didn't delete the old ones...

Indeed so odd. On my branch local they are not here and even after --force it doesn't update it. Let me check

yeah so only after removing my entire project and cloning again I was able to properly move it.

Looks much better now :)

I merged the pull request.
Thanks, @fraga and @celluj34.

@celluj34 @ndsvw anytime! Thanks to you for the tool!


Add tests

After #20 it might be nice to stand-up some tests with karma-webpack or similar - this will probably help reduce the maintenance overhead and make dealing with PRs a little easier.

#20 is fixed. This is unblocked! :tada:
Once we have tests I’d like to get the old Android tests and some of the other open PRs cleaned up.

Would a PR submitted using mocha be ok?

@dardone any tests are better than no tests!
Ideally I want them to be able to run in browserstack or something similar to verify that we get things like oldish Android working and not regressing
If the nwb tool has opinions I would like to follow those for consistency in insin/* repos, but that isn't a hard rule for now.
Thank you for considering taking in this effort.

Sounds good. We use a combination of nightwatch and mocha on a project I've been working on, so I'll just submit my other PR for this project before you guys require tests!


Create an ODP microsite and wiki using the Docusaurus JavaScript framework

Relates to https://github.com/finos/open-developer-platform/issues/29
Summary
As Docusaurus has become the FINOS reference solution for delivering project microsites, it would be great to have a template structure in https://github.com/finos/open-developer-platform to encourage ODP documentation collaboration.
Acceptance Criteria

[ ] as ODP visitor, I want to access wiki contents via odp.finos.org
[ ] as ODP visitor, I want to propose wiki changes via PRs on https://github.com/finos/open-developer-platform
[ ] as ODP Team member, I want to manage meeting agenda and rosters via PRs on https://github.com/finos/open-developer-platform

Tasks

[x] Build a white label microsite with Docusaurus (for FINOS ODP) on https://github.com/finos/open-developer-platform
[ ] #56 Add ODP branding to ODP white label Docusaurus microsite
[ ] Create microsite for ODP (odp.finos.org)
[ ] Create inline edit links as part of white labeled Docusaurus build
[ ] Migrate content from https://finosfoundation.atlassian.net/wiki/spaces/FDX/overview

Transferred implementing meeting attendance via markdown files on GitHub to #78

Transferred Setup ODP microsite DNS and make ODP Docusaurus live to #79

Transferred Migrate ODP content from FDX section of FINOS confluence wiki to ODP Docusaurus microsite to #80

Tagging @brntbeer as work sponsor

All done except branding and announcement. I'll close this one and mark the branding issue as epic


Fix Sass code style for flashes

Lowercase hex colors
Prefix decimal with a leading 0
Add % to the amount for Sass’s darken function
Added :focus alongside :hover
Removed -webkit-font-smoothing (I feel like this will almost always be set globally; no need to set for every Refills component)

@tysongach I am merging this now but

I'm keeping the ///// for now since they frame the things that come from Bitters. While we try the decoupling out I think it's good to have them there like that.
I'm keeping the -webkit-font-smoothing and this is a tricky one. I agree with you that this should be set globally but I (1) don't want the refills to look worse than they did before and (2) want to be sure people don't see them looking good on the site but then they look bad as they use them. (2) would be the case if the  -webkit-font-smoothing was set globally for the refills site. Any thoughts on this?

This should still get another review. We shoot for two people.
I still think the comments should be removed, but that can happen in another PR/later down the road.
I do strongly disagree with keeping font-smoothing, though. It should be set globally here on the Refills site, if you want it. And if I was adding a component to my app, never would I just want font-smoothing set on one single component and not elsewhere throughout the app. I would have font-smoothing already on for my entire app, or not at all…

@tysongach ok, I'll remove the smoothing. But it is an unfortunate scenario where some people might be like "why does this look bad? I'll post an issue about it..."

But if I add multiple components from Refills to my app, now every individual one would have font-smoothing. I see it as unnecessary repetition. It’s also super common for starter kits, boilerplates and other project kick-offs to already have it enabled on body.

yeah, that makes sense. I'll get rid of it!

Most of this was merged.


Review all the setActive, isActive stuff within the collectors

Check if it is doing anything useful or if it can simply be removed.

All these have been removed by commit<PHONE_NUMBER>589c09e3f619851dbd871465380b6e


Microsoft store version is too old, documentation is incorrect

This is clearly incorrect since we are on Windows Terminal v1.21.2361.0 on Github but on Microsoft Store:

So the documentation is misleading and should be changed.
The preferred method should be either the msixbundle installer or winget.

We've found an issue that causes Windows Terminal to freeze when using an IME on certain versions of Windows. The issue isn't caused by us, and we can't easily fix it on our side either. Because of this we're doing a slower rollout than usual for v1.21 as we're waiting for the bug fix to be released. I'll be closing this issue for now then. Please let me know if you have any other questions!


Retain model outputs during CAM inference

Implements the suggestion in this issue:
https://github.com/jacobgil/pytorch-grad-cam/issues/392
Also added 1-liner to README with example

Merged,
Thank you for the contribution!


Alpine unable to install local .apk file

Install Temurin following Instructions on the website for Alpine Linux.
apk add works fine
/ # apk add temurin-17-jdk
(1/8) Installing java-common (0.5-r0)
(2/8) Installing libffi (3.4.4-r2)
(3/8) Installing p11-kit (0.24.1-r2)
(4/8) Installing libtasn1 (4.19.0-r1)
(5/8) Installing p11-kit-trust (0.24.1-r2)
(6/8) Installing ca-certificates (20230506-r0)
(7/8) Installing java-cacerts (1.0-r1)
(8/8) Installing temurin-17-jdk (17.0.7_p7-r0)
Executing busybox-1.36.1-r0.trigger
Executing java-common-0.5-r0.trigger
Executing ca-certificates-20230506-r0.trigger
OK: 270 MiB in 23 packages

But it doesn't work if I download the .apk file to the local directory and install it
~ # apk fetch temurin-17-jdk
Downloading temurin-17-jdk-17.0.7_p7-r0
~ # ls
temurin-17-jdk-17.0.7_p7-r0.apk
~ # apk add temurin-17-jdk-17.0.7_p7-r0.apk
ERROR: temurin-17-jdk-17.0.7_p7-r0.apk: UNTRUSTED signature

It looks like  the .apk file can't be verified
~ # apk verify temurin-17-jdk-17.0.7_p7-r0.apk
temurin-17-jdk-17.0.7_p7-r0.apk: 0 - UNTRUSTED

From @steelhead31
_It appears all of our Alpine APKs going back several releases are not signed, Im just looking into the code to see if we currently sign it( and it isnt working.. ) or whether we release them unsigned.... this error can be worked around by adding the --allow-untrusted switch (e.g.. apk add ./temurin-17-jdk-17.0.7_p7-r0.apk --allow-untrusted )
I've figured it out, its an alpine oddity, Im fairly certain now our Alpine APKs are being signed, and signatures are verified when installing from the online repo, not when manually installing from an APK..  Im still digging, but this appears to be the case..
local apk's have to be installed with the --allow-untrusted switch
Thats how the packaging test for alpine passes in the Jenkins workflow too, I've unpacked the APK and can verify its signed that way, but having done some digging, I cant find an easy way to do the same on the command line.._
@karianna added: Thanks for checking! Sounds like either Alpine has some sort of a missing feature gap (perhaps there's a check from an online APK repo vs local) or we are missing something else that we weren't aware of.  I'll update the ticket and see if the OP knows anything more


[x264:x86-windows] build failure

Host Environment

OS: Windows 10 2004
Compiler: vs2019 16.6.1

To Reproduce
Steps to reproduce the behavior:
./vcpkg install x264
Failure logs
-- Configuring x86-windows-dbg
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:72 (message):
    Command failed: D:/source/test/vcpkg/downloads/tools/msys2/msys64/usr/bin/bash.exe --noprofile --norc --debug -c " CC='D:/source/test/vcpkg/downloads/tools/msys2/msys64/usr/share/automake-1.16/compile cl.exe -nologo' CXX='D:/source/test/vcpkg/downloads/tools/msys2/msys64/usr/share/automake-1.16/compile cl.exe -nologo' LD='link.exe -verbose' AR='D:/source/test/vcpkg/downloads/tools/msys2/msys64/usr/share/automake-1.16/ar-lib lib.exe -verbose' RANLIB=':' CCAS=':' NM='dumpbin.exe -symbols -headers -all' DLLTOOL='link.exe -verbose -dll' ./../src/14d026c3bd-bca2ebf740/configure --build=x86_64-pc-mingw32 --target=i686-pc-mingw32 --host=i686-pc-mingw32 --enable-strip --disable-lavf --disable-swscale --disable-avs --disable-ffms --disable-gpac --disable-lsmash --disable-asm --enable-debug --disable-silent-rules --verbose --enable-shared --disable-static --prefix=/D/source/test/vcpkg/installed/x86-windows/debug --bindir='${prefix}'/../tools/x264/debug/bin --sbindir='${prefix}'/../tools/x264/debug/sbin --includedir='${prefix}'/../include --datarootdir='${prefix}'/share/x264"
    Working Directory: D:/source/test/vcpkg/buildtrees/x264/x86-windows-dbg
    Error code: 1
    See logs for more information:
      D:\source\test\vcpkg\buildtrees\x264\config-x86-windows-dbg-out.log

Call Stack (most recent call first):
  scripts/cmake/vcpkg_configure_make.cmake:461 (vcpkg_execute_required_process)
  ports/x264/portfile.cmake:15 (vcpkg_configure_make)
  scripts/ports.cmake:76 (include)

config-x86-windows-dbg-out.log

By the way, I notice the error message says it is trying to use D:/source/test/vcpkg/downloads/tools/msys2/msys64/usr/share/automake-1.16
but this folder does not exist.
I've tried manually install automake in mysy2. After installing automake, it gives me another error:
-- Configuring x86-windows-dbg
-- Configuring x86-windows-rel
-- Building x86-windows-dbg
CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:136 (message):
Command failed: D:/source/test/vcpkg/downloads/tools/msys2/msys64/usr/bin/make.exe -j 13 --trace -f Makefile all
Working Directory: D:/source/test/vcpkg/buildtrees/x264/x86-windows-dbg
See logs for more information:
D:\source\test\vcpkg\buildtrees\x264\build-x86-windows-dbg-out.log
D:\source\test\vcpkg\buildtrees\x264\build-x86-windows-dbg-err.log
Call Stack (most recent call first):
scripts/cmake/vcpkg_build_make.cmake:200 (vcpkg_execute_build_process)
scripts/cmake/vcpkg_install_make.cmake:24 (vcpkg_build_make)
ports/x264/portfile.cmake:29 (vcpkg_install_make)
scripts/ports.cmake:76 (include)
Error: Building package x264:x86-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with .\vcpkg update, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
Package: x264:x86-windows
Vcpkg version: 2020.02.04-nohash
build-x86-windows-dbg-err.log
build-x86-windows-dbg-out.log
The .depend file in x86-windows-dbg folder

Confirmed.

After some investigations I've found that the CC env var is now valued as compile cl.exe -no-logo and no more as cl or cl.exe.
This bring a wrong environment detection, and it thinks it is GNU while it should be MS. Even fixing the configure file by hand leads to some LINK 1189 issues which I can't yet figure out why they are showing up.
I'll update this issue as soon as I figure out what's the issue...

I think it's better to summon the author of that change first, as he has done tremendous work improving/correcting make builds, there has to be a reason why call to cl.exe are routed via automake.
@Neumann-A, could you, please, comment on this issue?

improving/correcting make builds, there has to be a reason why call to cl.exe are routed via automake.

If a port is truly using autotools there should not be a problem with routing it through automakes compile cl script which also helps configure do the right thing better.
ffmpeg seems to be a case of custom configure script since I cannot see any configure.ac in the repo which makes things always a bit complicated since the assumption/requirements vary a lot between different custom configure scripts. So it is hard to decide what is required and what not.  x264 and ffmpeg seems to be such cases that require a bit of special attention since they do not follow autotools rules. The regression probably happend when I replaced the custom cl wrapper with the automake compile wrapper. Since it was a script change vcpkg probably did not properly detected the regression.
If only CC and CXX need to be correct this can be done by setting the environment variables in the portfile before calling vcpkg_configure_make. (If _vcpkg_append_to_configure_environment would be working correctly but there is a DEFINED missing in the if statement of that function)

config-x86-windows-...-out.log
Unknown option --build=x86_64-pc-mingw32, ignored
Unknown option --target=i686-pc-mingw32, ignored
Unknown option --disable-silent-rules, ignored
Unknown option --verbose, ignored
Unknown option --disable-static, ignored
Unknown option --sbindir=${prefix}/tools/x264/sbin, ignored
Unknown option --mandir=${prefix}/share/x264, ignored
Unknown option --docdir=${prefix}/share/x264, ignored
Unknown option --datarootdir=${prefix}/share/x264, ignored

...

cl : Command line warning D9024 : unrecognized source file type 'x264dll.o', object file assumed
cl : Command line warning D9025 : overriding '/O1' with '/Od'
cl : Command line warning D9025 : overriding '/MDd' with '/MT'
cl : Command line warning D9002 : ignoring unknown option '-g'
cl : Command line warning D9002 : ignoring unknown option '-m32'
cl : Command line warning D9002 : ignoring unknown option '-std=gnu99'
cl : Command line warning D9002 : ignoring unknown option '-mpreferred-stack-boundary=6'
cl : Command line warning D9002 : ignoring unknown option '-fno-tree-vectorize'
cl : Command line warning D9002 : ignoring unknown option '-fno-zero-initialized-in-bss'
cl : Command line warning D9002 : ignoring unknown option '-MM'
cl : Command line warning D9002 : ignoring unknown option '-g0'
cl : Command line warning D9024 : unrecognized source file type 'example.o', object file assumed
make: *** [Makefile:313: .depend] Error 2

flags gcc ?

improving/correcting make builds, there has to be a reason why call to cl.exe are routed via automake.

If a port is truly using autotools there should not be a problem with routing it through automakes compile cl script which also helps configure do the right thing better.
ffmpeg seems to be a case of custom configure script since I cannot see any configure.ac in the repo which makes things always a bit complicated since the assumption/requirements vary a lot between different custom configure scripts. So it is hard to decide what is required and what not. x264 and ffmpeg seems to be such cases that require a bit of special attention since they do not follow autotools rules. The regression probably happend when I replaced the custom cl wrapper with the automake compile wrapper. Since it was a script change vcpkg probably did not properly detected the regression.
If only CC and CXX need to be correct this can be done by setting the environment variables in the portfile before calling vcpkg_configure_make. (If _vcpkg_append_to_configure_environment would be working correctly but there is a DEFINED missing in the if statement of that function)

So If I understand this correctly, all we need to do is redefine CC and CXX? I'll try that and let you know!

Invoking cvtres.exe:
 /machine:x86
 /verbose
 /out:"C:\Users\ALEXAN~1\AppData\Local\Temp\lnk{66828486-1515-4CEE-AF4E-A35D4B86EDD3}.tmp"
 /readonly
 "x264res.o"
Microsoft (R) Windows Resource To Object Converter Version 14.26.28805.0
Copyright (C) Microsoft Corporation.  All rights reserved.

adding resource. type:VERSION, name:1, language:0x0409, flags:0x30, size:736

x264.o : error LNK2019: unresolved external symbol _CommandLineToArgvW referenced in function _get_argv_utf8

Unused libraries:
  C:\Program Files (x86)\Windows Kits\10\lib\10.0.19041.0\um\x86\shell32.lib

x264.exe : fatal error LNK1120: 1 unresolved externals

Is the error I see in #11836

So how is it going? I still cannot install neither x264:x86-windows nor x264:x64-windows.

I am hitting this as well. Happy to help testing fixes.

waiting for #11550 to be merged before touching #11836 again

--disable-cli

After some investigations I've found that the CC env var is now valued as compile cl.exe -nologo and no more as cl or cl.exe.
This bring a wrong environment detection, and it thinks it is GNU while it should be MS. Even fixing the configure file by hand leads to some LINK 1189 issues which I can't yet figure out why they are showing up.
I'll update this issue as soon as I figure out what's the issue...
//EDIT1: So yes, I do agree the issue is vcpkg_configure_make and it seems the CC change was introduced by this commit 27c6c94
The funny fact although is that this very same commit did also update the x264 portfile, so I wonder if the author managed to build x264 successfully on its own workstation...
Another nasty thing I've found is that the commit forces the automake compile script, although it puts the automake binary behind the AUTOCONFIG flag. This would make any package that is being built via MSYS to basically be broken by default ( unless the flag is defined in the relative portfile )
//EDIT2: So, I found the core issue living in here but I'm not sure which is the correct patch to solve it. Long story short, the main issue is linked between:

CC/CCX default value ( which is cl.exe being called by automake compile script )
x264 -link flag
The automake compile script eating -l parameter out of the -link flag and thinking it needs to link ink.lib

So, to solve it, I patched the CC/CCX flags by removing the ${MSYS_ROOT}/usr/share/automake-1.16/compile path before cl.exe ( which will allow the compile to proceed as always ). Finally I patched the x264 portfile by adding the --disable-cli flag in the vcpkg_configure_make section.
Be aware that the current way CC/CCX flags are being set also trigger a false GNU detection by most of the scripts you build out of make. So I think it's just wise to remove the automake compile script path before cl.exe.
I can submit a PR if you're interested. Just let me know in case.
//EDIT3: It seems this approach works fine when running vcpkg from the Developer Console on VS2019. It does not work on a normal CMD session or on a CI environment ( unless you load the Dev Console session there too )
//EDIT4: Managed to get it fixed for AppVeyor too! Here you can find the project where I have all the patched files accordingly: https://github.com/julianxhokaxhiu/ffmpegCI ( I even bumped both ffmpeg and x264 library branches, so don't mind that part )

got this after the patches:
C:\vcpackage\vcpkg>vcpkg install ffmpeg[ffmpeg,x264]:x64-windows
Computing installation plan...
The following packages will be built and installed:
ffmpeg[avresample,core,ffmpeg,gpl,x264]:x64-windows

x264[core]:x64-windows
Additional packages (*) will be modified to complete this operation.
Detecting compiler hash for triplet x64-windows...
Starting package 1/2: x264:x64-windows
Building package x264[core]:x64-windows...
Could not locate cached archive: C:\Users\samof\AppData\Local\vcpkg\archives\8c\8c69993c6bda1cf9d79b896c35678372ab30c041.zip
-- Using cached C:/vcpackage/vcpkg/downloads/mirror-x264-303c484ec828ed0d8bfe743500e70314d026c3bd.tar.gz
-- Cleaning sources at C:/vcpackage/vcpkg/buildtrees/x264/src/14d026c3bd-bca2ebf740.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source C:/vcpackage/vcpkg/downloads/mirror-x264-303c484ec828ed0d8bfe743500e70314d026c3bd.tar.gz
-- Applying patch uwp-cflags.patch
-- Using source at C:/vcpackage/vcpkg/buildtrees/x264/src/14d026c3bd-bca2ebf740.clean
-- Acquiring MSYS Packages...
-- Acquiring MSYS Packages... OK
-- Configuring x64-windows-dbg
-- Configuring x64-windows-rel
-- Building x64-windows-dbg
-- Building x64-windows-rel
-- Installing x64-windows-dbg
-- Installing x64-windows-rel
-- Fixing pkgconfig
-- Fixing pkgconfig - release
-- Checking file: C:/vcpackage/vcpkg/packages/x264_x64-windows/lib/pkgconfig/x264.pc
-- CHECK_LIB_x264_RELEASE:CHECK_LIB_x264_RELEASE-NOTFOUND
CMake Error at scripts/cmake/vcpkg_fixup_pkgconfig.cmake:239 (message):
Library "x264" was not found! If it is a system library use the
SYSTEM_LIBRARIES parameter for the vcpkg_fixup_pkgconfig call! Otherwise,
correct the *.pc file
Call Stack (most recent call first):
scripts/cmake/vcpkg_fixup_pkgconfig.cmake:316 (vcpkg_fixup_pkgconfig_check_files)
ports/x264/portfile.cmake:31 (vcpkg_fixup_pkgconfig)
scripts/ports.cmake:79 (include)

Error: Building package x264:x64-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with .\vcpkg update, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
Package: x264:x64-windows
Vcpkg version: 2020.06.15-nohash
Additionally, attach any relevant sections from the log files above.

@samofoz I'm currently using this patchset now https://github.com/julianxhokaxhiu/ffmpegCI/tree/master/patch
That post is "more or less" outdated now.

@samofoz I'm currently using this patchset now https://github.com/julianxhokaxhiu/ffmpegCI/tree/master/patch
That post is "more or less" outdated now.

Same problem with these patches:
C:\vcpackage\vcpkg>vcpkg install ffmpeg[ffmpeg,x264]:x64-windows --recurse
Computing installation plan...
The following packages will be rebuilt:
ffmpeg[avresample,core,ffmpeg,gpl,x264]:x64-windows
The following packages will be built and installed:

x264[core]:x64-windows
Additional packages (*) will be modified to complete this operation.
Starting package 1/3: ffmpeg:x64-windows
Removing package ffmpeg:x64-windows...
Removing package ffmpeg:x64-windows... done
Elapsed time for package ffmpeg:x64-windows: 301.3 ms
Detecting compiler hash for triplet x64-windows...
Starting package 2/3: x264:x64-windows
Building package x264[core]:x64-windows...
Could not locate cached archive: C:\Users\samof\AppData\Local\vcpkg\archives\29\29c0006e028bef9d4232f3a7ff8d53b322c542b3.zip
-- Downloading https://github.com/mirror/x264/archive/stable.tar.gz...
-- Extracting source C:/vcpackage/vcpkg/downloads/mirror-x264-stable.tar.gz
-- Applying patch uwp-cflags.patch
-- Using source at C:/vcpackage/vcpkg/buildtrees/x264/src/stable-05ed9f7d66.clean
-- Acquiring MSYS Packages...
-- Acquiring MSYS Packages... OK
-- Configuring x64-windows-dbg
-- Configuring x64-windows-rel
-- Building x64-windows-dbg
-- Building x64-windows-rel
-- Installing x64-windows-dbg
-- Installing x64-windows-rel
-- Fixing pkgconfig
-- Fixing pkgconfig - release
-- Checking file: C:/vcpackage/vcpkg/packages/x264_x64-windows/lib/pkgconfig/x264.pc
-- CHECK_LIB_x264_RELEASE:CHECK_LIB_x264_RELEASE-NOTFOUND
CMake Error at scripts/cmake/vcpkg_fixup_pkgconfig.cmake:239 (message):
Library "x264" was not found! If it is a system library use the
SYSTEM_LIBRARIES parameter for the vcpkg_fixup_pkgconfig call! Otherwise,
correct the *.pc file
Call Stack (most recent call first):
scripts/cmake/vcpkg_fixup_pkgconfig.cmake:316 (vcpkg_fixup_pkgconfig_check_files)
ports/x264/portfile.cmake:31 (vcpkg_fixup_pkgconfig)
scripts/ports.cmake:79 (include)

Error: Building package x264:x64-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with .\vcpkg update, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
Package: x264:x64-windows
Vcpkg version: 2020.06.15-nohash
Additionally, attach any relevant sections from the log files above.

You can't just update the x264 patch, you need also the one in scripts/cmake as the core issue is around how msys builds with make ( long story short, most of the software, including x264 thinks are building on Linux rather than on MINGW ). Update that and you'll get a valid build.

You can't just update the x264 patch, you need also the one in scripts/cmake as the core issue is around how msys builds with make ( long story short, most of the software, including x264 thinks are building on Linux rather than on MINGW ). Update that and you'll get a valid build.

Hi Julian,
I did copy both the patches. Check the logs carefully - the library is being compiled fine but the error seems to be during installation:
Library "x264" was not found! If it is a system library use the
SYSTEM_LIBRARIES parameter for the vcpkg_fixup_pkgconfig call! Otherwise,
correct the *.pc file

Library "x264" was not found! If it is a system library use the
SYSTEM_LIBRARIES parameter for the vcpkg_fixup_pkgconfig call! Otherwise,
correct the *.pc file

I see, I'm personally building using x86-windows-static so it could be an issue regarding dynamic builds which I've never done before. I may check on that later but it's not under my targets atm. Sorry, can't help yet.

New issue with latest vcpkg: ffmpeg[ffmpeg,x264] installation fails with "libx264 not found":
C:\vcpackage\vcpkg>vcpkg install ffmpeg[ffmpeg,x264]:x64-windows
Computing installation plan...
The following packages will be built and installed:
ffmpeg[avresample,core,ffmpeg,gpl,x264]:x64-windows

x264[core]:x64-windows
Additional packages (*) will be modified to complete this operation.
Detecting compiler hash for triplet x64-windows...
Starting package 1/2: x264:x64-windows
Building package x264[core]:x64-windows...
Using cached binary package: C:\Users\samof\AppData\Local\vcpkg\archives\80\803584d5f475e64bf2f465dfb329357606bc8ea4.zip
Building package x264[core]:x64-windows... done
Installing package x264[core]:x64-windows...
Installing package x264[core]:x64-windows... done
Elapsed time for package x264:x64-windows: 203.3 ms
Starting package 2/2: ffmpeg:x64-windows
Building package ffmpeg[avresample,core,ffmpeg,gpl,x264]:x64-windows...
Could not locate cached archive: C:\Users\samof\AppData\Local\vcpkg\archives\20\20a085d14f8e51af705bee60ebb9a68ee99fe9ad.zip
-- Using cached C:/vcpackage/vcpkg/downloads/ffmpeg-ffmpeg-n4.2.tar.gz
-- Cleaning sources at C:/vcpackage/vcpkg/buildtrees/ffmpeg/src/n4.2-a4d149a5c6.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source C:/vcpackage/vcpkg/downloads/ffmpeg-ffmpeg-n4.2.tar.gz
-- Applying patch 0001-create-lib-libraries.patch
-- Applying patch 0003-fix-windowsinclude.patch
-- Applying patch 0004-fix-debug-build.patch
-- Applying patch 0005-fix-libvpx-linking.patch
-- Applying patch 0006-fix-StaticFeatures.patch
-- Using source at C:/vcpackage/vcpkg/buildtrees/ffmpeg/src/n4.2-a4d149a5c6.clean
-- Acquiring MSYS Packages...
-- Acquiring MSYS Packages... OK
-- Building Options: --enable-asm --enable-yasm --disable-doc --enable-debug --enable-runtime-cpudetect --enable-gpl --disable-openssl --enable-ffmpeg --disable-ffplay --disable-ffprobe --disable-libvpx --enable-libx264 --disable-opencl --disable-lzma --disable-bzlib --enable-avresample --disable-cuda --disable-nvenc --disable-cuvid --disable-libnpp --disable-avisynth  --disable-static --enable-shared --extra-cflags=-DHAVE_UNISTD_H=0
-- Building Release Options:  --extra-cflags=-MD --extra-cxxflags=-MD
-- Building ffmpeg for Release
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:72 (message):
Command failed: C:/vcpackage/vcpkg/downloads/tools/msys2/msys64/usr/bin/bash.exe --noprofile --norc C:/vcpackage/vcpkg/ports/ffmpeg\build.sh C:/vcpackage/vcpkg/buildtrees/ffmpeg/x64-windows-rel C:/vcpackage/vcpkg/buildtrees/ffmpeg/src/n4.2-a4d149a5c6.clean C:/vcpackage/vcpkg/packages/ffmpeg_x64-windows "--enable-asm --enable-yasm --disable-doc --enable-debug --enable-runtime-cpudetect --enable-gpl --disable-openssl --enable-ffmpeg --disable-ffplay --disable-ffprobe --disable-libvpx --enable-libx264 --disable-opencl --disable-lzma --disable-bzlib --enable-avresample --disable-cuda --disable-nvenc --disable-cuvid --disable-libnpp --disable-avisynth  --disable-static --enable-shared --extra-cflags=-DHAVE_UNISTD_H=0  --extra-cflags=-MD --extra-cxxflags=-MD"
Working Directory: C:/vcpackage/vcpkg/buildtrees/ffmpeg/x64-windows-rel
Error code: 1
See logs for more information:
C:\vcpackage\vcpkg\buildtrees\ffmpeg\build-x64-windows-rel-out.log

Call Stack (most recent call first):
ports/ffmpeg/portfile.cmake:210 (vcpkg_execute_required_process)
scripts/ports.cmake:79 (include)
Error: Building package ffmpeg:x64-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with .\vcpkg update, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
Package: ffmpeg:x64-windows
Vcpkg version: 2020.06.15-nohash
Additionally, attach any relevant sections from the log files above.

@samofoz, I would advice openning a new issue -- comments in the closed issues sometimes are being ignored.