Potential issue for request smuggling

I would like to report a potential bug I found, which I previously submitted via email on November 1st. Since I haven’t received a response, I wanted to follow up here in case the email was missed or if GitHub is a more appropriate place for this report.
As I am not a security expert, I cannot fully assess the potential impact of this bug. Should I share further details here, or would it be better to contact someone privately? Thank you for your time and attention to this matter.

Please follow the Security Vulnerability Disclosure process documented here:
https://python-hyper.org/en/latest/security.html#vulnerability-disclosure
In case you already reported your finding to the mentioned email address, feel free to directly address it to me (you can find my email address via the git commit history) or jump into our team chat at https://app.gitter.im/#/room/#python-hyper_community:gitter.im to ask for more contact options.


Allow custom command arguments to override default values in docker

Depending on a setup, 1GB volume limit is not the preferable size.
As weed can process multiple arguements and the later argument is the one to be used,
it is relatively easy to override the arguments defined in the entrypoint.
The arguments passed to the script will be shifted and appended at the end of the command. Since the first argument will fall into specific case, the argument can be predefined and the whole argument array shifted. Allowing to do "volume/server/master/etc $ARGS $@"

Thanks! I did not know this nifty "shift" command. Nice!


install rockit

I'm trying to install rockit on a Windows 7 PC manually. I downloaded rockit-master, but I can't figure out how to install it. Please advise.

ajex12 - it's deployed as a python package, so check the documentation on how to install python packages.


Fix Python ternary syntax error

Introduced by bd2c1a7fedf795f792016548fb768d91bf22a768.

Thanks! Glad to see the python stuff is getting tested now 😅


@conda-forge-admin, please add bot automerge

Additional comment:
@conda-forge-admin, please add bot automerge

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I added bot automerge in conda-forge/architector-feedstock#2.


aws-device-farm-runner 0.0.2

This is a re-share of https://github.com/bitrise-io/bitrise-steplib/pull/659
(I rebased this on your master so it still does have the other PR in its history since it was already merged, but the delta should be clean)
New Pull Request Checklist
Please mark the points which you did / accept.

[x] I read the Step Development Guideline
[x] I have a test for my Step, which can be run with bitrise run test (in the step's repository)
Note: This test requires additional configuration to pass:

AWS_ACCESS_KEY and AWS_SECRET_KEY must be set in .bitrise.secrets.yml
An Amazon device farm project must be set up in the target region, and its ARN must be specified in the device_farm_project input
If platform input is...
1. ... set to ios, then ios_pool must be set to the ARN of an iOS device pool and ipa_path or envvar BITRISE_IPA_PATH must be set
1. ... set to android, then android_pool must be set to the ARN of an Android device pool and apk_path or envvar BITRISE_SIGNED_APK_PATH must be set
1. ... set to ios+android, then all of the above inputs must be set

see step.yml for more info on obtaining ARNs
[x] I did run bitrise run audit-this-step (in the step's repository - note, if you don't have this workflow in your bitrise.yml, you can copy it from the step template.)
[x] I read and accept the Abandoned Step policy

LGTM but please don't share more than one version at a time! There's no need to share 0.0.1 if you already have an update for it ;)


Use more features of unittest

Description

use assertTrue as recommended in examples (may switch to more specific assertIn for some)
use subTest for better messages on test failures

Motivation and Context

Trying to make it easier to add tests to our PRs #155, #152, #132 .
Checklist:

[x] I am familiar with the Contributing Guidelines.
[x] I agree with the terms of the Contributor Agreement.
[ ] The changes introduced by this pull request are covered by existing or newly introduced tests.
[x] The package documentation and framework documentation in signac-docs are up to date with these changes.
[ ] I have updated the changelog and added any related issue and pull request numbers for future reference.

Rather than doubling down on unittest paradigms here, I'd recommend porting our tests to use pytest. pytest has helpful error messages for plain assert statements.

@cbkerr I'm going to close this PR. If we were to apply these changes, it would actually move us away from pytest API design / paradigms, which we want to embrace. I haven't had time to migrate the testing suite fully to pytest, but it is an eventual task that I plan to take on after cleaning up some of the backlog of signac 2.0 and signac-dashboard 0.4.0 work. I opened #164 to track this.


git pull hangs

When there aremany new branches on the server which are not on the client, Git pull hangs during the communication with Bonobo. This happens when the response of upload-pack is larger than 4k.
The ouput (and input) buffer of a console app is maximum 4 k.
When the output buffer is full git stops processing the input buffer. Thereby the process hangs.

Thanks for this - it it the same issue as #840 would solve?

Hi Will,
Yes this solves the same problem. I did not find the other issue while searching for the problem.
I thought about using async calls. But the two async solutions I saw were changing the whole to async, which was a bit much. Or looping like #840. But when looping you use the processor for 100%. So quite heavy for the server.
Spawning another thread was les work and less pressure on the processor. The read hangs when there is no data.
Regards,
Leon


Update MSML Canonical Example Comparison Table

Also add in the current status (alpha, beta, production, work in progress)


Typescript support - Doesn't catch type issues like vanilla valtio proxy

Maybe I'm missing something, but it seems like this doesn't support typescript at the moment? I've used valtio before and was looking for something to help with data validation, but I feel like this now misses out on catching incompatible types. It seems I can't type the proxy like with valtio.
./types with original typescript type and zod schema/inferred type
import { z } from "zod";

export type ImageMetadataType = {
  base64: string;
  filename: string;
  tags: string[];
  title: string;
  contentType: string;
  width: number;
  height: number;
};

export type SelectFieldOption = { label: string; value: string };

// Base64 validation regex
const base64Regex =
  /^([A-Za-z0-9+/]{4})*([A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$/;

// Content type validation regex (matches any MIME type starting with 'image/')
const contentTypeRegex = /^image\/[a-zA-Z0-9+\.-]+$/;

// Filename validation regex (simple validation to exclude invalid filename characters)
const filenameRegex = /^[^<>:"/\\|?*\x00-\x1F]+$/;

// Define the ImageMetadata schema
export const ImageMetadataSchema = z.object({
  base64: z.string().regex(base64Regex, { message: "Invalid image data" }),
  filename: z
    .string({ required_error: "Filename cannot be empty" })
    .regex(filenameRegex, { message: "Filename contains invalid characters" }),
  tags: z.array(z.string({ required_error: "Tags cannot be empty strings" })),
  title: z.string({ required_error: "Title cannot be empty" }),
  contentType: z.string().regex(contentTypeRegex, {
    message:
      'Content type must start with "image/" and contain valid characters',
  }),
  width: z
    .number()
    .int({ message: "Width must be an integer" })
    .positive({ message: "Width must be a positive number" }),
  height: z
    .number()
    .int({ message: "Height must be an integer" })
    .positive({ message: "Height must be a positive number" }),
});

// Export the TypeScript type inferred from the schema
export type ImageMetadata = z.infer<typeof ImageMetadataSchema>;

Example valtio-zod vs valtio store setup with initial data (invalid base64 value)

If trying to use the same typing of proxy, it isn't supported like with valtio.

I did find i could separate the initial data and type it separately or specify the initial data inline {...} as ImageMetadata to catch the issue. Just thought it would be nice if it worked the same as valtio.

Sorry for the delay - I published a patch to hopefully fix this (0.7.5). This package is still pretty new and in development and it doesn't have many tests in place to verify everything working correctly. Feel free to play around with it and report anything you find (much appreciated!), however it might be a bit early to use in any important projects.

Thanks! I'll take a look at it. Yeah, this was for a small CMS plugin to do some basic cropping and metadata collection for images and thought it would be interesting to try separating the state and data validation from the UI component, so no worries.

Hope it works! Let me know if you run into issues.

Just getting back to thinking about this lib again - and something occurred to me about this issue...there's no reason we can't use z.infer to grab the type defs directly from zod object passed into schema. Basically do what you're doing in your type definitions file. There's no reason to make the lib user do this and make them pass a type. I'll make an issue for this.


Allow members to advertise using IPs

Is it possible for etcd members to advertise themselves via their IPs rather than DNS hostnames? Since they're on hostNetwork, I assume they will advertise their host IP.
The reason this is needed is that we're trying to integrate etcd-operator into kubeadm, but we do not have a working DNS server on bootstrap (because there is no CNI yet). The user sets up CNI after the control plane is working. We also want kube-apiserver on each node to hit its own etcd pod via localhost, so we really have no need to use services in our use case.
@hongchaodeng @xiang90 WDYT?
/cc @luxas

I'm suggesting making this configurable, with a new field in EtcdCluster or something.

Looks like this was already considered in https://github.com/coreos/etcd-operator/pull/122.
It seems that using the operator without a working DNS server is possible, just requires a bit of hacking because the host IP is only known after the pod is scheduled. @xiang90 what would be needed to make that work?

Hi @jamiehannaford
It's possible to use Pod IP. Actually we initially use pod IP in self hosted etcd to avoid depending on kubedns. The issue arises when adding TLS certs because IPs are dynamic.
With using of k8s csr endpoint we can switch to use pod IP: https://github.com/coreos/etcd-operator/issues/1465

@hongchaodeng Oh, cool! I think we use CSRs in kubeadm too with auto-approve so that might work really well. So I'm imagining how this would work...

We'd need to update addOneSelfHostedMember to find the node with no etcd pod on it. Then pass that node's IP into NewSelfHostedEtcdPod which can generate the CSR and make the pod command.

Add new fields to the spec struct for dynamic TLS. I'm thinking the RBAC user or group name that the operator will use to send the CSRs.

Use status.podIP if the user wants to use pod IPs instead of DNS.

Did I miss anything?

We'd need to update addOneSelfHostedMember to find the node with no etcd pod on it.

Scheduler does this for us via anti-affinity.

Then pass that node's IP into NewSelfHostedEtcdPod which can generate the CSR and make the pod command.

Correct. We will use init-container.

Use status.podIP if the user wants to use pod IPs instead of DNS.

DNS would be get ridden of. Instead of adding member in etcd operator, there will be an init container that does the add member command.

@hongchaodeng

Correct. We will use init-container.

SGTM. Will the init container also create the CSR, or will the operator handle that?

DNS would be get ridden of. Instead of adding member in etcd operator, there will be an init container that does the add member command.

So after init containers are added, only Node IPs are supported? If so, we will also need to add a new field to Member, right? Because m.Name is currently used to find its address

Will the init container also create the CSR, or will the operator handle that?

The init container. Pod IP can't be known until a Pod is created.

So after init containers are added, only Node IPs are supported? If so, we will also need to add a new field to Member, right? Because m.Name is currently used to find its address

We can think of this implementation later. We need to implement the dynamic TLS feature first.

@hongchaodeng Based on my comment, I don't think auto-approvals for CSRs can work for now. Instead, is it possible to get host IPs working with static TLS for 1.9? It will work if the cluster has its own CA right?

Hi @jamiehannaford
Using host IPs doesn't satisfy our use case because our nodes on which etcd pods are running have dynamic IPs.
Also see https://github.com/coreos/etcd-operator/issues/1465#issuecomment-342322365

@hongchaodeng kubeadm definitely has a use case of using host IPs. Can we implement this as a first step? How do you expect to solve dynamic host IPs?

How do you expect to solve dynamic host IPs?

Each etcd pod generates CSR and gets a cert for itself.

@hongchaodeng Why a CSR and not generate certs from a CA? It solves the exact same problem and is a lot simpler

Why a CSR and not generate certs from a custom CA file for the etcd cluster? It solves the exact same problem and is a lot simpler

I have no opinion on which is better. Any solution that works and solves user issues.

Hi @jamiehannaford
Sorry to revert https://github.com/coreos/etcd-operator/pull/1662.
Could you add a flag/field in spec to switch that?

Is there any plan on developing the option to advertise the client IP?


updated Newtonsoft.Json, fixed PlaceLimitOrderAsync()

package update is self explanatory
Good Till Time is a Limit Order Time In Force option
the cancellation of orders does not work as it currently stands
this is fixed by ensuring that the Time In Force: Good Till Time enumeration is applied before specifying the length of time before cancellation

gdax-csharp.zip
migrating to .NET Standard 2.0 is a much better idea than migrating to .NET Core 2.0.
I now realize that Standard is the base for all implementations of .NET including Core.

yeah, I’m out and about right now but I’ll run a clean fork and initiate a
pull request as soon as I make it back
On Sunday, March 4, 2018, Doug Dellolio<EMAIL_ADDRESS>wrote:

@dougdellolio commented on this pull request.
In GDAXClient/Services/Orders/OrdersService.cs
https://github.com/dougdellolio/gdax-csharp/pull/73#discussion_r172064860
:

@@ -82,6 +82,7 @@ public class OrdersService : AbstractService
ProductType productPair,
decimal size,
decimal price,

       TimeInForce timeInForce,

@confessore https://github.com/confessore this fix is super important.
can we pull this out into its own pull request and merge immediately? i
don't want this mingled in with the net standard changes. Also according to
the API, if the user is using cancel_after, marking as GTT is required.
This should be non-optional imo and just a part of the call below on line
96.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dougdellolio/gdax-csharp/pull/73#pullrequestreview-101019878,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB1LRAdR_ICnxQrj3G94aEqBQZe2Ot8Gks5tbFoagaJpZM4SbK_5
.


Update Copyright script to include README.md files

README.md files currently read '2016' where it should be '2016-2019' like all the other files.
Update the script located at ./cd/updateCopyrightHeaders.sh and files to show the updated header.

Hey, can I work on this issue?

Hi. I would like to take this up.

This issue was in fact fixed later by the reporter and merged in https://github.com/gchq/gaffer-tools/pull/864.


Clang for windows

@PoliakovVI, thanks for not being indifferent and putting an effort to this project! 🙏It helps a lot to make our course more win-friendly!


Mitmproxy cannot decode WBXML

Steps to reproduce the problem:
On

Open a request that contains WBXML (for example, sync requests of Apple Mail app)
In both the request and response tabs I see Couldn’t parse: falling back to raw

Any other comments? What have you tried so far?
I tried different versions of python with virtualenv, no difference.
I tried installing from pip and from brew, no difference.
I tried version 0.17.1 binary directly: worked (but I would prefer a not so old version)
I tried version 2.0.2 binary directly: didn't work.
System information
Mitmproxy version: 2.0.2 (release version)
Python version: 3.6.3
Platform: Darwin-16.7.0-x86_64-i386-64bit
SSL version: OpenSSL 1.1.0f  25 May 2017
Mac version: 10.12.6 ('', '', '') x86_64
(I only found this https://discourse.mitmproxy.org/t/cant-decode-wbxml/621 but there is no response there...)

Will it be possible for you to share the WBXML file?
Both the versions, 2.0.2 and 0.17 use the same decoder https://github.com/mitmproxy/mitmproxy/tree/master/mitmproxy/contrib/wbxml
If it works in 0.17 it should work in 2.0.2

This is an example of WBXML
hexdump:
0000000 03 01 6a 00 00 0d 45 48 03 32 34 30 00 01 49 4a
0000010 4b 03 31 37 00 01 4c 03 45 6d 61 69 6c 00 01 01
0000020 4a 4b 03 37 00 01 4c 03 45 6d 61 69 6c 00 01 01
0000030 4a 4b 03 31 31 00 01 4c 03 43 6f 6e 74 61 63 74
0000040 73 00 01 01 4a 4b 03 32 35 00 01 4c 03 4e 6f 74
0000050 65 73 00 01 01 4a 4b 03 31 35 00 01 4c 03 4e 6f
0000060 74 65 73 00 01 01 4a 4b 03 31 34 00 01 4c 03 4e
0000070 6f 74 65 73 00 01 01 4a 4b 03 31 32 00 01 4c 03
0000080 4e 6f 74 65 73 00 01 01 4a 4b 03 31 30 00 01 4c
0000090 03 43 61 6c 65 6e 64 61 72 00 01 01 4a 4b 03 31
00000a0 00 01 4c 03 54 61 73 6b 73 00 01 01 4a 4b 03 33
00000b0 00 01 4c 03 54 61 73 6b 73 00 01 01 4a 4b 03 32
00000c0 00 01 4c 03 54 61 73 6b 73 00 01 01 01 01
00000ce

or raw:
\x03\x01j\x00\x00
EH\x03240\x00\x01IJK\x0317\x00\x01L\x03Email\x00\x01\x01JK\x037\x00\x01L\x03Email\x00\x01\x01JK\x0311\x00\x01L\x03Contacts\x00\x01
\x01JK\x0325\x00\x01L\x03Notes\x00\x01\x01JK\x0315\x00\x01L\x03Notes\x00\x01\x01JK\x0314\x00\x01L\x03Notes\x00\x01\x01JK\x0312\x00
\x01L\x03Notes\x00\x01\x01JK\x0310\x00\x01L\x03Calendar\x00\x01\x01JK\x031\x00\x01L\x03Tasks\x00\x01\x01JK\x033\x00\x01L\x03Tasks\
x00\x01\x01JK\x032\x00\x01L\x03Tasks\x00\x01\x01\x01\x01

Which is correctly decoded in 0.17.1 as
<?xml version="1.0" ?>
<Ping>
    <HeartbeatInterval>240</HeartbeatInterval>
    <Folders>
        <Folder>
            <Id>17</Id>
            <Class>Email</Class>
        </Folder>
        <Folder>
            <Id>7</Id>
            <Class>Email</Class>
        </Folder>
        <Folder>
            <Id>11</Id>
            <Class>Contacts</Class>
        </Folder>
        <Folder>
            <Id>25</Id>
            <Class>Notes</Class>
        </Folder>
        <Folder>
            <Id>15</Id>
            <Class>Notes</Class>
        </Folder>
        <Folder>
            <Id>14</Id>
            <Class>Notes</Class>
        </Folder>
        <Folder>
            <Id>12</Id>
            <Class>Notes</Class>
        </Folder>
        <Folder>
            <Id>10</Id>
            <Class>Calendar</Class>
        </Folder>
        <Folder>
            <Id>1</Id>
            <Class>Tasks</Class>
        </Folder>
        <Folder>
            <Id>3</Id>
            <Class>Tasks</Class>
        </Folder>
        <Folder>
            <Id>2</Id>
            <Class>Tasks</Class>
        </Folder>
    </Folders>
</Ping>

But it is failed to decode in version 2.0.2:

And I checked that the content (by exporting it with command "b") is exactly the same

Very helpful, thanks!

I also find this decode error in version 2.02 and 0.9.2

It seems to be fixed in the latest release and also in master branch.
I used pathoc/pathod and these wbxml examples https://github.com/davidpshaw/PyWBXMLDecoder/tree/master/wbxml_samples to test it.
Mitmproxy v2.0.2:

Mitmproxy v3.0.0:

@mhils are we still fixing bugs for v2.0.2 and earlier?

@kajojify: no, we don't - 3.0 is around the corner. :-)

Then since it is fixed in 3.0rc2, I think it can be closed :)
A way to make sure, that wbxml is decoded (or isn't):

Run mitmproxy.
Create a folder and put into it any file from https://github.com/davidpshaw/PyWBXMLDecoder/tree/master/wbxml_samples.
pathod -a '/=200:b<"response-4569.wbxml"' -d ~/yourfolder/
pathoc -c localhost:9999 localhost:8080 'get:/'
In mitmproxy: enter the flow -> response -> m -> wbxml
Maybe this isn't the shortest way, but I used it :)

I checked a real-life scenario (an iPhone with iOS 11.2.5 and an exchange mail account configured). When doing any action with the Mail.app I could correctly see the wbxml content correctly parsed.

👍

This issue is back.
Parsing fails due to "KeyError: '0,2'" while .format-ing UNKOWN_TAG_
I created a pull request on PyWBXMLDecoder  The unknown tag that causes this problem is Codepage 0x16, Tag 0x15 returned by server


README: add verify labels step in "run in cluster" section

Some labels, for example pmem-csi.intel.com/node=, are added
to nodes only if certain feature gates are active,
makes it too easy to miss. Let's have a step checking labels.

have I addressed all comments now?

I can do a follow-up PR with this clerical change if you agree.

yes please, thank you!
I made changes by three recent proposals by Mary, thanks!


Add retention time to cw loggroup

Description
This pull request adds the option to specify a retention time of the CloudWatch log group that is created by the lambda, which does the shipping of the S3 log data to Coralogix. In particular, for some log types (like CloudTrail or VPC flow logs) the lambda creates much output, thereby creating large CloudWatch log groups. For most use cases, these logs in CloudWatch are not necessary and a short retention time is sufficient.
How Has This Been Tested?
The module was instantiated with the new variable set to 7 (i.e., one week retention)  and checked that the resulting CloudWatch Log Group has the corresponding retention time:
module "coralogix-shipper-s3" {
source = "<local_path>/terraform-coralogix-aws/modules/s3"
coralogix_region = var.coralogix_region
custom_url       = var.coralogix_custom_url
private_key      = var.coralogix_private_key
application_name = var.coralogix_application_name
subsystem_name   = var.coralogix_subsystem_name
s3_bucket_name   = var.bucket_name
integration_type = "s3"
s3_key_prefix    = local.s3_key_prefix
cloudwatch_logs_retention_in_days = 7
tags = var.custom_tags
}
Checklist:

[X ] I have updated the relevant example in the examples directory for the module.
[ ] I have updated the relevant test file for the module.
[ ] This change does not affect module (e.g. it's readme file change)

Hey @guyrenny , do I need to do anything else? I don't have write access to this repository, so I can't merge / close the pull request.


[Update] Homer<PHONE_NUMBER>05911296)

Updated short and long descriptions for my bot.

don't merge right now

no

i shall merge mwahahaha
jk

✅ U can merge


Fix "&&" operation

The current implementation of logical-and is incorrect. Fix it with the equivalent instruction combination.
Fix #120

Thank @vacantron for contributing!


docs: add vitepress-plugin-group-icons

This PR add vitepress-plugin-group-icons to enhance the document's readability.
After

Look @andretchen0 this can be handy for the rest of the ecosystem as well


Notify the Marketplace reg Carbonable's Royalties

Carbonable is now compatible for royalties

[ ] Convey to the marketplace about it

Hi! Can you elaborate on this?
I can take it!

Elements - configured
Integrate the Royalties
Marketplace Left
Pyramid
Unframed


Thought experiment: using schema.org + JSON-LD instead

First: don't shoot me. This is just a thought experiment, but one that I believe may prove useful.
My reasoning is as follows:

Many content producers already have to produce schema.org+JSON-LD for their content. If they could reuse it, it would be better than having to produce a second JSON representation with essentially the exact same information but a different syntax. (For people who don't already produce this, the differences for the most part boil down to taste.)
Many consumers already understand it, notably all major search engines.
The extensibility model is already covered: no need to think about it.
Several issues are already covered (I'm just listing a few that are obvious, there are certainly more): #44, #26, #22, #23, #19, #18, #38, #39, #13, #10, #15, #7.
It's already documented and already has a process for change and evolution, a lively community, a successful repo on GitHub, etc. All we need to define is the vernacular.

Downside:

It's a bit more verbose (but not that much).

This is just a translation of the example from the site's front page to give a feel for the result. If there's interest we can dig through more details.
{
  "@type": "Blog",
  "name": "My Example Feed",
  "mainEntity": "https://example.org/",
  "url": "https://example.org/feed.json",
  "blogPost": [
    {
      "@type": "BlogPosting",
      "@id": "https://example.org/second-item",
      "articleBody": "This is a second item.",
      "url": "https://example.org/second-item"
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.org/initial-post",
      "articleBody": { "@type": "rdf:HTML", "@value": "
Hello, world!
" },
      "url": "https://example.org/initial-post"
    }
  ]
}

"articleBody": "This is a second item.",
"articleBody": { "@type": "rdf:HTML", "@value": "
Hello, world!
" },

That's more than just "move verbose" -- it's more complex. A feed reader wouldn't be able to make any assumptions about the content of articleBody, they'd have to inspect each one.

@gruber I'm not sure what you mean about "inspecting". If the articleBody is a string, then it's text. If it's an object then the @type will tell you what it is — an option we could (and probably should) limit to HTML. That's no more inspection than checking to see if there is a content_text or a content_html.

This isn't the first time RDF is pushed onto feeds. It might be worthwhile to reflect on how well the RSS 1.0 effort did compared to RSS 0.92 and Atom and how often RSS 1.0 was actually consumed using RDF tooling.

Several issues are already covered

JSON-LD answers issue #39 by saying RFC 3986 even though the WHATWG URL spec is the one that's more useful to implement (actually says how to handle errors), so at least that point doesn't suggest that inheriting the choices of JSON-LD would be a positive thing.

Whoa there, let's not FUD Henri. JSON-LD != RDF. It's RDF-compatible, but most people who use it completely ignore that because it was designed that way. We have a complete and complex publishing system built atop JSON-LD and there is nothing in it RDFy, even though we do manipulate graphs. Worst-case scenario "RDF" shows up in the names of some things.

I totally support that. json-ld-feed is generic enough I'd be happy to store the the source of my blog/site in that, generate the HTML from it, and serve it in a feed either as is or lightly filtered.
You could theoretically do the same with json-feed, but you'd constantly run into things that it can't quite express yet, and either not do it, or come up with your own non-standard way of doing it, which means hell for clients trying to figure out what (if anything) it can do with the various bits of non standard data they find in your feed. Not all feed readers need to react to everything you find in a feed, but having well understood ways of including all sorts of information makes life easier for anyone who wants to.
Here are a handful of examples of things json-ld would know how to do, but json feed doesn't, all taken from a poetry site/blog I'm running (https://namino.rivoal.net/poems/):

say which language various things are in (author name, content of the post...) (relates to https://github.com/brentsimmons/JSONFeed/issues/40)
Non-english text in titles that need markup to be correctly represented, like 猫と太陽と
some items have an author, some items have a translator, some have both, some have several of each (relates to https://github.com/brentsimmons/JSONFeed/issues/6)
I store the author's name in multiple languages, also some times their place of birth, date of birth and date
I have various metadata about the book poems come from. This is easily expressed using json-ld + schema.org.

 Aside from the international aspects, arguably, you do not need all of these in a feed. But given the choice between a format that already has answer to all of these, and one that doesn't, I think it'd be a lot less pain to go with the one that does.
Having not just the json syntax in common with the rest of the world, but also the json-ld semantics makes for much easier interactions with all sorts of tools out there.

Whoa there, let's not FUD Henri. JSON-LD != RDF

"LD" is a rebranding of the "Semantic Web", so I think its fair to ask how things would be better this time round. XML got namespaces due to RDF, so clearly, the SemWeb influence wasn't positive on XML and contributes in significant part to why JSON feels simpler than XML even now that the SemWeb/LD community has moved on from XML. Now JSON-LD adds that complexity to JSON for largely the same reason.
More specifically in relation to feeds, history has RSS 1.0 as a data point. It seems fair to ask why mixing "LD" to JSON-based feeds would be better this time round compared to adding "RDF" or "Semantic Web" to XML-based feeds earlier.

It seems fair to ask why mixing "LD" to JSON-based feeds would be better this time round

While LD brings some complexity to JSON, the result is still way less complex that XML.

Using JSON-LD may not be the only way to solve all the relevant problems, but relevant problems need solving. As currently proposed, JSONFeed falls short on of a number of things that JSON-LD already solves. (See my earlier comment, or many of the open issues, including those quoted by @darobin ).

There's no evidence that all these problems will be solved for JSONFeed, or that if they are solved, the result will be less complex than JSON-LD.

To be candid Henri, it isn't clear to me why you feel compelled to import the nasty parts from the W3C/WHATWG playbook here. Just in that last short comment I count castigation by association (RDF, namespaces…), negative reframing ("rebranding"), and slippery sloping ("ZOMG you're going to bring namespaces"). There's a world outside standards and an awful lot of people are nice there. I see no need to spread that sort of tactic.
If your concern is the risk of grandfathering in complexity, that's a legitimate concern — certainly one that I share at any rate — but in that case why not just say it and discuss solutions instead of reaching for the negative?
The avowed purpose of this proposal is to maintain the simplicity of JSON Feed while reaping the benefits from an existing vocabulary that is already widely deployed, is already consumed by several major implementers, and has already solved many of the problems — including some that haven't been filed yet (@frivoal's ruby text example is a great one: it's a common Western-centric error to assume that things like title can be conveyed solely with a string). Grandfathering in external complexity would defeat the purpose, so I reckon it would be pretty stupid.
Thankfully there's a lot that can be done to retain the full simplicity of JSON Feed while not reinventing the wheel, not rediscovering solved problems, and benefiting from implementations. That's why I mentioned creating a vernacular, the implication being that it's just a subset of the syntax that processes like JSON-LD — enough to inherit the solved problems — but restricts it in a way that makes it usable by anyone who doesn't care what other things you can do there.
There are some technicalities involved obviously; I'm happy to help with those.

This is an interesting proposal, and it's given me the opportunity to become more familiar with JSON-LD and how it might fit with JSON Feed. Thanks! But it's really a different solution. JSON Feed prioritizes clarity and ease of implementation over some flexibility. JSON-LD is much larger in scope. If JSON-LD is solving problems for people, that's great. I'm glad it's there for developers to use if they need it.
Also, since RDF and RSS 1.0 was brought up... Many of us remember those early debates and we don't want to recreate that kind of "us vs. them" split.  Just something to keep in mind.
I think we can let this thread run its course and then close it. If anyone has related blog posts or other articles, feel free to post a link so there's a record.

To be candid Henri, it isn't clear to me why you feel compelled to import the nasty parts from the W3C/WHATWG playbook here.

I find it interesting that you accuse me of a nasty playbook here, when you suggested resolving issue #39 by the proxy decision of buying into a large bundle of decisions when you must be aware that of the specs mentioned over at issue #39 the WHATWG URL spec best serves practical needs and that a decision to delegate the choice to JSON-LD would effective mean buying into the W3C playbook of pretending WHATWG non-existence by refusing to make normative references to WHATWG specs even when it would make the most sense technically.
I thought that suggesting this kind of roundabout way of resolving issue #39 was particularly uncool, which is what prompted me to comment here in the first place.
Other than that, I spent quite a bit of time participating in the Atom standardization process, so I have some nostalgic interest in what happens in the next generation of feeds. Back then, there was debate of RDF or not to RDF and Atom chose not to RDF. Now that someone is trying to simplify further, it seems backwards to import the complexity back then avoided especially when there's the RSS 1.0 case to study. (It's telling that you seem to take association with RDF as an offense.)
Further, over the years, I've had a lot of bad time with Namespaces both implementation-wise and standards committee-wise, so I was particularly unhappy to discover that the bit of RDF history that should have been thoroughly recognized as a bad design has been imported into JSON-LD. I would hope that the next generation of specs could be spared from the badness of the prefix-based indirection of Namespaces in XML.

@manton I think maybe I was not entirely clear about the proposal. The idea is emphatically not to bring in all of JSON-LD. That would seem neither useful nor practical. The proposal is little more than to keep JSON Feed as it is with just 1) different field names, 2) a different mechanism for text/HTML distinction, and 3) @type. Item (3) is the one that annoys me most, but I can show examples of the sort of things that it enables (without touching the complexity of processors one bit).
Simplicity and clarity are unaffected, but we get a format that has already solved the problems faced here, that is already understood by major consumers, and that is already compatible with the content produced by a few million sites. I'm not entirely sure what's not to like…
FWIW I too recall many of the horrors surrounding the earlier RSS discussions, which is why I'm sad to see that universe spill over here, into what I hoped would be a constructive discussion.

@hsivonen Again, if it's #39 you have a problem with why not simply say so instead of being aggressive over it?  If you think that JSON-LD should reference WHATWG URL that is perfectly fine by me. I'm pretty sure that if you open an issue there then @gkellogg or whoever handles it will be happy to consider it.
I'm not sure what you're referring to about "pretending WHATWG non-existence"; I left that world a couple of years ago precisely because I feel life is too short to put up with the kind of toxic comment you are bringing here.
I would like to have a friendly, constructive discussion about this issue — that's why I came here. I have seen the (sadly, unofficial) numbers for the number of pages that have the type of schema.org content we're talking about here from a major processor and they're very impressive. Building on what is actually used out there strikes me as a plus over publishing the same content mostly using different key namews. That's all I care about here.
I know you're technically very competent Henri, so if you have constructive input then I very much welcome it. But I don't think technical competence can justify negative behaviour, so if it's just to grind whatever old axes you have with whatever organisation, I would very kindly, and very respectfully, ask that you please take your anger somewhere else.

@darobin Thanks for clarifying the proposal. Even those 3 changes would turn JSON Feed into something very different, though. I'm happy to learn from the problems that JSON-LD has already solved, but we can't rename the fields, or it becomes a different format.

but we can't rename the fields, or it becomes a different format.

That's true, but JSONFeed is very new and hasn't been deployed much yet (you can point a some deployments, but not at some tens of thousands of deployments yet), and regardless of whether you adopt the JSON-LD proposal or not, I think it's premature to consider it frozen. I know you've promised it would be and that you'd be compatible forever going forward, but nobody gets something this subtle right on the first attempt, and not all problems can be solved by strict additions.
Even if you end up rejecting the approach proposed here, please reconsider your stance on rejecting all breaking changes this early.

@frivoal Thanks for the feedback. We've been trying to take the approach of keeping most of the issues open for a while, including this one, so that people have a chance to comment. This proposal is for a completely different format, though. It's not so much that it's a "breaking change" as it throws everything out and starts over. :-)

I'm not sure what you're referring to about "pretending WHATWG non-existence"

Extreme avoidance of normatively referencing WHATWG specs. Trying to minimize credit to the WHATWG when publishing a WHATWG spec under the W3C name. Not mentioning WHATWG as a stakeholder in charters unless pushed to do so. This went on while you were still there.

negative behaviour

It's worth noting that "I see you are doing a spec. Please rebase your spec onto SemWeb/LD stuff." can be seen as negative behavior (in the context of this not being the first time) even if expressed very politely. Then if someone asks "How did it go last time?" that can be portrayed as negative.

Hi folks, jumping in here as one of the lead creators and spec editors of JSON-LD 1.0 to try and help...
@hsivonen said:

WHATWG URL spec best serves practical needs and that a decision to delegate the choice to JSON-LD would effective mean buying into the W3C playbook of pretending WHATWG non-existence by refusing to make normative references to WHATWG specs even when it would make the most sense technically

JSON-LD was born out of the desire to reflect reality (Web Developers use JSON) and do practical Linked Data (RDF is far too academic to be useful to most Web Developers). If it makes more sense to refer to the WHATWG URL spec, which I personally think it does, then we should reference it and fight for that in W3C. Especially because I think implementers will just implement according to the most practical spec out there (which is the WHATWG URL spec).
@darobin said:

 "@type": "BlogPosting",
 "@id": "https://example.org/second-item",

Remember that you can alias the "@id" and "@type" keywords to "id" and "type". Vanquish the curly "a" if possible. If this is a new format (which it seems like it is), I suggest you do that to avoid Web developers scratching their head over the strange syntax. The "@id" and "@type" keywords are already aliased in schema.org.
@gruber said:

  "articleBody": { "@type": "rdf:HTML", "@value": "
Hello, world!
" },

That's more than just "move verbose" -- it's more complex.

I agree with @gruber, -1 to doing that. Have you considered using JSON-LD Type Coercion, @darobin? So, you do something like this in the JSON-LD Context:
"articleBodyHtml": {
      "@id": "http://schema.org/articleBody",
      "@type": "rdf:HTML"  // or alternatively - "@type": "whatwg:HTML" :)
    }

That would enable you to do this in the JSONFeed document, which developers should like:
 "articleBodyHtml": "
Hello, world!
"

@darobin said:

different field names

To be clear, JSON-LD doesn't require you to change any of your field names. It should be possible to create a JSON-LD context that is compatible with JSONFeed's syntax today. It's true that there are some corner cases where this is not possible, but it should be true for 99% of the JSON-based data formats out there.

Just a couple short things and then I'd like to jump into the heart of it.
We've taken our discussion offline with @hsivonen (or rather, to a different online) so as not to annoy everyone here. I reckon we can shake away the misunderstandings.
@msporny I am well aware of all the tricks one can do with contexts, but my goal here is emphatically not to add a layer of indirection: it's to reuse the data model and code that millions of domains already use and that many large consumers (Google, Bing, etc.) already accept.
The "@type": "Blog"… example I store with is already what I (and several million other domains) have to put on a home page (as recommended by Google, etc.). Obviously, I can translate it to JSON Feed, but that's one more format to manage that has the exact same content and semantics as one that is already widely used on the Web. Adding a context (and therefore requiring translation) would defeat the purpose.
We already have schema.org as the de facto widespread data model for sharing blog data on the Web. I want to avoid reinvention — ideally this should just be an effort in agreeing to split that data out of the HTML and agree on some fields you must have (schema.org is a very loose duck-typing affair, it can help to require a few things on top).
Now, to address @manton's point, I would like to push back somewhat on the notion that this "throws out everything" or constitutes a major change in any way.
There are essentially two different kinds of change that could apply to a simple format: naming and processing algorithm. Naming is of course required to get both ends to understand something, but changing a name — especially early in the process — is a lot simpler and in a wholly different sphere from changing the processing, even in a simple way. If we decide to change title to zorblux (to please our new Zorbluxian overlords, obviously) it's pretty straightforward and different from, say, deciding that all the items must now be URL references to external things that need to be dereferenced.
Now, that's all a lot of word so I'd like to switch to code if you fine people don't mind. Below is a simple but (I think) representative of the problem space little CLI util that takes the URL of a feed and prints out the content of the first item as text on the console, implemented once in the current JSON Feed proposal and once in the schema-compatible variant. I'm taking a few shortcuts for brevity (essentially in error handling) but they're the same shortcuts in both.
JSON Feed:
const request = require('request');
const stripTags = require('strip-tags');

request({ url: process.argv[2], json: true }, (err, res, body) => {
  if (err) return console.error(err);
  let item = body && body.items && body.items[0];
  if (!item) return console.error('No item');
  if (item.content_html) {
    console.log(stripTags(item.content_text));
  } else if (item.content_text) {
    console.log(item.content_text);
  } else {
    console.log('No content');
  }
});

schema.org:
const request = require('request');
const stripTags = require('strip-tags');

request({ url: process.argv[2], json: true }, (err, res, body) => {
  if (err) return console.error(err);
  let item = body && body.blogPost && body.blogPost[0] && body.blogPost[0].articleBody;
  if (!item) return console.error('No item');
  if (item['@value']) {
    console.log(stripTags(item['@value']));
  } else {
    console.log(item);
  }
});

I would contend that these two implementations are pretty damn similar. Both are, to the best of my knowledge, complete and correct implementations of the task at hand, and in my opinion demonstrate enough of what would be involved in implementing a more elaborate tool (eg. a feed reader) atop either format.
The only difference is that the latter example uses a format that is already understood by all major search engines and a very large number of Web developers who've had to use it for SEO, with AMP, etc., whereas the former essentially reinvents that with different field names and problems that have already been found and solved elsewhere. The last I want is to disparage this effort, I really like the overall idea, but I don't understand why developers should be made to do the work twice. I know you're all smart folks so it can't be about preferring underscores to camel case or whatnot.
So — can we talk about this?

@darobin wrote:

@msporny I am well aware of all the tricks one can do with contexts, but my goal here is emphatically not to add a layer of indirection: it's to reuse the data model and code that millions of domains already use and that many large consumers (Google, Bing, etc.) already accept.

Ah, then in that case:

schema.org already supports @type and @id aliasing (it's in the vanilla schema.org context), even though all of their examples have @id and @type.
Try to stay away from { "@type": "rdf:HTML", "@value": "
Hello, world!
" }, as @gruber mentioned, people will have an allergic reaction to it. Either re-use articleBody as is... or lobby schema.org to add articleBodyHtml (with the proper data typing as I mentioned above).
Avoid using "@id": "https://example.org/initial-post", as it seems to duplicate url. Just use url OR use id, but not both.

In any case, +1 to using vanilla schema.org. If this community does that, I'm sure you can lobby schema.org for the tiny change that will make it easier for Web developers to pick this stuff up and treat it as JSON (the articleBodyHtml comment above).
Best of luck to the JSONFeed community. If you folks go the route of schema.org and JSON-LD, both of those communities are here to support you if you need it.

https://xkcd.com/927/
#SCNR

@alexplusde Heh. That never gets old. Even though I've seen it a few times in the last week. :-)
@darobin I appreciate where you're coming from with this. Also, thanks for the code examples! They do a good job of illustrating the similarities between the 2 formats.
But even though you joke that it can't be about camelcase, in a way it is. It's our belief that JSON Feed should be clear and readable, which will encourage more people to support it, because it's so obvious. There's already evidence that this is happening, with support from multiple feed readers shipping this week.
If we renamed items to blogPost and went back to one of these feed reader developers — let's say the developer of Feedbin — and told him to update his parser even though it would break all existing JSON feeds that people have been experimenting with... What would he say? There would have to be an incredibly good reason to force a change like that, and with this issue there are clear disadvantages in readability to renaming the fields regardless of current implementations. I hope you can see our perspective on that.
@msporny Thank you. That the @context can do aliasing and type coercion like that is really cool. Best of luck to the JSON-LD community as well.

@manton With respect, I can only push back. This repository was created nine days ago, the public announcement was six days ago. Are you honestly making the case that within a review period of nine days you are confident that you have delivered a sufficiently defect-free format? I don't believe anyone, no matter how smart or experience, would really expect that.
Or maybe if you'd already decided to keep it that way no matter what issues may be found beyond typos, it might have been simpler to not open it up at all? Or at the very least it may have been polite to say so.
If I were implementing a specification that was publicly announced six days ago, I would absolutely expect it to change. Everyone is familiar with what early adoption entails. I have every last bit of confidence in the ability of Feedbin's developer to let items = feed.blogPost || feed.items.
What's more, you are giving precedence to the few over the many. There are a few implementations and a few deployments, all of them early adopters with the wherewithal to handle change. You are, for unclear reasons, giving them precedence over the many more of us who will now have to produce (and test, and maintain, and fix, and document) the same exact same information in two different JSON formats.
Why you consider that the better decision strikes me as particularly unclear.

Fair enough, but I was trying to make the point that while we can debate whether the spec should be frozen — there are a lot of proposals and I'm reading all of them — at the very least there's friction introduced in any change, so the change has to be inarguably the correct way forward. blogPost does not fit the design of the spec: it's camelcase when nothing else is, it's not plural as all array fields should be, and it unnecessarily mentions "blog". And that's ignoring the complexity of the other changes like articleBody and rdf:HTML.
The repository creation date doesn't tell the full story. Many months of work went into this spec, debating it and rewriting it, before we felt it was ready to share with everyone.
I also think it's worth pointing out again that JSON Feed and JSON-LD can co-exist. They are solving different problems. They do not need to be merged into a single format.

hi @manton @brentsimmons, everyone. Quick intro: I run Schema.org, I work for Google, and this discussion is giving me RSS 1.0 flashback :)
JSONFeed is a fine and good thing, and to be honest I stepped back from jumping in and saying "hey look, here's how you could do something similar using Schema.org and JSON-LD" because it felt like it could come off negatively, and there are so many kinds of feeds already out there that another exploration of the design space can't hurt.  But since @darobin has opened the conversation and made some positive proposals, maybe I can share some thoughts from a Schema.org, Google and RSS1-ish person's perspective?
Schema.org was launched with an emphasis on Microdata syntax, but when JSON-LD came along we adopted it as another representation (alongside RDFa). All our schemas are defined in terms of a general purpose graph data model (it's basically a collection of named types and properties), so they are not tightly bound to any of these syntax choices. Other syntaxes we've looked at that might be interesting from a feeds perspective are CSV (see W3C CSVW which gives a JSON mapping of tabular data into graphs - spec + my undocumented js hackery), and also Web Components where the idea is to document the meaning of new custom elements by mapping into schema.org-based graphs.
Currently there is nothing on the Schema.org site about using JSON-LD outside of HTML, although this is a very natural and even simpler use of it. For now we only give examples (ab)using the


Bill Details-Follow Button

On the Bill Details page, specifically in the policy actions section, the follow button is currently non-functional. We need to implement a the functional follow feature to allow users to follow current Bill

it's currently functional on my dev localhost and is rendered hidden on production by the flags.notification
maybe I can follow up with you at some point during the week on Slack or at the next meeting


Add keep_symlinks option and disable it by default

This PR:

Adds keep_symlinks (--keep-symlinks in CLI) option disabled by default. By default, it will now copy the files referred by symbolic links.
Deprecates zip_symlinks (--zip-symlinks in CLI) option that used to only work with zip format. Now it works with other formats too.

Resolves #5
The rationale here is:

The downside is copying and it takes more time but we can make it it working everywhere, which is probably the main reason of packing a virtual environment, and also pretty important in distributed environments.
Presumably most of issues related to the path and prefixes will go away by doing this.
We can just simply copy by default first and incrementally whitelist the "safe" links like relative paths.

I added unittests and manually tested CLI after installing, for example:
venv-pack --keep-symlinks -o pyspark_venv-keep-symlinks.tar.gz
venv-pack --zip-symlinks -o pyspark_venv-zip_symlinks.tar.gz
venv-pack  -o pyspark_venv.tar.gz

The tests look already failing in the master branch ...

The tests look already failing in the master branch ...


Improve build copr experience

TODO:

[x] Document in build in-copr --help that people need to set up the Copr config, ideally link to https://docs.pagure.org/copr.copr/user_documentation.html#quick-start
[x] Also document this in packit.dev
[x]  Let the error message bubble to the stderr that a Copr project could not be updated because
the Copr token is missing, invalid or expired

Fixes  #1762
Related to https://github.com/packit/packit.dev/pull/593
Merge before/after
RELEASE NOTES BEGIN

Running build in-copr --help now tells users that the Copr configuration should be set before usage.
Error message now tells users that Copr project could not be updated because
the Copr token is missing, invalid or expired

RELEASE NOTES END

Regarding the test time-outs from Zuul. Please, rebase your branch so you have there the fixes we've added in the meantime.

@blankRiot96 Do you need any help or should we take care of this?


How to listen on ''loggin" event ?

Hey,
In default winston logger we can listen on 'logging' event with something like this
var logger = new (winston.Logger)({
  transports: [
    new (winston.transports.Console)({ level: 'info' }),
    new (winston.transports.File)({ filename: 'app.log' })
  ]
});

logger.on('logging', function (transport, level, msg, meta) {
  console.log(msg);
});

Is there anyway we can do the same for expressWinston?
Thanks

Supply express-winston with a winston-instance that has the callback

@krazylearner did the answer provided by @dmichelin work for you? You should be able to print to stdout by specifying a transporter. Does this solution not work for you?


Getting error when category has no background image

Steps to reproduce the problem

Create category with no background image
Exec query

{
  category {
    backgroundImage {
      url
    }
  }
}

Get an error

{
  "errors": [
    {
      "message": "The 'background_image' attribute has no file associated with it.",
      "locations": [
        {
          "line": 6,
          "column": 7
        }
      ],
      "path": [
        "categories",
        "edges",
        1,
        "node",
        "backgroundImage",
        "url"
      ]
    }
  ]
}

What I expected to happen
To successfully fetch category data.

Same situation should be checked for collections with no backgorund_image


Update test resources SP password creation to support Az >= 7.1.0

Az version 7.0.0 had an issue where new service principal credential creation would not automatically generate a password by default. To work around this, one had to pass in a password credential object with an empty password to get it to work.
With the update to 7.1.0, the behavior of creating a password automatically was restored, but it also appeared to change the parameter set such that the existing calls were broken (since we weren't passing a now required ServicePrincipalId parameter).
Cannot bind argument to parameter 'ServicePrincipalId' because it is an empty string.

This PR updates the script to handle 7.0.0 and >= 7.1.0 versions of Az. Eventually we can remove the special handling for 7.0.0 as no one should have it installed. For posterity in case anyone hits this, the error you get when running the 7.1.0 targeted code with 7.0.0 loaded is:
New-TestResources.ps1: Cannot bind argument to parameter 'String' because it is null.

Thanks to @kashifkhan for bringing this to my attention.

The following pipelines have been queued for testing:java - templatejava - template - testsjs - templatenet - templatenet - template - testspython - templatepython - template - tests You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejava - template - testsjs - templatenet - templatenet - template - testspython - templatepython - template - tests You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

/check-enforcer reset


Hash mark missing from color.hex passed to onChange handler

    let colorPicker = <div>
      <Button onClick={ this.onColorClick } style={{backgroundColor: color}}/>
      <ColorPicker display={ displayColorPicker } type="swatches" onChange={this.onColorChange}/>
    </div>;

Same issue with onChangeComplete

Fixed in<EMAIL_ADDRESS>

This bug has returned as of 2.0.0, onChange & onChangeComplete returns a hex with no hash

Seeing the same thing.  Master branch seems okay, but the 2.0.0 I get from npm contains the hash fix in the /src directory but not the /lib directory.  It's possible the published /lib is out of date.


Fix MaxKeys in boto3.client.list_objects_v2

As mentioned in https://github.com/spulec/moto/pull/2375,
"the MaxKeys limits the sum of CommonPrefixes and Contents other than each"

Closed with https://github.com/spulec/moto/pull/2417


Adding support to add/list vims(compute/networking) and wims

test this please

test this please

test this please


Refactor model serving section on the project details page

Closes #1942
Closes #1944
Description

This PR does the following things:

When both KServe and ModelMesh are enabled, and user creates a project, in the model serving section, we show them a card selection

The user could choose either card, a button will show to indicate the next action

When clicking the button, it will directly open the modal. The Multi-model serving platform will open the modal we previously had. The single model serving platform modal will be implemented in #1943

When the project is not labeled, but we only enabled either KServe or ModelMesh, we should the corresponding table with the empty state
When the project is labeled, directly show the labeled corresponding table (We add a tag at the top right of the section to indicate the enabled platform)

How Has This Been Tested?

Go to check the old projects, see if they are Multi-model serving enabled because they should be (We don't have KServe before and all the projects should have modelmesh-enabled label)
Go to create a new project
Try to choose different platform, see the change in the title action button
The single model platform button is not working now because we need the KServe modal. So try to choose multi-model serving platform and add a server
Once you successfully add a server, the project should be labeled and you can never see the selection
Try to go to the dashboard config to disable either KServe or ModelMesh
Wait for 2 mins, and create a new project, make sure this time you don't see the selection card, but it will directly take you to the empty table view based on the feature you enabled

Test Impact

Create 2 stories for future testing, will add more integration tests when the KServe modal is implemented
Request review criteria:

Self checklist (all need to be checked):

[x] The developer has manually tested the changes and verified that the changes work
[x] Commits have been squashed into descriptive, self-contained units of work (e.g. 'WIP' and 'Implements feedback' style messages have been removed)
[x] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[x] The developer has added tests or explained why testing cannot be added (unit tests & storybook for related changes)

If you have UI changes:

[x] Included any necessary screenshots or gifs if it was a UI change.
[x] Included tags to the UX team if it was a UI/UX change (find relevant UX in the SMEs section).

After the PR is posted & before it merges:

[ ] The developer has tested their solution on a cluster by using the image produced by the PR to main

@vconzola Could you check the screenshots and the current flow as described?

@christianvogt Can you take a look at this too please?


vscode version compatablity fix

include a version of package compatible with the version in nixos-unstable, nixos-stable, latest
at very least make sure to have version that works with nix-vscode-extensions.inputs.nixpkgs
expose an up to date vscode / codium
tag daily commit with newest version of vscode / highest min engine version.

let
  pkgs = import <nixpkgs> {};
  inherit (pkgs) lib writeTextFile;
  inherit (lib) catAttrs pipe importJSON;
  inherit (lib.lists) unique naturalSort last;

  file = ./vscode-marketplace-latest.json;

  text = pipe file [
    importJSON
    (catAttrs "engineVersion")
    unique
    (map (lib.strings.removePrefix "^"))
    unique
    naturalSort
    last
  ];
  output = writeTextFile { name = "engineVersion.txt"; text = text; };
in
output

gets the highest engineVersion

Please, check https://github.com/nix-community/nix-vscode-extensions/issues/41. I believe addressing the compatibility problem for all extensions is doomed. nix4vscode should solve this, but maintainers didn't have enough time to finish it and deprecate this repo (https://github.com/nix-community/nix-vscode-extensions/issues/47).

I saw #41 and am not a huge fan of having to generate lock file for extensions.
i use this script to figure out what version to pin to
with builtins; let
  pkgs = import <nixpkgs> { };
  inherit (pkgs) lib;
  currentVersion = "1.84.2";

  checkVersion = v: all (f: f v) [
    (lib.versionAtLeast currentVersion)
    (lib.versionOlder (lib.versions.major currentVersion))
  ];

  file = ./data/cache/vscode-marketplace-latest.json;

  json = lib.importJSON file;
  packages = filter (p: lib.strings.hasPrefix "github" p.publisher) json;
  getStripVersion = x: lib.strings.removePrefix "^" x.engineVersion;
  byVersion = groupBy getStripVersion packages;
  byMajor = groupBy lib.versions.major (attrNames byVersion);

  compatableVersions = filter checkVersion (attrNames byVersion);

  versionsThisMajor = byMajor.${(lib.versions.major currentVersion)};
  tooOldFor = lib.subtractLists compatableVersions versionsThisMajor;
  howBad = lib.flatten (lib.attrVals tooOldFor byVersion);

in
trace howBad (length howBad)

is it possible include  latest extensions supported by code in nixpkgs-unstable by running through the git history of the cache?
it's not hard to program. i'm just wondering if the scrapper will stay up.

@lizelive, you may try, but AFAIR there were changes to the JSON file format, so the scrapper may not work sometimes.


Translate tab removed for regional admins on campaign node.

#Fixes #5362
What's this PR do?
This PR removes the Translate tab (as well as the Devel tab) from the Admin Tabs in the main site view (as opposed to the tab in the admin CMS side).
Where should the reviewer start?
Start at line 86 in the preprocess.inc file and follow the breadcrumbs over into the helpers.inc file :wink:
How should this be manually tested?
If so desired, you can test by pulling down the branch, pretending you're a Brazilian or Mexican admin by changing your admin settings, and then seeing if the Translate tab (and Devel tab) show up for you when viewing the main site.
What are the relevant tickets?
#5362

@sbsmith86 @DFurnes
cc: @mikefantini @mshmsh5000

Ah, good catch ;)

Looks good to me! :hammer:

:dancers:


Use cloudposse/terraform-aws-cloudfront-cdn for cloudfront resources

Describe the Feature
Both this module and https://github.com/cloudposse/terraform-aws-cloudfront-cdn have overlapping cloudfront resources.
If we use the other module in this module, it will be less work to maintain. Otherwise PRs will have to be duplicated across both modules.
References

https://github.com/cloudposse/terraform-aws-cloudfront-s3-cdn/pull/195
https://github.com/cloudposse/terraform-aws-cloudfront-cdn/pull/76

Can you take the changes from this repository into your repository?

This is, in fact, the plan. This module will be refactored to use https://github.com/cloudposse/terraform-aws-cloudfront-cdn and https://github.com/cloudposse/terraform-aws-s3-bucket as part of the migration to support AWS Terraform Provider v4.


add UnitEnum stub (PHP 8.1)

@vudaltsov yes, it does. However this is special case because \UnitEnum is added to Symfony as a doctype regardless of PHP version. Example: https://github.com/symfony/symfony/blob/4.4/src/Symfony/Component/DependencyInjection/ParameterBag/ParameterBagInterface.php#L50
/**
     * Gets a service container parameter.
     *
     * @param string $name The parameter name
     *
     * @return array|bool|string|int|float|\UnitEnum|null
     *
     * @throws ParameterNotFoundException if the parameter is not defined
     */
    public function get($name);

This is Symfony 4.4 with PHP 7.
Because of that change all versions lower that 8.1 were failing.

Thanks, I needed that!

I need it too.
I described the problem here https://github.com/vimeo/psalm/issues/8380 and here https://stackoverflow.com/questions/73209831/unitenum-cannot-be-cast-to-string


Importing multiple palettes

First, thank you for making the plugin. It’s very useful and I’m using it all the time to manage color schemes in Sketch.
I wanted to separate all the Material Design colors into their own respective .sketchpalete files so that I could select only the colors I need for each project (e.g. material-design-red.sketchpalette, material-design-pink.sketchpalette, etc.), rather than having all of the Material colors at once.
However, it seems when I load a palette it overwrites the previous one. It seems it replaces the current palette with the new one. Is this a bug or just a use case that the plugin doesn’t handle?

Glad you're finding the plugin useful. It currently does not supporting appending colors, but that could be a nice addition. I'll consider adding it.

I just merged a pull request which changes the load functionality to append colors instead of replace them.


Fix React imports

I'm not certain why these were changed in this commit: https://github.com/xinthink/react-native-material-kit/commit/892c35e16c042dedf4d41eb3adb141d616017357, but this breaks the build in Xcode for my project. Restoring the previous version of these imports fixes the issue.

Thank you for that! I assume @xinthink is on an older version of RN


Source-build 3.0.1 SDK contains unintentional Microsoft.NETCore.App.Ref 3.0.1 patch

@dseefeld and I were looking at a 3.0.101 source-built SDK and found an unexpected 3.0.1 targeting pack:

/usr/share/dotnet/packs/Microsoft.NETCore.App.Ref/3.0.1 is the netcoreapp targeting pack.

Built from source by Core-Setup from 3.0.1 commit.

/usr/share/dotnet/sdk/3.0.101/Microsoft.NETCoreSdk.BundledVersions.props lists 3.0.1 as the expected targeting pack version.

Generated by Core-SDK based on version inputs.

(Paths from memory, may need correction.)
In the Microsoft build, Core-SDK manually pinned its dependency to avoid using this unintentional package, and instead use the old 3.0.0 version from nuget.org. The Microsoft SDK expects netcoreapp targeting pack 3.0.0, and carries the 3.0.0 targeting pack. 🙂
In source-build, the working theory is that since the 3.0.1 nupkg was built, its version was put in the PackageVersions.props (PVP). Core-SDK used the PVP version to generate the BundledVersions.props file and include it in the tarball. 😕
This 3.0.1 version doesn't seem to affect surface-level scenarios.

On a whim, we tried dotnet publish with the source-build 3.0.1 SDK. I was thinking that maybe the runtimeconfig would end up with 3.0.1 due to the patched targeting pack, but it was actually 3.0.0 still, which seems good. (It seems you can still publish an app with the 3.0.101 SDK that runs on any 3.0.x runtime.)
This SDK must have passed the smoke test, in any case.

@nguerrera do you know if this 3.0.1 targeting pack version ends up being used anywhere that causes a functional gap or incompatibility between source-build and the Microsoft build?

The plan to fix this in 3.0.2+ is to stop building the targeting pack in Core-Setup (unless it's being patched in that release) and instead ship the one from source-build-reference-packages: https://github.com/dotnet/core-setup/issues/8913.
/cc @adaggarwal @omajid @tmds @crummel

The plan is that this will be fixed in 3.0.2, so this can be close.

@nguerrera do you know if this 3.0.1 targeting pack version ends up being used anywhere that causes a functional gap or incompatibility between source-build and the Microsoft build?

I'm not aware of anything. If it is only the TargetingPackVersion and not the DefaultRuntimeFrameworkVersion that is different, and that TargetingPackVersion is installed, and it is not materially different from 3.0.0 other than the version number, it should work. It would basically be emulating what would happen if we had shipped a revision.


Removing Optimizely as it is flashing in viper

Removing Optimizely as it is loading too late from Viper and causing flashing on the pager

The travis build is failing.  Can you fix that?

+1

+1

+1


Add reload .datafusionrc

Needs IF NOT EXISTS for CREATE EXTERNAL TABLE to work properly

PR in datafusion to add IF NOT EXISTS is up https://github.com/apache/arrow-datafusion/pull/2143


Refactor config, parsers, formatters and types

Pull request checklist
Make sure you:

[x] Signed the Contributor License Agreement
[x] Followed the commit message guidelines

For non-trivial changes, please make sure you also:

[x] Added/Updated related documentation.
[x] Added/Updated related tests.

Short description of the change(s)

@sonarwhal/core this is ready for review.
@alrra, don't know how you want to handle the history of this one 🙄

don't know how you want to handle the history of this one

As with the rearchitecture, group related things together but keep things as they are otherwise.

@molant I'll try to update the list below, let me know what commit you think should be the ones associate with each issue.

Issue
Fixed by commit

#11
51f880a4d95d

#51
?

#123
?

#212
?

#361
?

#832
27b2fb6e78c8

#51
@alrra 27b2fb6 has a typo in the title of the commit:

configuartion

Also the concept of configuration was first added in d003eaa058ac9d6f099c5f2e7613f9fc32d555be. I would update the commit to that one (although there are several other commits that add documentation and add the missing functionality of working on global).
#123
The commit isn't related to that although I think we can close that issue because there's no way to do it AFAIK.
#212
OK with that commit
#361
OK with that commit
#832
Same as #51, I'd use d003eaa058ac9d6f099c5f2e7613f9fc32d555be because they are related.

On top of that I think we can close the following. The refactor to workspaces made them obsolete IMO.

Title
Commit

Move ESLint configs to their own repository #410
commit that introduced packages (#748)

Move scripts to its own repo? #536
commit that introduced packages (#748)

Allow entry point to not be HTML? #550
f453639

And maybe before publishing a new version we should also fix #497 which shouldn't take too long (but not blocking for this PR).

27b2fb6 has a typo in the title of the commit:

Fixed.


5-fold cross-validation of continuous target variable that has a highly-skewed distribution compared to normal distribution

I was wondering if you have suggestion on how to do something like stratified K-fold cross-validation in sklearn for classification task for categorical data but here for regression task and for continuous target variable?
Unfortunately, sklearn doesn't have such an option.

Hi - For StratifiedKFold module in sklearn, the document indicates that: The folds are made by preserving the percentage of samples for each class. So to replicate it in regression problems, a simple way is to divide the target range into discrete bins and calculate the #samples in each bin (the resolution might be based on each specific problem). Then you do the same thing by viewing bins as classes for fold division.
Since the question is not quite related to the repo, I'm closing it for now. Feel free to comment if you have any related questions.


Revamp folder structure

We should have a traditional src/test/docs structure.

Plus namespace names. Should / can we have Microsoft.ML as in ML.NET?

Plus namespace names. Should / can we have Microsoft.ML as in ML.NET?

I don't think that is a good idea. Success to me for this project would be acceptance into the PyTorch code base. Maybe we can use Torch as the prefix?

Few topics:
Agreed, we do not want "Microsoft" on the prefix.   Makes sense to use "Torch" instead of "TorchSharp", let us do that.
As for the layout of the project, you probably mean the "corefx" lineage, which is only traditional as "in the last couple of years", the tradition of cross platform .NET goes some 17 years back and that is a mixed bag.
I do not mind creating a toplevel for "test" and adding or moving various tests there, the rest I would keep as is.
In particular, "docs" is harder, given that I am publishing the API documentation from GitHub, the formatted docs have to go there, while the source documentation has to go elsewhere.

I think that all docs related can stay as they are. However it is probably better to factor source code into their proper folders: all tests into the test dir, and the remaining code into src. I also suggest to rename Tester to Sample.
So the final structure I have in mind is
/docs
/docfx
/ecmadocs
/test
/src
/src/TorchSharp
/src/Sample
(/src/TorchTensor) -> this is the mapping to SNT
For the namespace, I think we should have Torch as root. So TorchSharp will become Torch.TorchSharp (or Torch.Sharp?), and the bindings to SNL as Torch.Sharp.Tensor (I am open to suggestions here).
WDYT?

@interesaaat looks good - although we have to double check the location of test/ folder - it can be e.g. under /src/. Also, do we plan to keep using Microsoft.VisualStudio.TestTools.UnitTesting or switch to, say, XUnit or soething?

test should be its own folder IMO.  UnitTesting is ok since we already started with that.

@NiklasGustafsson any specific reason for having the test project not being part of the solution?


Comparison with blank crash

Issue https://github.com/microsoft/Power-Fx/issues/1301.

✅ No public API change.

✅ No public API change.

✅ No public API change.


FIX: Stylised Nav bar.

The Nav bar should be more attractive and stylised.

Make a new issue addressing the same problem, after the coding phase begins, i.e. after 12AM tonight.


Cannot see map of connection location on mobile when logged as Super admin

Version
2023.3.0-dev.5.1
Reproduction steps

Create a correction/deletion request
Approve the request
Check to see if the changes were applied in Compose

Expected behavior
After the request is approved, the new values should be applied in Compose
Screenshots/Videos

Tested on
Iphone 13 Pro Max
Safari

for today: investigate issue and stat implementing a solution

for today: resolve issue

for today: continue working on task and find a solution


Adding a reward combiner

Adding a combined reward to quickly combine different reward schemes into a single reward

Great minds think alike lol


fix: added filtering for GetUsersCountAsync

Enhanced the GetUsersCountAsync to include the filtering as documented here: https://www.keycloak.org/docs-api/22.0.1/rest-api/index.html#_users:~:text=GET /admin/realms/{realm}/users/count

@dijar-kadriu It appears that there are conflicts that need to be resolved. Could you please resolve these, and I will then merge the changes.

@sps-campbellwray I reopened the PR https://github.com/silentpartnersoftware/Keycloak.Net/pull/38


Right shift key not detected by wslg

Windows build number:
Windows 10.0.19045.2364
Your Distribution version:
20.04
Your WSL versions:
WSL version: <IP_ADDRESS>
Kernel version: <IP_ADDRESS>
WSLg version: 1.0.47
MSRDC version: 1.2.3575
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.2364
Steps to reproduce:

Open gedit/emacs with windows terminal
Type while holding the right shift key

Expected behavior:
Letters should be capitalized when right shift key is pressed.
Actual behavior:
Letters are not capitalized when right shift key is pressed. Other keys behave properly. Left shift key and caps lock properly capitalize letters. Left shift key properly produced lower case letters when pressed while caps lock is on, but right shift key has no effect when caps lock is on.
Right shift key behaves properly outside WSLg, such as while in the wsl terminal.
Everything works fine if I use VcXsrv instead of WSLg

@BrianShTsoi, thanks for reporting the issue. As I tried at my end, the right shift key works as expected and it doesn't exhibit the issue you mentioned. What keyboard layout are you using at Windows side, and do you happen to manually modify at Linux side (such as xkbsetmap)? And would you please share the equivalent log lines at your /mnt/wslg/weston.log as below. Mine has like below with English (United States) layout, thanks!
[12:46:15.264] kbd_layout:0x409 kbd_type:0x4 kbd_subType:0x0 kbd_functionKeys:0xc
[12:46:15.264] convert_rdp_keyboard_to_xkb_rule_names: matching model=pc105 layout=us variant=(null) options=(null)

Thank you for the quick response.
I used Microsoft PinYin (Simplified Chinese) as my keyboard layout. After reading your comment I switched to a US keyboard layout and the right shift key works properly. I also tried Microsoft Quick (Traditional Chinese) and the right shift key doesn't work. So I suppose the issue is about non-US keyboard layouts and at least I have a work around now.
I did not manually modify anything on the Linux side.
here's my log lines in /mnt/wslg/weston.log
[13:56:14.196] kbd_layout:0x804 kbd_type:0x4 kbd_subType:0x0 kbd_functionKeys:0xc
[13:56:14.197] convert_rdp_keyboard_to_xkb_rule_names: matching model=pc105 layout=(null) variant=(null) options=(null)

Thanks!

@BrianShTsoi, I installed Chinese (Simplified, Chine) - Microsoft Pinyin keyboard layout and right shift key works just same way as left shift key, thus I don't observe the issue you described, and observed same log at weston.log. What do you see with xev -event keyboard with right shift key? Below is from my environment, which shows "Shift_R" is pressed and released, do you see this? thanks!
KeyPress event, serial 35, synthetic NO, window 0x600001,
    root 0x390, subw 0x0, time 28034, (154,32), root:(553,560),
    state 0x0, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 35, synthetic NO, window 0x600001,
    root 0x390, subw 0x0, time 28192, (154,32), root:(553,560),
    state 0x1, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

I am encountering the same issue.
I installed Ubuntu 20.04.5 on Windows 10 Japanese.
wsl --version
WSL バージョン: <IP_ADDRESS>
カーネル バージョン: <IP_ADDRESS>
WSLg バージョン: 1.0.47
MSRDC バージョン: 1.2.3575
Direct3D バージョン: 1.606.4
DXCore バージョン: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windowsバージョン: 10.0.19045.2364

Following is an output from /mnt/wslg/weston.log
[23:41:14.963] kbd_layout:0xe0010411 kbd_type:0x4 kbd_subType:0x0 kbd_functionKeys:0xc
[23:41:14.963] convert_rdp_keyboard_to_xkb_rule_names: matching model=pc105 layout=us variant=(null) options=(null)

When I run xev -event keyboard with the right shift key, KeyPress is output when I press the key, but KeyRelease is not outputted when I release the key. Further more, When I press the right shift key again, there is no output in the console. Neither for releasing the key.
$ xev -event keyboard

Outer window is 0x600001, inner window is 0x600002
KeymapNotify event, serial 24, synthetic NO, window 0x0,
keys:<PHONE_NUMBER> 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
KeyPress event, serial 25, synthetic NO, window 0x600001,
root 0x390, subw 0x0, time 836845, (-399,-338), root:(0,0),
state 0x10, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

I've encoutered the same problem.
WSLg apps won't detect the right shift key. I don't find any problem with other keys.
My WSL version:
$ wsl.exe --version
WSL version: <IP_ADDRESS>
Kernel version: <IP_ADDRESS>
WSLg version: 1.0.47
MSRDC version: 1.2.3575
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.2486

The kbd_layout part of wetson.log - tell me if you want to see other parts.
It looks same to the output of @hideyuki88, so this might not cause this issue.
[20:56:46.345] kbd_layout:0x409 kbd_type:0x4 kbd_subType:0x0 kbd_functionKeys:0xc
[20:56:46.345] convert_rdp_keyboard_to_xkb_rule_names: matching model=pc105 layout=us variant=(null) options=(null)

Xev behaves the same to how @akidon30 reports.
The very first key push is detected, but releasing the key is not detected. Afterwards, even pushing the right shift key is not detected anymore.
$ xev -event keyboard
Outer window is 0x1000001, inner window is 0x1000002

KeymapNotify event, serial 24, synthetic NO, window 0x0,
    keys:<PHONE_NUMBER> 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0

KeyPress event, serial 25, synthetic NO, window 0x1000001,
    root 0x390, subw 0x0, time 362658, (1275,521), root:(2004,593),
    state 0x0, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

I do not have any modification to my key layout, nether in host nor in WSL.
Thanks

@akidon30, @asada-n, thanks for sharing the information. I noticed you are on Windows 10 (not Windows 11), so just in case I tried it on Windows 10, but I'm not able to replicate the issue at my end, the right shift works as expected. Thus, I'm sure there is something still missing at my end. Have you installed some keyboard shortcuts software monitoring the key input or have changed any configuration of Windows? thanks!

@hideyukn88, thank you for checking the information. I don't installed any software monitoring the key input, and don't change Windows configuration as far as I remember.
To investigate the issue, I made a local build of the WSLg to enable debug output that are commented out in the source code (xf_input_keyboard_event() in rdp.c of libweston), and got the following output in /mnt/wslg/weston.log.
I pressed a key twice after I launch the 'xev' command (I re-launch the 'xev' command before getting the log for each keys).
I noticed a value of 'ext' is changed from 0 to 1 for Right Shift key, but it is consistent for Left Shift key, Right Alt key and Left Alt key. I guess this could be a reason why the issue is occurred with Right Shift key only, but I have no idea how to investigate further. Let me know if you need any further information on my PC. Thank you!
 This is a bit confusing since at Windows keyboard driver level, right shift is extended key (see below link to Windows US English and Japanese keyboard layout driver)
From previous comments, it looks you are using Japanese 101 Keyboard Layout with IME (and you are not on OADG 106 Japanese keyboard which has "henkan" key next to space key). Just for sanity check, if you switch to US English layout (0x409), does it change anything? thanks!
Link to Windows keyboard layout driver for US English
https://github.com/microsoft/Windows-driver-samples/blob/07779ee84973f2f63a1f2ced6377463b1c01baaf/input/layout/kbdus/kbdus.c#L38
Link to Windows keyboard layout driver for Japanese 101 keyboard.
https://github.com/microsoft/Windows-driver-samples/blob/07779ee84973f2f63a1f2ced6377463b1c01baaf/input/layout/fe_kbds/jpn/101/kbd101.c#L42
Link to Remote Desktop Protocol Specification for TS_FP_KEYBOARD_EVENT
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpbcgr/089d362b-31eb-4a1a-b6fa-92fe61bb5dbf
FASTPATH_INPUT_KBDFLAGS_EXTENDED
Indicates that the keystroke message contains an extended scancode. For enhanced 101-key and 102-key keyboards, extended keys include the right ALT and right CTRL keys on the main section of the keyboard; the INS, DEL, HOME, END, PAGE UP, PAGE DOWN and ARROW keys in the clusters to the left of the numeric keypad; and the Divide ("/") and ENTER keys in the numeric keypad.

@akidon30, if you don't mind, would you please try "spy++"? If you have installed any version of Visual Studio (not Visual Studio Code), it's installed under, for example my case, it's enterprise edition, "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\Tools\spyxx_amd64.exe". And by monitoring window message to the Linux GUI application window, what key inputs are delivered to application.
Below is on my machine with press/release right shift key, which shows it doesn't have "fExtended" property.

@hideyukn88
Hello, thank you for all researches.
Just a quick report, I found the right shift key works as expected if I switch my input method from Japanese (Microsoft IME) back to English (US).

This is an output of spy++, right shift working as expected.

And this is an output of spy++, right shift not working as my IME is being enabled.

@hideyukn88, the right shift key works fine after I switch the input method to English(US) as well as @asada-n reports.
A result of spy++ in my PC is as follows:
input method is Japanese: (fExtended is set)

input method is English(US): (fExtended is not set)

I guess I am using 106 keyboard as the "henkan" key is placed next to the space key, but I am not sure because I am using a laptop PC (Surface Book 1).

@akidon30, @asada-n, now I'm able to reproduce the issue using Japanese keyboard layout on Windows 10, and @BrianShTsoi, using Chinese Pinyin layout as well on Windows 10, but it doesn't repro with English US layout even on Windows 10. And it does not reproduce on Windows 11 with any of those keyboard layouts. Given this is OS behavior difference, I will consider have some additional patch to address this in WSLg, thanks for helping us!

I would like to add some more information because it seems that the right shift and right control keys are
not detected by Gui apps and not some terminal/console apps.
| shell/app      | right shift key | right control key | comments                                                 |
|----------------+-----------------+-------------------+----------------------------------------------------------|
| wsl shell      | OK              | OK                |                                                          |
| emacs -nw      | OK              | OK                | emacs without windows                                    |
| emacs          | Does not work   | Does not work     |                                                          |
| spacemacs      | Does not work   | Does not work     | spacemacs is a layer over emacs, so expect same behavior |
| xterm          | Does not work   | Does not work     |                                                          |
| gnome-terminal | Does not work   | Does not work     |                                                          |

All the above apps were invoked from the wsl shell.
Hope this sheds light on this problem.
Details of machine
Host: Win10 Version 22H2 (OS Build 19045.2486)
WSL2 machine: Ubuntu 22.04.1 LTS

wsl --version
WSL version: <IP_ADDRESS>
Kernel version: <IP_ADDRESS>
WSLg version: 1.0.47
MSRDC version: 1.2.3575
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.2486

@khtan, thanks for info, but I can't not reproduce the issue with Right Control Key, it works for me on Window 10 with those East Asian keyboard has issue with Right Shift Key, are you using some other different keyboard layout, thanks!

I am using standard Microsoft keyboard for English language.
When u say u cannot reproduce the problem, which app ( emacs, xterm,
gnome-terminal ) did you use?
Since it is working for you, I would like to know more about your
configuration so that I can consider upgrading to them.
Are you on Win 10 22H2? Is your Ubuntu 22.04?
Thanks for your fast response,
On Thu, Feb 9, 2023 at 8:31 AM Hideyuki Nagase @.***>
wrote:

@khtan https://github.com/khtan, thanks for info, but I can't not
reproduce the issue with Right Control Key, it works for me on Window 10
with those East Asian keyboard has issue with Right Shift Key, are you
using some other different keyboard layout, thanks!
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/wslg/issues/930#issuecomment-1424474213,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACBDX6TXUQB2XOEJATAZ4ZLWWULWJANCNFSM6AAAAAATAJFN3Y
.
You are receiving this because you were mentioned.Message ID:
@.***>

@khtan,

Are you on Win 10 22H2? Is your Ubuntu 22.04?

I have tried both Windows 10 and 11, and both has all updates, and both on Ubuntu 20.04 LTS and 22.04.
If you have a chance, would you please share your /mnt/wslg/weston.log? thanks!

Thanks for your reply. Turns out my problem was self inflicted. Somehow, my Win10 has sticky keys turned on. So I turned off Mouse keys, Sticky keys, Toggle keys and Filter keys -- one of them was causing the Shift to not register for WSL2.


radicale: add ldap3 dependency to fix ldap support

Built-in LDAP authentication support for radicale is currently broken. This commit adds the required dependency to the package.
The change was tested on my system and seems to work fine.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Could we have this using optional-dependencies, so it's configurable for users that want to use ldap? Or what do you think, @dotlambda ?

Could we have this using optional-dependencies, so it's configurable for users that want to use ldap? Or what do you think, @dotlambda ?

I don't really see the point. It's a tiny dependency and having it included by default reduces friction and confusion.


Example of inserting data in MongoDB using Loopback framework

Can you share a simple example to add/update/delete records in MongoDB using Loopback framework ? Thanks

Old question and we don't have a loopback example.


Reset date only after event end date

Codecov Report

Merging #183 (a6c1943) into master (4b78852) will not change coverage.
The diff coverage is 33.33%.

@@            Coverage Diff            @@
##             master     #183   +/-   ##
=========================================
  Coverage     66.73%   66.73%
  Complexity      665      665
=========================================
  Files           107      107
  Lines          2363     2363
  Branches        312      312
=========================================
  Hits           1577     1577
  Misses          665      665
  Partials        121      121

Impacted Files
Coverage Δ

.../main/java/seedu/address/model/schedule/Event.java
59.77% <33.33%> (ø)

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 4b78852...a6c1943. Read the comment docs.

LGTM, @markbiju  @hanqinilnix wdyt?

Looks good to me too. I think this should be merged after #185 since both are editing the Event.java file. Need to be careful with the merge conflict.

@hanqinilnix but #185 doesn't edit anything about getNextRecurringEvent or getNextRecurringDate, yes? And this pr also doesnt use any edited function on #185. Is there anything we should check?


allow null in relationship data resource linkage list

It seems to me that the current specification has an inconsistency. The resource linkage may support ordered relationships, and an ordered relationship may have missing elements. Thus, the resource linkage list should allow null elements to represent to-many ordered relationships in which some elements are missing.

Could you provide an example use-case with a corresponding payload?

Here is an example of a document of a resource with relationship "foo" to "foos", in which 0th and 2nd element correspond to a resource, and 1st is empty:
{
  "data": {
  "id": "some-id",
  "type": "some-types",
    "relationships": {
      "foo": {
        "data": [{"id": "1", "type": "foos"}, null, {"id": "10", "type": "foos"}]
      }
    }
  }
}

This would be a breaking change, in the sense that it would break existing consumers—clients or servers—reading documents produced with this new payload. Whether that's a breaking change we could permit is a bit unclear (we need to better define what we mean by "additive only" in future specs). Sill, even if such a change is possible, I'm not sure that the breakage and extra complexity (there are already a lot of values possible in data) would be worth it—especially since the idea that a relationship is ordered is already optional/at the periphery of the spec.
Therefore, my recommendation would be to handle this with resource identifier object meta, like so:
{
  "data": {
  "id": "some-id",
  "type": "some-types",
    "relationships": {
      "foo": {
        "data": [
          // note how index 1 is missing
          {"id": "1", "type": "foos", "meta": { "index": 0 } },
          {"id": "10", "type": "foos", "meta": { "index": 2 } }
        ]
      }
    }
  }
}

A related issue is POST requests to a relationship. An ordered relationship could have the same element more than once. Would a server be compliant if it used the index field in meta to denote which element of the ordered relationship it should replace (optionally, in this case, allowing more than one of the same id/type)? If so, IMO that should be reflected in the specification explicitly, as otherwise it would seem that a server supporting an ordered, non-unique relationship would be not in compliance.


added some service mesh patterns

Signed-off-by: Aditya Chaterjee<EMAIL_ADDRESS>Description
Created a page for Service-mesh-patterns
This PR fixes #503
Notes for Reviewers
This needs images for all the different patterns(haven't figured out how to get them dynamically, yet), and also need to add the files for download.
Signed commits

[ ] Yes, I signed my commits.

@debo19 this still needs a lot of work, if you want you can work off this branch.
The preview: https://deploy-preview-545--mesheryio-preview.netlify.app/service-mesh-patterns

Messed up my branch, closing this PR.


Custom css classes?

The original library lets you override default classes:
{
    rangeClass: 'rangeslider',
    disabledClass: 'rangeslider--disabled',
    horizontalClass: 'rangeslider--horizontal',
    verticalClass: 'rangeslider--vertical',
    fillClass: 'rangeslider__fill',
    handleClass: 'rangeslider__handle'
}

Hi @adamsoffer - sorry for the late reply, somehow missed this issue.
It's possible, but I don't see a big benefit in it and would like to keep this small. If theres a real use case for custom classes I would prefer giving the option to add additional classnames instead of overriding.


multiple paths arguments

I have an error when trying to run behat with multiple feature files:

$ vendor/bin/behat 1.feature 2.feature
[Symfony\Component\Console\Exception\RuntimeException]
Too many arguments, expected arguments "paths".
behat [-s|--suite SUITE] [-f|--format FORMAT] [-o|--out OUT] [--format-settings FORMAT-SETTINGS] [--init] [--lang LANG] [--name NAME] [--tags TAGS] [--role ROLE] [--story-syntax] [-d|--definitions DEFINITIONS] [--snippets-for [SNIPPETS-FOR]] [--snippets-type SNIPPETS-TYPE] [--append-snippets] [--no-snippets] [--strict] [--order ORDER] [--rerun] [--stop-on-failure] [--dry-run] [--] []

did I misunderstood the  [<paths>] part ?
ps: I also tried vendor/bin/behat -- 1.feature 2.feature ⇒ same results

Looks like this isn't expecting an array (https://github.com/Behat/Behat/blob/master/src/Behat/Testwork/Tester/Cli/ExerciseController.php#L94)

There is a PR that adds this functionality to Behat: #996
For now only one feature file can be passed.

indeed, I didn't searched PRs for this. too bad it's a BC for extensions :(
should it be renamed path until it supports multiple paths ? (maybe this is a BC too)

indeed, I didn't searched PRs for this. too bad it's a BC for extensions :(
should it be renamed path until it supports multiple paths ? (but this is probably a BC too for extensions)

In the meantime you can probably use a shortcut with a temporary *.scenarios file:
your_first.feature:lineno
your_second.feature:lineno

For searchers who find this issue late to the party: I get this error message when I accidentally use single hyphen rather than double hyphen (e.g., -snippets-for rather than the correct --snippets-for) in the runner options. Once I fixed the argument syntax all proceeded correctly; the error message disappeared.