pnpm run generate fails out of the box

Summary
I am trying to fix the prior issue I reported and finding that without making any changes I am unable to successfully run pnpm run generate.
Steps to reproduce
Checkout latest react-storefront
Modify Dockerfile to use RUN npm install -g<EMAIL_ADDRESS>since the head of pnpm fails.
Ensure using npm install -g<EMAIL_ADDRESS>Now run pnpm run generate to try and process the thing, but it fails.
A link to a reproduction repository
https://github.com/matteius/react-storefront
What OS are you using?
Linux
Your next.config.js file

`next.config.js`
const withBundleAnalyzer = require("@next/bundle-analyzer")({
  enabled: process.env.ANALYZE === "true",
});

const apiURL = new URL(process.env.NEXT_PUBLIC_API_URI);
const allowedImageDomains = process.env.NEXT_PUBLIC_ALLOWED_IMAGE_DOMAINS
  ? process.env.NEXT_PUBLIC_ALLOWED_IMAGE_DOMAINS.split(",")
  : [];
const imageConversionFormats = process.env.NEXT_PUBLIC_IMAGE_CONVERSION_FORMATS
  ? process.env.NEXT_PUBLIC_IMAGE_CONVERSION_FORMATS.split(",")
  : [];

module.exports = withBundleAnalyzer({
  reactStrictMode: true,
  swcMinify: true,
  images: {
    domains: [apiURL.hostname, ...allowedImageDomains],
    formats: imageConversionFormats,
  },
  async headers() {
    return [
      {
        source: "/(.*)",
        headers: [
          {
            key: "x-content-type-options",
            value: "nosniff",
          },
          { key: "x-xss-protection", value: "1" },
          { key: "x-frame-options", value: "DENY" },
          {
            key: "strict-transport-security",
            value: "max-age=31536000; includeSubDomains",
          },
        ],
      },
    ];
  },
  experimental: {
    reactRoot: true,
  },
});

Builds logs (or link to your logs)

Build logs
(saleor) matteius@matteius-VirtualBox:~/mattscoinage/react-storefront$ pnpm run generate

><EMAIL_ADDRESS>generate /home/matteius/mattscoinage/react-storefront
> dotenv -c -- graphql-codegen --config codegen.yml -w

  ✔ Parse configuration
  ❯ Generate outputs
    ❯ Generate saleor/api.tsx
      ✔ Load GraphQL schemas
      ✔ Load GraphQL documents
      ✖ Generate
        →     at /home/matteius/mattscoinage/react-storefront/graphql/mutations/CheckoutLineUpdate.graphql:6:45
    ❯ Generate ./graphql.schema.json
      ✔ Load GraphQL schemas
      ✔ Load GraphQL documents
      ✖ Generate
        →     at /home/matteius/mattscoinage/react-storefront/graphql/mutations/CheckoutLineUpdate.graphql:6:45

 Found 2 errors

  ✖ saleor/api.tsx
    AggregateError: GraphQL Document Validation failed with 1 errors;
      Error 0: GraphQLDocumentError: Variable "$lines" of type "[CheckoutLineInput!]!" used in position expecting type "[CheckoutLineUpdateInput!]!".
        at /home/matteius/mattscoinage/react-storefront/graphql/mutations/CheckoutLineUpdate.graphql:3:3
        at /home/matteius/mattscoinage/react-storefront/graphql/mutations/CheckoutLineUpdate.graphql:6:45
        at new exports.AggregateError (/home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-tools+utils@8.6.1_graphql@16.3.0/node_modules/@graphql-tools/utils/index.js:82:16)
        at Object.checkValidationErrors (/home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-tools+utils@8.6.1_graphql@16.3.0/node_modules/@graphql-tools/utils/index.js:1253:15)
        at Object.codegen (/home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-codegen+core@2.5.1_graphql@16.3.0/node_modules/@graphql-codegen/core/index.js:175:15)
        at async process (/home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-codegen+cli@2.6.2_graphql@16.3.0+typescript@4.6.3/node_modules/@graphql-codegen/cli/bin.js:1126:56)
        at async Promise.all (index 0)
        at async /home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-codegen+cli@2.6.2_graphql@16.3.0+typescript@4.6.3/node_modules/@graphql-codegen/cli/bin.js:1136:37
        at async /home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-codegen+cli@2.6.2_graphql@16.3.0+typescript@4.6.3/node_modules/@graphql-codegen/cli/bin.js:925:21
    AggregateError: GraphQL Document Validation failed with 1 errors;
      Error 0: GraphQLDocumentError: Variable "$lines" of type "[CheckoutLineInput!]!" used in position expecting type "[CheckoutLineUpdateInput!]!".
        at /home/matteius/mattscoinage/react-storefront/graphql/mutations/CheckoutLineUpdate.graphql:3:3
        at /home/matteius/mattscoinage/react-storefront/graphql/mutations/CheckoutLineUpdate.graphql:6:45
        at new exports.AggregateError (/home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-tools+utils@8.6.1_graphql@16.3.0/node_modules/@graphql-tools/utils/index.js:82:16)
        at Object.checkValidationErrors (/home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-tools+utils@8.6.1_graphql@16.3.0/node_modules/@graphql-tools/utils/index.js:1253:15)
        at Object.codegen (/home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-codegen+core@2.5.1_graphql@16.3.0/node_modules/@graphql-codegen/core/index.js:175:15)
        at async process (/home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-codegen+cli@2.6.2_graphql@16.3.0+typescript@4.6.3/node_modules/@graphql-codegen/cli/bin.js:1126:56)
        at async Promise.all (index 0)
        at async /home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-codegen+cli@2.6.2_graphql@16.3.0+typescript@4.6.3/node_modules/@graphql-codegen/cli/bin.js:1136:37
        at async /home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-codegen+cli@2.6.2_graphql@16.3.0+typescript@4.6.3/node_modules/@graphql-codegen/cli/bin.js:925:21

  ✖ ./graphql.schema.json
    AggregateError: GraphQL Document Validation failed with 1 errors;
      Error 0: GraphQLDocumentError: Variable "$lines" of type "[CheckoutLineInput!]!" used in position expecting type "[CheckoutLineUpdateInput!]!".
        at /home/matteius/mattscoinage/react-storefront/graphql/mutations/CheckoutLineUpdate.graphql:3:3
        at /home/matteius/mattscoinage/react-storefront/graphql/mutations/CheckoutLineUpdate.graphql:6:45
        at new exports.AggregateError (/home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-tools+utils@8.6.1_graphql@16.3.0/node_modules/@graphql-tools/utils/index.js:82:16)
        at Object.checkValidationErrors (/home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-tools+utils@8.6.1_graphql@16.3.0/node_modules/@graphql-tools/utils/index.js:1253:15)
        at Object.codegen (/home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-codegen+core@2.5.1_graphql@16.3.0/node_modules/@graphql-codegen/core/index.js:175:15)
        at async process (/home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-codegen+cli@2.6.2_graphql@16.3.0+typescript@4.6.3/node_modules/@graphql-codegen/cli/bin.js:1126:56)
        at async Promise.all (index 0)
        at async /home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-codegen+cli@2.6.2_graphql@16.3.0+typescript@4.6.3/node_modules/@graphql-codegen/cli/bin.js:1136:37
        at async /home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-codegen+cli@2.6.2_graphql@16.3.0+typescript@4.6.3/node_modules/@graphql-codegen/cli/bin.js:925:21
    AggregateError: GraphQL Document Validation failed with 1 errors;
      Error 0: GraphQLDocumentError: Variable "$lines" of type "[CheckoutLineInput!]!" used in position expecting type "[CheckoutLineUpdateInput!]!".
        at /home/matteius/mattscoinage/react-storefront/graphql/mutations/CheckoutLineUpdate.graphql:3:3
        at /home/matteius/mattscoinage/react-storefront/graphql/mutations/CheckoutLineUpdate.graphql:6:45
        at new exports.AggregateError (/home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-tools+utils@8.6.1_graphql@16.3.0/node_modules/@graphql-tools/utils/index.js:82:16)
        at Object.checkValidationErrors (/home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-tools+utils@8.6.1_graphql@16.3.0/node_modules/@graphql-tools/utils/index.js:1253:15)
        at Object.codegen (/home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-codegen+core@2.5.1_graphql@16.3.0/node_modules/@graphql-codegen/core/index.js:175:15)
        at async process (/home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-codegen+cli@2.6.2_graphql@16.3.0+typescript@4.6.3/node_modules/@graphql-codegen/cli/bin.js:1126:56)
        at async Promise.all (index 0)
        at async /home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-codegen+cli@2.6.2_graphql@16.3.0+typescript@4.6.3/node_modules/@graphql-codegen/cli/bin.js:1136:37
        at async /home/matteius/mattscoinage/react-storefront/node_modules/.pnpm/@graphql-codegen+cli@2.6.2_graphql@16.3.0+typescript@4.6.3/node_modules/@graphql-codegen/cli/bin.js:925:21

  ℹ Watching for changes...
^C  Shutting down watch...

Function logs
No response

Ok I have fixed this in my fork:  https://github.com/matteius/react-storefront
But probably you'll want to port what is relevant because I also changed the default country from PL to US and I am going to start customizing the site more for my use case.   Will be interesting to see how to port back in the upstream changes, but I am fairly set in using this product since its Python/Django backend is what I am most trained in, and I have some react next.js experience.  It was actually kind-of fun figuring this out because it was my first time tinkering with TypeScript directly.

Ok I have fixed this in my fork: https://github.com/matteius/react-storefront
But probably you'll want to port what is relevant because I also changed the default country from PL to US and I am going to start customizing the site more for my use case. Will be interesting to see how to port back in the upstream changes, but I am fairly set in using this product since its Python/Django backend is what I am most trained in, and I have some react next.js experience. It was actually kind-of fun figuring this out because it was my first time tinkering with TypeScript directly.

What was the fix for this? @matteius

The main branch has been updated with a fix. Thank you for the report!


Added mock implementation of the Google Cloud NLP API

Added a mock implementation of Google cloud NLP API
Use that in necessary tests

Congratulations on the merge @arpitgogia !

		### Pull request completion results
		- **estimated day(s)**: %!s(int=10)
		- **actual day(s)**:    %!g(int=5)


Parquet: How to do concurrent decoding over columns?

Which part is this question about

parquet's api.
Describe your question

How to do concurrent read/decoding over columns? The similar code can be found in polars
I found the build_array_reader function, but I can't construct a ParquetField, which is the input param of this function.
Additional context

We currently only support parallelizing reads at the row group level. In practice this is usually plenty, although if you wanted to as support for this I'd be happy to provide some pointers

although if you wanted to as support for this I'd be happy to provide some pointers

Yes please, I would like to have a try.

Ok I'll have a think about how to approach this and get back to you in a couple of days

Ok I'll have a think about how to approach this and get back to you in a couple of days

hello, have you found any approach?


Layout Shift when Opening Select Component

https://github.com/shadcn-ui/ui/assets/119763173/ce8560fa-2d8f-4970-aaa8-0dfb8d40eebe

Can you provide a sandbox with the issue? Do you have overflow rules on  rather than ?

Try to remove overflow-x-hidden on .

Can you share a sandbox?

I had the same issue, removing the class of body to a new div under the body solved the issue.

@chengd42 thanks bro, that also solves my problem with dialog.

@chengd42  thanks!

I have the same issue and this is my code:

        {children}

  )

if for some reason anyone wants to solve this without moving all of body's classes into a new child div you can add "min-w-full" to body. added the ! for overkill
body {   @apply !min-w-full; }

c4bee2075a0940265dce10d721b22300.mp4
i get the same issue but more drastic.

I get the same problem, i able to work around it, below are the example.
 // parent container
      Content
 // dropdown in className don't forget "flex-1"

CN

My Account

Profile
Billing
Team
Subscription

There's couple of solutions I tested out myself, but this one works for me
Make the body width to viewport and hide the overflow horizontally

global.css

body {
    margin: 0;
    padding: 0;
}

html,body,:root {
    height: 100%;
}

layout.tsx

I also changed my custom navbar w-screen as it is also affected by the shifting

nav.tsx

Here's gif of what I experience & the fix
https://github.com/shadcn-ui/ui/assets/48374007/715fcbfa-75c4-4b30-bed5-6401684d7371
I hope this helps 😄

I encountered the same issue and was able to resolve it by removing all classes from the body element and adding a child div:
BEFORE:

         {children}

AFTER:

             {children}

@rollakal solved the issue man. thanks much.

I have the same issue and this is my code:

 {children}

  )

make another div in body and pass children and also remove the body css from global css or your main file

same issue here but fixed by adding min-w-full to the body tag

this worked for me, that data atributte is added once the select is open
body[data-scroll-locked]{
  min-width: 100%;
}

that worked for me, that data attribute is added once the select is open
body[data-scroll-locked]{
  min-width: 100%;
}

Does anyone have a plain CSS solution?
I'm not using Next, I'm using Vite, and my application isn't wrapped in a single-body tag.
If there's no other solution I'll do that, but I don't feel like adding layouts JUST for this yk?

Does anyone have a plain CSS solution? I'm not using Next, I'm using Vite, and my application isn't wrapped in a single-body tag. If there's no other solution I'll do that, but I don't feel like adding layouts JUST for this yk?

if u are using vite try to add this to your css
body[data-scroll-locked] #root{   min-width: 100%; }

the layout shift still appears, its because when i close the select, the vertical scrolling of the page appears, i need to find a way to  remove all vertical scrolls when dialog is open

Does anyone have a plain CSS solution? I'm not using Next, I'm using Vite, and my application isn't wrapped in a single-body tag. If there's no other solution I'll do that, but I don't feel like adding layouts JUST for this yk?

if u are using vite try to add this to your css
body[data-scroll-locked] #root{ min-width: 100%; }

the layout shift still appears, its because when i close the select, the vertical scrolling of the page appears, i need to find a way to remove all vertical scrolls when dialog is open

Please have you been able to fix this? I'm facing the same issue.

Does anyone have a plain CSS solution? I'm not using Next, I'm using Vite, and my application isn't wrapped in a single-body tag. If there's no other solution I'll do that, but I don't feel like adding layouts JUST for this yk?

if u are using vite try to add this to your css
body[data-scroll-locked] #root{ min-width: 100%; }

the layout shift still appears, its because when i close the select, the vertical scrolling of the page appears, i need to find a way to remove all vertical scrolls when dialog is open

Please have you been able to fix this? I'm facing the same issue.

I haven't, yet, I believe by the end of this week I'll try to debug it and maybe fix it, but I'm still left with no answers

Okay. I've spent quite a while on this and I can't really figure out what is wrong. I just noticed that if I remove some elements from the page it works fine. Please share your solution if you fix it. Thanks.

I have the same issue. I have a Select component inside Dialog, when I open the dialog, the data-scroll-locked property is added to the body. When I open the select component, the same property seems to be added, but when I close the select component, it removes the property, even when the dialog is still open.

I faced a similar issue, but with vertical layout shift. The cause was what @IvarK mentions - the rule body[data-scroll-locked] that is being applied once it opens. Overriding the vertical padding there fixed it for me.

I have the same issue. I have a Select component inside Dialog, when I open the dialog, the data-scroll-locked property is added to the body. When I open the select component, the same property seems to be added, but when I close the select component, it removes the property, even when the dialog is still open.

I'm experiencing this exact issue. Did you find a solution?

Pass something like this in comp if you are facing the same issue with dropdown
<DropdownMenu modal={false}>

By default it's set to true

I encountered the same issue and was able to resolve it by removing all classes from the body element and adding a child div:
BEFORE:

         {children}

AFTER:

             {children}

Perfect , worked for me , thank you

I encountered the same issue and was able to resolve it by removing all classes from the body element and adding a child div:
BEFORE:

         {children}

AFTER:

             {children}

worked for me

w-screen overflow-x-hidden

This is the best and cleanest solution, I only had to use w-screen in the body.
The second solution of moving the classes from the body to a div underneath it is not good for SEO.

if for some reason anyone wants to solve this without moving all of body's classes into a new child div you can add "min-w-full" to body. added the ! for overkill
body { @apply !min-w-full; }

Thanks @voidoperator  this resolved my issue

just put modal={false} on the  like this: , same for select!

@coding-billi but what about when you are using a Dialog and need's to use modal={true} ..?

Pass something like this in comp if you are facing the same issue with dropdown
<DropdownMenu modal={false}>

For select you can do this
html {
  overflow-x: hidden;
}

thanks a lot mate! this is the one that worked for me. by applying this the scroll wheel doesnt get hidden even when i open the dropdown menu and thats what was causing the layout shift

if for some reason anyone wants to solve this without moving all of body's classes into a new child div you can add "min-w-full" to body. added the ! for overkill
body { @apply !min-w-full; }

This one worked for me!

Pass something like this in comp if you are facing the same issue with dropdown
<DropdownMenu modal={false}>

For select you can do this
html {
  overflow-x: hidden;
}

this one is a kill

          {children}

This is good solution for me  .

In my case the layout shift was caused because the vertical scrollbar was removed, causing horizontal layout shift. Here is a solution for that:
<DropdownMenu.Root preventScroll={false}>

@andp97 worked for me ty ty

Pass something like this in comp if you are facing the same issue with dropdown
<DropdownMenu modal={false}>

For select you can do this
html {
  overflow-x: hidden;
}

Thanks for this solution, it was really helpful 👍

this is what worked for me

          <ThemeProvider attribute="class" defaultTheme="system" enableSystem disableTransitionOnChange>
            {children}
          </ThemeProvider>

I had to keep the inter.variable and the font-sans in the body because otherwise was changing font all over the place.

just add w-svw or w-screen

That really drives me crazy!!!!
I had already tried many solutions above, but not single solution could solve the problem until I tried a combination of solutions.

set modal={false}

<Select modal={false}
...
</Select>

css

html {
    overflow-x: hidden;
}

body[data-scroll-locked] {
    min-width: 100%;
}

No layout shift and missing of vertical scrollbar anymore for my case.
I think it really depends on the case. But thanks for all the solutions!

I also encountered this issue with Select and Drowpdown, the issue was my padding on the body, adding important to these CSS properties resolved the issue for me

Context
I have this css rule:
html {
  scrollbar-gutter: stable;
}

Because of this, I can't use some of the previously proposed solutions.
The Fix
I added the following rule to my globals.css:
html body[data-scroll-locked] {
  --removed-body-scroll-bar-size: 0 !important;
  margin-right: 0 !important;
}

Now, everything works as expected without causing a layout shift.
Additional Note
It seems like the issue might be related to Radix UI, although I haven't fully investigated it yet.
Source
https://github.com/radix-ui/primitives/issues/1496#issuecomment-1962839229

html > body[data-scroll-locked] {
  overflow: visible !important;
  margin: 0 !important;
}

Pass something like this in comp if you are facing the same issue with the dropdown
<DropdownMenu modal={false}>

For select you can do this
html {
  overflow-x: hidden;
}

This is the right answer! You don't even need to add the overflow-x-hidden property.
Just add modal={false} for the desired behavior.
Thanks.

I encountered the same issue and was able to resolve it by removing all classes from the body element and adding a child div:
BEFORE:

         {children}

AFTER:

             {children}

thanks man, it works for me.

just put modal={false} on the <DropdownMenu> like this, same for select! <DropdownMenu modal={false}>

Works perfectly!

Pass something like this in comp if you are facing the same issue with dropdown
<DropdownMenu modal={false}>

For select you can do this
html {
  overflow-x: hidden;
}

Thanks buddy, the overflow-x: hidden worked for me for the Select component

that worked for me, that data attribute is added once the select is open
body[data-scroll-locked]{
  min-width: 100%;
}

This worked for me.
Every time a DropdownMenu was opened, the layout shifted.

html > body[data-scroll-locked] {
  overflow: visible !important;
  margin-right: 0 !important;
}

this work for me. Thanks

You can set the modal prop of the of dropdown menu to false
<DropdownMenu modal={false}>...</DropdownMenu>
But this means I have to start adding this prop to every occurrence of the dropdown menu component. So instead, I added this to the globals.css file:
`
html {
overflow-y: auto;
scrollbar-gutter: stable;
}
body[data-scroll-locked] {
min-width: 100%;
}
`

It works fine for me, you can follow it, thanks
html {
    @apply overflow-x-hidden;
  }

  body {
    @apply  !min-w-full;
  }

I've removed the body code but still, my issue is not resolved
`export default function RootLayout({ children }) {
return (

    <CustomProvider>

      {children}

      <ConnectExpertModal />
    </CustomProvider>

);
}`
https://github.com/user-attachments/assets/eb8a7d57-7026-4caa-90cb-d08b55ee2ef5


Third-party virtual channel plugins on Remote Desktop client for MacOS

Remote Desktop client for Windows supports loading third-party virtual channel plugins.
Any plan to support this on macOS?

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

ID: b27f471b-700b-1bbb-7a44-ccb06b110182
Version Independent ID: 63667707-9901-abb7-953d-d1466d910eac
Content: What's new in the Remote Desktop client for macOS - Azure Virtual Desktop
Content Source: articles/virtual-desktop/whats-new-client-macos.md
Service: virtual-desktop
GitHub Login: @Heidilohr
Microsoft Alias: helohr

Hi @jingkunhuang - this isn't the correct place to ask as it's only for raising issues with the documentation. You should ask in the TechCommunity hub for Azure Virtual Desktop: https://techcommunity.microsoft.com/t5/azure-virtual-desktop/bd-p/AzureVirtualDesktopForum.
#please-close

@jingkunhuang
It looks like your issue is resolved since you closed this thread.
If there are further questions regarding this matter, please tag me in a comment. I will reopen it and we will gladly continue the discussion.

thanks @dknappettmsft @RamanathanChinnappan-MSFT
I will ask in the TechCommunity


Restrict Megaton Strike to specified Strikes

Also switched value for diceNumber on the rule elements, as the dice were not being added

You're going to need to update the migration as well.

You're going to need to update the migration as well.

I'll see if I can figure that out, but if I can't I suppose I can just draft this until next release


display errors with subset fonts and text fields in Chrome

Describe the bug
On font embed without the subset option, the characters get displayed normally, although the look doesn't seem to resemble the font. However, the main issue is having to embed a large font to a PDF only to use a few characters, which can be resource intensive on the network.
On this case, the editable text fields can't seem to use the subset fonts properly when it comes to Chrome. In Firefox, this issue doesn't seem to be found.
In Chrome (with subset enabled):

To Reproduce

import {
  PDFDocument,
} from '@pdfme/pdf-lib';
import fontkit from '@pdf-lib/fontkit';
import * as fs from 'fs';
import * as path from 'path';

const formPdfBytes = fs.readFileSync(path.resolve(`./src/forms/sample-form.pdf`));
const formPdfArrayBuffer = formPdfBytes.buffer.slice(formPdfBytes.byteOffset, formPdfBytes.byteOffset + formPdfBytes.byteLength);
const pdfDoc = await PDFDocument.load(formPdfArrayBuffer);
const form = pdfDoc.getForm();

const NotoSansCJKjp = fs.readFileSync(path.resolve('./src/assets/NotoSansCJKjp-Regular.otf'));
pdfDoc.registerFontkit(fontkit);
const jp_FontSupport = await pdfDoc.embedFont(NotoSansCJKjp, { subset: true });

const id = "<sample-id>"

const f = form.getTextField(id);
f.setText('mono物語gatari');
if (true) {
  f.updateAppearances(jp_FontSupport)
}

Expected behavior
In Firefox (although it doesn't look like the embedded font):

In Chrome (with subset disabled):

Your Environment
- "@pdf-lib/fontkit": "1.1.1"
- "@pdfme/pdf-lib": "1.18.3"
- Operating system: Windows 10
- Node.js version or Browser name & version: nodejs v20.11

Your Error Log
There is nothing to log

Additional context
I could be wrong in coding. Please let me know if there's code that works better.

Hi @qtwf !
This issue should be in the following repository:
https://github.com/pdfme/pdf-lib/issues
Also, I'd like you to understand what subset fonts are before creating issues.
Based on my understanding, this is the correct behavior.


Should snapshots be readable for everyone?

I had a look around for the snapshot folder and discovered that the file in it was readable for everyone, I also tried opening it in an image viewing program and that worked. The permissions on it are:
-rw-rw-r-- root <my user's group> /usr/lib/security/howdy/snapshots/20200716T180150.jpg
OS: Kubuntu 20.04
Howdy version: 2.6.0

That would be a lot better, yes. It might make it harder for people sending snapshots for debug purposes

I modified the snapshot.py code, to only store the data of the latest snapshot and remove all existing snapshots. The main reason for this was mainly to limit the size of the snapshot folder, which was getting absolutely huge! Everything is working fine as of now. Don't know whether there would be any issues after any update.

I have a question regarding the snapshots folder. Is it necessary to keep so many pictures if there is already a user model in the models folder?

This is a security issue. An attacker (another legitimate user of this PC) could trivially use the photos taken during successful authentication of the target user in order to impersonate the target user. I think this at least warrants a comment.

That's a good point, but "trivially easy" is a severe overstatement. Feeding the images back into Howdy requires either the code or the config file to be changed so a different (virtual/loopback) camera device can be configured. All these files should only be editable by root. If the root user is compromised then why even mess with Howdy?
The other option would be cloning the USB ID of the camera and using a dedicated board to impersonate it. This is only an option when you have physical access to the device and the camera is not build into a laptop.
You raise a good point but exaggerate the impact a bit. On 3.0.0 both options are disabled by default, as they should have been in the first place.

There are lots of instructions (mostly related to making howdy work with screensavers) that ask for changing the permissions recursively. So de-facto, if a person has successfully set up howdy to work with the screensaver, root is not needed for accessing the snapshots. And feeding back images to Howdy via the pre-existing camera requires only a printer and some paper, no need to mess with virtual cameras or custom USB devices.
So no, while this indeed does not apply to the new default configuration and default permissions, this is not an overstatement. Anyway, I understand that the next version will have the default changed - but could you please add some comments regarding this concern to the default config file?

I mean, yeah. If you modify a program like Howdy to be explicitly less secure i don't think you should be shocked to find it easier to bypass. This is only needed for some specific screensavers because they have a non-compliant PAM implementation. And while printing remains the easiest attack, you need a printer that prints in the IR spectrum, which not all printers do. Even then, you're just as vulnerable if a photo of you has ever been posted online.
So many of the default config options harm the security of Howdy: abort_if_ssh, abort_if_lid_closed, certainty and device_path are the most dangerous. I guess it would mean adding warnings to all of them. I'll think about it.


generate accessors for value/sentinel type-pair properties

@devoncarew

lgtm!
It's a little odd seeing dart and java in the same PR :)


Using your example, I am getting Null Check Operator used on a null value

════════ Exception caught by widgets library ═══════════════════════════════════
Null check operator used on a null value
The relevant error-causing widget was
MaterialApp
lib\main.dart:10

[√] Flutter (Channel stable, 2.0.3, on Microsoft Windows [Version 10.0.19042.867], locale en-US)
    • Flutter version 2.0.3 at C:\tools\flutter
    • Framework revision 4d7946a68d (10 days ago), 2021-03-18 17:24:33 -0700
    • Engine revision 3459eb2436
    • Dart version 2.12.2

[√] Android toolchain - develop for Android devices (Android SDK version 30.0.0)
    • Android SDK at C:\Users\jeremiah\AppData\Local\Android\sdk
    • Platform android-30, build-tools 30.0.0
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b01)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

[√] Android Studio (version 4.1.0)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin can be installed from:
       https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
       https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b01)

[√] VS Code (version 1.54.3)
    • VS Code at C:\Users\jeremiah\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.20.0

[√] Connected device (3 available)
    • sdk gphone x86 arm (mobile) • emulator-5554 • android-x86    • Android 11 (API 30) (emulator)
    • Chrome (web)                • chrome        • web-javascript • Google Chrome 89.0.4389.90
    • Edge (web)                  • edge          • web-javascript • Microsoft Edge 89.0.774.57

Because animated_splash_screen 1.1.0 depends on page_transition 2.0.1-nullsafety.0 and no versions of animated_splash_screen match >1.1.0 <2.0.0, animated_splash_screen ^1.1.0 requires page_transition 2.0.1-nullsafety.0.

I'm having the same issue

I am also facing the same issue. I resolved it by removing the page transition field from it. Although it is not a perfect solution because the page transition has gone.

I have had the same issue, and the solution at this point is to remove page_transition.

It's the only way to fix it that I have found.  It would be nice if the creator would come up with a solution or just go ahead and remove that feature.

Same issue here
Flutter 2.0.5 • channel stable • https://github.com/flutter/flutter.git
Framework • revision adc687823a (9 days ago) • 2021-04-16 09:40:20 -0700
Engine • revision b09f014e96
Tools • Dart 2.12.3

Same issue here
Flutter 2.2.0 • channel stable • https://github.com/flutter/flutter.git
Framework • revision b22742018b (7 days ago) • 2021-05-14 19:12:57 -0700
Engine • revision a9d88a4d18
Tools • Dart 2.13.0

i don't know why, some of the PageTransitionType will work expect. I choose use PageTransitionType.fade, hope help for you


Performances Issue

I have run the code as is, and for the default LambdaReset18 model
I am seeing accuracy of only 71.39% on the test dataset (which 96% on the training dataset)
Could you share the model for LambdaReset18

Thanks for comments !
You need to replace a code.
https://github.com/leaderj1001/LambdaNetworks/blob/95278e28fda14b9034a30be5bfecdfd57fef5095/model.py#L124
self.conv1 = nn.Conv2d(3, 64, kernel_size=3, stride=1, padding=1, bias=False)

Accuracy has improved a lot after reducing the kernel size from 7 to 3
But the max accuracy is still only 89.10% which is quite far from what is reported 93.32%
The model Parameters: 10121128 is different than what is reported 8.6M.
Is there any additional architecture changes which are required to add to the code
Also the default number of class is1000:
def init(self, block, num_blocks, num_classes=1000):
Which slows down the convergence, better to set it to 10 for CIFAR10
Thanks for the support!
Current Learning Rate: [1.9637012099169403e-05]
[Epoch:  310], Loss: 0.000, Acc: 100.000, Correct 12928.0 / Total 12928.0
[Epoch:  310], Loss: 0.000, Acc: 100.000, Correct 25728.0 / Total 25728.0
[Epoch:  310], Loss: 0.000, Acc: 100.000, Correct 38528.0 / Total 38528.0
[Epoch:  310], Acc: 89.110

The uploaded code is for ImageNet training. Therefore, you need to convert the code according to CIFAR to get the desired performance. In addition, 8.6M is a parameter when classes=10.
Thanks.

When setting the number of classes=10
The number of reported parameters is:
Model Parameters: 8092618

I think your u, m parameter settings are different.
u=1, m=23, 8.0M
u=4, m=7, 8.6M

I fixed values for u and m
and the model size now matches.
The performances for: LambdaResNet18 are still lower than expected:
Could you think of a reason why that may happen?
Current Learning Rate: [0.0654543046337755]
[Epoch:  215], Loss: 0.070, Acc: 97.625, Correct 12621.0 / Total 12928.0
[Epoch:  215], Loss: 0.075, Acc: 97.392, Correct 25057.0 / Total 25728.0
[Epoch:  215], Loss: 0.073, Acc: 97.485, Correct 37559.0 / Total 38528.0
[Epoch:  215], Acc: 86.770
Thanks

Resnet18 performance are verified (very close)
Epoch:  147], Loss: 0.002, Acc: 99.992, Correct 12927.0 / Total 12928.0
[Epoch:  147], Loss: 0.002, Acc: 99.992, Correct 25726.0 / Total 25728.0
[Epoch:  147], Loss: 0.002, Acc: 99.992, Correct 38525.0 / Total 38528.0
[Epoch:  147], Acc: 92.800 (compared to 93.0)

Performances for:
LambdaResNet18(num_classes=10)
Have not being verified yet:
Current Learning Rate: [1.9637012099169403e-05]
[Epoch:  310], Loss: 0.001, Acc: 99.996, Correct 25855.0 / Total 25856.0
[Epoch:  310], Acc: 86.650

@leaderj1001 I got the same Acc with @ssram50, its still lower than your AP:
020-11-24 13:37:47,301 Lambda INFO: [Epoch:   77], Loss: 0.015, Acc: 99.520, Correct 12866.0 / Total 12928.0
2020-11-24 13:37:58,849 Lambda INFO: [Epoch:   77], Loss: 0.015, Acc: 99.522, Correct 25605.0 / Total 25728.0
2020-11-24 13:38:10,404 Lambda INFO: [Epoch:   77], Loss: 0.015, Acc: 99.541, Correct 38351.0 / Total 38528.0
2020-11-24 13:38:23,640 Lambda INFO: [Epoch:   77], Acc: 87.450

When I use u=4, m=7, I get a 94.2% Acc.

without Dropout,
Gradient Clip: 2.0
stem: self.conv1 = nn.Conv2d(3, 64, kernel_size=3, stride=1, padding=1, bias=False)

Since the CIFAR-10 32x32 image resolution is used, it seems that u=4 and m=7 show better results.

Thank you.

@leaderj1001 u=1, m=23 are settings for exp above.
Could you please share your code for CIFAR-10 or create new branch CIFAR-10.
Thanks

Hi, @ssram50 @naviocean
I've successfully achieved 93.95 Acc with LambdaReset18. In addition to the setting of @leaderj1001 :

u=4, m=7,
without Dropout,
Gradient Clip: 2.0
stem: self.conv1 = nn.Conv2d(3, 64, kernel_size=3, stride=1, padding=1, bias=False)

I remove the first pooling layer by commenting out these lines: https://github.com/leaderj1001/LambdaNetworks/blob/3a51b6a7dbac9490dffed6a1bf68157e93135da6/model.py#L129
https://github.com/leaderj1001/LambdaNetworks/blob/3a51b6a7dbac9490dffed6a1bf68157e93135da6/model.py#L159
After this I achieved 93.27 Acc.
[Epoch:  146], Loss: 0.000, Acc: 100.000, Correct 12928.0 / Total 12928.0
[Epoch:  146], Loss: 0.000, Acc: 100.000, Correct 25728.0 / Total 25728.0
[Epoch:  146], Loss: 0.000, Acc: 99.997, Correct 38527.0 / Total 38528.0
[Epoch:  146], Acc: 93.270
Best Model Saving...
Current Learning Rate: 0.000714967387272874

By replacing CosineAnnealingWarmRestarts in:
https://github.com/leaderj1001/LambdaNetworks/blob/3a51b6a7dbac9490dffed6a1bf68157e93135da6/main.py#L97
with: lr_scheduler = torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, T_max=200)
I further achieved 93.95 Acc.
[Epoch:  209], Loss: 0.000, Acc: 100.000, Correct 12928.0 / Total 12928.0
[Epoch:  209], Loss: 0.000, Acc: 100.000, Correct 25728.0 / Total 25728.0
[Epoch:  209], Loss: 0.000, Acc: 100.000, Correct 38528.0 / Total 38528.0
[Epoch:  209], Acc: 93.950
Best Model Saving...
Current Learning Rate: 0.0004988171141721232

Hi @changlin31
Can you please share your code for the version that achieves: 93.95 Acc.
Thanks

Hi @ssram50 ,
I further achieved 94.12 Acc. Check out the modified code here: https://github.com/changlin31/LambdaNetworks/tree/cifar10
cheers

Hi @changlin31
Thank you so much for you help :)
I have verified the performances for CIFAR10 with Acc 93.470

Attaching another snapshot for the performances
Acc = 94.02


Add unit-tests for fileRemoved event.

Added unit-tests for fileRemoved event.
Testing three cases that should fire fileRemoved event.

Adding a second file when in single-file mode.
Calling Flow.removeFile.
Calling FlowFile.cancel.

Test involves checking if the event if fired, and if the first argument passed in is the FlowFile being removed.

Made a new pull request in #167


ROX-21992: Flip Feature Flag to on by default

Description
This PR enables the feature flag for roxctl deployment check improvements on by default (ROX_CLUSTER_AWARE_DEPLOYMENT_CHECK)
Checklist

~[ ] Investigated and inspected CI test results~
~[ ] Unit test and regression tests added~
~[ ] Evaluated and added CHANGELOG entry if required~
~[ ] Determined and documented upgrade steps~
~[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)~

If any of these don't apply, please comment below.
Testing Performed
Here I tell how I validated my change
Run deployed image and observe log output to ensure the feature is active by default
Reminder for reviewers
In addition to reviewing code here, reviewers must also review testing and request further testing in case the
performed one does not seem sufficient. As a reviewer, you must not approve the change until you understand the
performed testing and you are satisfied with it.

@vikin91 Apologies, I had to sneak in a bugfix for a nil panic I discovered in additional testing. Feel free to re-review 😄

/retest


base.po: Update chinese translations.

Fix some Chinese translations.
Signed-off-by: Angus Ding<EMAIL_ADDRESS>

cc @yousong

@angusding, @hnyman, Thank you


Aligning efforts

Hi @martin-lindstrom -
Should we align the efforts with your impl and the impl at https://github.com/ehn-digital-green-development/hcert-java

Will be glad to ...


Language keys in share buttons don't get parsed (title-attribute)

@LiNetKurando  Please could you clarify what you mean ?

If you hover one of the share-buttons, the language-key in the title-attribute of the button is not getting parsed.
This one (taken from online.me):

thank you @LiNetKurando for clarification


Allowed SHOW COLUMNS and SHOW INDEX to work with the promise interface

Thank you for the time you are putting into AlaSQL!

Codecov Report

Merging #868 into develop will increase coverage by 0.12%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           develop    #868      +/-   ##
==========================================
+ Coverage    67.78%   67.9%   +0.12%
==========================================
  Files            1       1
  Lines         9907    9907
  Branches      2960    2963       +3
==========================================
+ Hits          6715    6727      +12
+ Misses        3192    3180      -12

Impacted Files
Coverage Δ

dist/alasql.fs.js
67.9% <100%> (+0.12%)
:arrow_up:

Continue to review full report at Codecov.

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


Moar documentation updates

What's this PR do?

Added in the system file to the repo (:facepalm: I forgot this one)
updated a few links that didn't work

How should this be reviewed?
👀
Relevant tickets
Refs #6602

👍

⛵ 💨


Glitched Scoreboard

When using center-hud-linux-v17b the scoreboard is completely broken:

This is the non linux version, still scuffed but at least you can see something:

Could you try the most recent push? You download it here

Could you try the most recent push? You can download it here

That works! Thanks


[Proposal] Expose type FilteredContext.

Hello,
could you please export the FilteredContext type. This will make it easier code splitting in projects using Typescript.
Thanks.

It is already exported as Filter. See https://grammy.dev/ref/core/filter.


Subscription is not working with permission_classes

Subscription is failing with error after upgrading to version 0.217.0 from 0.216.1. Bug seems to be in permission_classes, because if I'm trying to use subscription without permission_classes, it works without any problem.

Describe the Bug
Error when subscription is used with permission_classes:
Traceback (most recent call last):
  File "/.../lib/python3.11/site-packages/graphql/execution/subscribe.py", line 206, in execute_subscription
    event_stream = await event_stream
                   ^^^^^^^^^^^^^^^^^^
  File "/.../lib/python3.11/site-packages/strawberry/schema/schema_converter.py", line 675, in _async_resolver
    return await await_maybe(
           ^^^^^^^^^^^^^^^^^^
  File "/.../lib/python3.11/site-packages/strawberry/utils/await_maybe.py", line 12, in await_maybe
    return await value
           ^^^^^^^^^^^
  File "/.../lib/python3.11/site-packages/strawberry/permission.py", line 172, in resolve_async
    return await next_(source, info, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: object async_generator can't be used in 'await' expression

Here is sample code to reproduce the bug:
class IsAuthenticated(BasePermission):

    message = "Unauthorized"

    async def has_permission(self, source: Any, info: Info, **kwargs: Any) -> bool:
        return True

async def sample(info: Info) -> AsyncGenerator[int, None]:
    while True:
        yield 1

@strawberry.type
class Subscription:
    sample = strawberry.subscription(
        resolver=sample, permission_classes=[IsAuthenticated]
    )

System Information

Strawberry version (if applicable): 0.217.0

Permissions are powered by FieldExtensions. These currently do not explicitly support subscriptions since we only expect awaitables or non-awaitable values, not for AsyncGenerators. However, since the new stream feature in GraphQL-core also allows to make every resolver an AsyncGenerator, we need to add support for it as part of #2914. I'll create a separate issue to track this in a moment.

#3318

Ok, thank you!


Destroy All Models At Once

I know that backbone likes to call destroy on each model but in my particular case, it would be nice to be able to destroy all models in a collection with one call to speed up the process.
My scenario.
I am using Appcelerator which uses backbone collections to bind models to a list view.  Say I have 100 models in the collection bound to the listview. This listview contains leads ( customers who made a call to a dealership in the past 30 days). Now I only want to show the customers who made calls to the dealer in the past 7 days.  I could use reset but that does not remove the models so the current list would still show the 30-day list instead of the 7-day list.  In order to show the 7-day list, I have to run a loop to destroy each model in the collection and re-populate the collection.  The destroy loop for just 100 items takes about 10 seconds while adding the items takes under a second.
Without being able to remove all at once the UI since Appcelerator runs on the main thread is frozen until all the models are deleted. Currently, there is no workaround for this issue.

Backbone adheres to how REST API's work. REST does not generally support DELETE on ranges or lists. That's why the Collection class does not have a destroy method. You'll have to build custom support for that yourself, if you really need it. However don't expect Backbone to ever support that.

I have to run a loop to destroy each model in the collection and re-populate the collection. The destroy loop for just 100 items takes about 10 seconds while adding the items takes under a second.

If you use a decent promise library and some smart looping you can do all or some of these HTTP calls "concurrently" and you won't have to wait for each of them to finish before starting another. That will probably speed up your the deletion process tremendously.
Note that I'm not a backbone maintainer but a maintainer will probably say the same.

I'm a Backbone maintainer (although only since recently) and in principle, I agree with what @jaapz wrote, though I also wonder: do you really need to destroy those models if you just want to see fewer of them? Besides, the destroy method is already non-blocking.
There's probably something I'm misunderstanding about the question. @jwogan5 please clarify whenever it suits you, I'll save this on ice in the meanwhile.


EditSign

Mod name
EditSign
Curseforge link
https://www.curseforge.com/minecraft/mc-mods/edit-sign
Other links
https://modrinth.com/mod/editsign
https://github.com/RakSrinaNa/EditSign
What it does
Allows editing signs after placement by right clicking.
Why should it be in the modpack
Makes it much less of a hassle to edit signs after placement, as without this mod you would need to memorize/screenshot the text, destroy the sign, and place the sign with the new text.
Why shouldn't it be in the modpack
Doesn't work on servers, see https://github.com/RakSrinaNa/EditSign/issues/62
Categories
New feature
Additional details
No response

This will never work on servers, unless vanilla adds it and that breaks the consistency. I want to keep singleplayer-only mods to a minimum, possibly only performance improvements like Lithium.


buildpacks

https://github.com/SvenTo/steampipe-plugin-cf/blob/main/docs/tables/cf_buildpack_v2.md


checking to see if bot gets this

@austin0602 i think u mad coz u r inserting some kinda shitty server data in here and the repo uses OriginDb for storing seen data and money it doesn't need a separate json bro


[STORM-763] nimbus reassigned worker A to another machine, but other worker's netty client can't connect to the new worker A

(This PR builds on STORM-839, so it includes its changes)
While I'm not 100% certain if it's the same issue, I also saw these messages logged a lot (hundreds per second per machine).
Upon investigation, I found that after firing a connection request, Client.Connector waits synchronously for the connection. Because there is only one scheduler thread per worker by default, this means only one connection request per worker process can be serviced at a time. This becomes a problem when connections are lost frequently for whatever reason, and is especially exacerbated when each connection attempt takes time.
Commit aa5c2d71 changes the code so that the Connector fires & forgets the connection request, and lets Netty's callback thread handle the rest. There is no blocking or expensive operation done here, so using Netty's thread should be fine.
This change did decrease the amount of ERROR logs in my topology, but I still saw a fair amount. Upon investigation, I found that this is simply because each call to send produces an ERROR log. So ad8112d10 changes the code so that a connection error is exactly logged twice; once when the connection error is detected, and the second time when the re-connection is concluded (either a successful re-connect, or permanent failure).

Do you have any performance numbers around this change?  This is on the critical path, and I want to verify that there has been no regression around this.
I am also a bit concerned about losing the pending metric.  We really need a good way to know if this connection is getting backed-up.  Meaning the network connection is slow but still up or is just simply saturated.  We really need an equivalent of pending for us to know how much data Netty has queued up to send.

@revans2 Re: pending metric, I see. I removed it thinking that it exclusively had to do with the pendingMessage field, but now I realise it was actually tracking messages inside Netty's internal buffer, too. I brought it back; should be equivalent to the old metrics.
Re: performance, I couldn't see any performance difference on my test cluster (5 node, processes around 60K tuples per sec) under "normal" conditions. With v0.9.4 it would start to go haywire after several hours and start to consume lots of CPU and a lot of tuples start to fail. That symptom seems to have been alleviated with the patch. However, this topology feeds off a live data stream so admittedly it's not a strict comparison (because the volume of data is not completely the same from run to run). Is there a standard way you guys use to verify performance regression?

@eshioji Sounds great. The metric looks good.  Just from looking at the code it looks good, but I do want to play around with it a bit before giving it a final +1.

@revans2 Sure, take your time and let me know if you find something to change!

@eshioji,
I ran some speed of light tests on my macbook pro, that was running all of the processes, and had 4 slots configured.  I ran with 4 spouts, 8 bolts, acking enabled and I varied the maxSpoutPending with 10, 1000, and 2000.  I calculated the average number of messages per millisecond.

maxSpoutPending
0.11.0-SNAPSHOT
STORM-763
diff

10
28.6491
26.9551
-1.694 (-5.9%)

1000
45.2541
43.0215
-2.2326 (-4.9%)

2000
42.7067
40.5542
-2.1525 (-5.0%)

As you can see this change is having an impact of about -5% on the performance in this one use case.  I do like very much that the code is smaller and STORM-763 seems significant enough that I am inclined to let this in as is, but I really would like to have you take a crack at possibly doing some optimizations to the code.  I'm not sure but my guess is that it is the 64k high water mark, which is switching the channel to no longer be writable, or the fact that we do not batch in-between calls to send.

@revans2 Thanks for the performance testing, I could replicate very similar results on our machine. I'm trying a few things, hopefully I can get it back to where it was.
In case you haven't noticed, this change includes fix for STORM-839 which seems pretty critical (I actually encountered a deadlock on my live cluster). Do you think the patch should be applied to 0.9.x if the performance concern is alleviated? Or are you more thinking of 0.11.x? (I noticed you tested with 0.11)
Also I have a question, maybe @miguno could help; I've removed the graceful shutdown which tries to flush all pending message before the Client is closed, mostly to make it easier for me to fix the deadlock. However now I'm worried I might have removed something significant. Do you think I should bring it back?

@eshioji wrote:
Also I have a question, maybe @miguno could help; I've removed the graceful shutdown which tries to flush all pending message before the Client is closed, mostly to make it easier for me to fix the deadlock. However now I'm worried I might have removed something significant. Do you think I should bring it back?

IIRC the graceful shutdown was primarily (but not exclusively) for non-acking topologies to minimize any potential data loss.  I think it would be preferable if we'd continue to allow for graceful shutdowns, if possible.

And like Bobby already said:  many thanks for your continued work and improvements, @eshioji!

@eshioji I think getting this into a 0.9.x release is doable, especially if the performance issues can be addressed.

@revans2 I was able to bring back the performance where it was, if not a bit higher:

0.9.5-SNAPSHOT
STORM-763

10
23.8
23.9

1K
78.6
82.5

2K
75.6
74.5

10K
71.1
72.9

The change brings back the batching of in-between calls. However, it does it a bit differently; instead of using a background process, it uses Netty's Channel interest notification callback. This should have an added benefit in theory, because pending messages are immediately flushed as space becomes available, rather than potentially waiting up to FLUSH_CHECK_INTERVAL_MS. I also brought back @miguno 's graceful shutdown. Let me know if this is good.
One question; I noticed that you guys plan to make 0.9.5 the last 0.9.x release. This PR is against 0.9.x, but should I rather open it against 0.10.x (or master)?
PS
@miguno No worries at all, I'm glad I can give back, however small it may be :)

Hi @revans2 , did you have time to look at the results above?

@eshioji Sorry I took so long to respond.
I am +1 for merging this in, but I want to see a corresponding pull request for master too.  I cannot pull code just into 0.9.x without going into 0.10.x and master too.

@revans2 No worries!
Just to clarify, do I create a pull request for 0.10.x AND master?

The main thing is around merge conflicts.  0.9.x is very different from 0.10.x and master, so when I go the cherry-pick there are a lot of conflicts.  0.10.x and master are still very close so I think just one pull request should be enough between the two.

@revans2 I see, OK, I'll ping you again when they are ready.

+1 the code compiles and the tests all pass

+1


Wrong macro used for loop condition in paging.cpp:initDirectory()

https://github.com/XyrisOS/xyris/blob/adf3ae0afff96e621f22f5f2c49e58e8d7b59203/Kernel/Memory/paging.cpp#L134
I believe the upper bound for the iterator of this for loop is meant to be ARCH_PAGE_TABLE_ENTRIES. The current code works because the two macros happen to have the same value.

You would be correct! Thank you for opening an issue, I'll merge in a fix soon.


Extending Vim Mode Operators

Is there any sort of API for extending the set of vim-mode operators? I've forked this repo to add an operator that emulates some of the functionality of vim-commentary but it seems like this sort of feature would be better added via a standalone package that requires vim-mode. Any recommendations on how to implement this?

As stated in the README, this package is no longer maintained and is deprecated. We recommend that people use the vim-mode-plus package instead. Because of this, we are archiving this repository and closing all issues and pull requests. Thanks very much for your support and contributions!


timer: TestTicker fail

I do maintain and run a build bot for Gentoo packages. Inside one of the running images (bubblewrap'ed images) the mentioned test case fails. The approproiate Gentoo dev  [2] is arguing that the environment of the tinderbox harms the test case scenario.
The build bot is a recent zen3 with enough RAM.  For a good overall throuput however I do chain each image via cgroups to 2 CPUs. Furthermore I do set [3]
EGO_BUILD_FLAGS="-p ${jobs}"
GO19CONCURRENTCOMPILATION=0

with jobs=2 or jobs=3 usually.
Does this by any chance harms the test case ?
[1] https://github.com/toralf/tinderbox
[2] https://bugs.gentoo.org/792963#c7
[3] https://github.com/toralf/tinderbox/blob/master/bin/setup_img.sh#L393

Is this a reproducible failure or a one off? how are you limiting CPU resources? and how loaded is the system (hardware) overall?

From https://bugs.gentoo.org/792963 the beginning of the failure report is
--- FAIL: TestTicker (2.80s)
    tick_test.go:79: saw 5 errors
    tick_test.go:37: 10 20ms ticks took 599.673629ms, expected [240ms,360ms]
    tick_test.go:37: 10 20ms ticks took 500.305963ms, expected [240ms,360ms]
    tick_test.go:37: 10 20ms ticks took 586.319661ms, expected [240ms,360ms]

This certainly suggests that there is something wrong but it's hard to know what.  I don't know what tinderbox does.  The environment variables you mention should not make any difference to this test.
This test can fail in this way if the machine is very busy, or if it is run in an environment in which the epoll system call does not honor its timeout with a reasonable granularity.  Because the test is affected by system busyness, the test is run five times with a delay in between, and only if all five cases fail is a failure reported.

Each image is given a cgroup v1 quota of usually 2.1 cpu if run with "make -j2" (https://github.com/toralf/tinderbox/blob/master/bin/bwrap.sh#L30) I can see that go spawns always much more threads as if could be used all 32 CPUs. The system is under load, yes - it is a build bot.
I will repeat the tests.

Is there some way that the Go runtime could know that it only has a limited number of CPUs available?  Currently on Linux systems the Go runtime determines the number of CPUs available by using the sched_getaffinity system call.

This looks like the same failure mode as #35692 and #37332.
On CL 313849, I suggested that this measurement would be better suited to a benchmark rather than a test.


Update README.md recommendations for implementations beyond v1.0-rc1

Beyond v1.0-rc1 we should not recommend external developers to implement a moving development version of the specification, or chaos will ensue.
- "My server implements v1.1-develop"
- "My client too"
- "Then why are they incompatible?!"

Ok, @merkys makes good points about version terminology. I've now updated the PR to only use SemVer terminology.


⚠ Mobitopup has degraded performance

In 037576e, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 4461 ms

Resolved: Mobitopup performance has improved in 82d9879.


Installation on official docker image fails

When uploading the latest release tar.gz Mattermost plugin installation fails with the following error:
"level":"error","ts":1572953682.8417873,"caller":"mlog/log.go:174","msg":"Unable to activate plugin","plugin_id":"mattermost-file-list","error":"unable to generate webapp bundle: mattermost-file-list: unable to copy webapp bundle directory: mattermost-file-list: mkdir client/plugins/mattermost-file-list: permission denied","errorVerbose":"mkdir client/plugins/mattermost-file-list: permission denied\nunable to copy webapp bundle directory: mattermost-file-list\ngithub.com/mattermost/mattermost-server/plugin.(*Environment).UnpackWebappBundle\n\t/go/src/github.com/mattermost/mattermost-server/plugin/environment.go:383\ngithub.com/mattermost/mattermost-server/plugin.(*Environment).Activate\n\t/go/src/github.com/mattermost/mattermost-server/plugin/environment.go:239\ngithub.com/mattermost/mattermost-server/app.(*App).SyncPluginsActiveState\n\t/go/src/github.com/mattermost/mattermost-server/app/plugin.go:100\ngithub.com/mattermost/mattermost-server/app.(*App).InitPlugins\n\t/go/src/github.com/mattermost/mattermost-server/app/plugin.go:133\ngithub.com/mattermost/mattermost-server/app.(*Server).RunOldAppInitalization.func6\n\t/go/src/github.com/mattermost/mattermost-server/app/server_app_adapters.go:148\ngithub.com/mattermost/mattermost-server/config.(*emitter).invokeConfigListeners.func1\n\t/go/src/github.com/mattermost/mattermost-server/config/emitter.go:35\nsync.(*Map).Range\n\t/usr/local/go/src/sync/map.go:333\ngithub.com/mattermost/mattermost-server/config.(*emitter).invokeConfigListeners\n\t/go/src/github.com/mattermost/mattermost-server/config/emitter.go:33\ngithub.com/mattermost/mattermost-server/config.(*commonStore).set\n\t/go/src/github.com/mattermost/mattermost-server/config/common.go:90\ngithub.com/mattermost/mattermost-server/config.(*FileStore).Set\n\t/go/src/github.com/mattermost/mattermost-server/config/file.go:107\ngithub.com/mattermost/mattermost-server/app.(*App).SaveConfig\n\t/go/src/github.com/mattermost/mattermost-server/app/config.go:378\ngithub.com/mattermost/mattermost-server/app.(*App).EnablePlugin\n\t/go/src/github.com/mattermost/mattermost-server/app/plugin.go:333\ngithub.com/mattermost/mattermost-server/api4.enablePlugin\n\t/go/src/github.com/mattermost/mattermost-server/api4/plugin.go:298\ngithub.com/mattermost/mattermost-server/web.Handler.ServeHTTP\n\t/go/src/github.com/mattermost/mattermost-server/web/handlers.go:146\ngithub.com/NYTimes/gziphandler.GzipHandlerWithOpts.func1.1\n\t/go/src/github.com/mattermost/mattermost-server/vendor/github.com/NYTimes/gziphandler/gzip.go:336\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:1995\ngithub.com/gorilla/mux.(*Router).ServeHTTP\n\t/go/src/github.com/mattermost/mattermost-server/vendor/github.com/gorilla/mux/mux.go:212\ngithub.com/mattermost/mattermost-server/app.(*RateLimiter).RateLimitHandler.func1\n\t/go/src/github.com/mattermost/mattermost-server/app/ratelimit.go:108\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:1995\nnet/http.serverHandler.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2774\nnet/http.(*conn).serve\n\t/usr/local/go/src/net/http/server.go:1878\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1337\nunable to generate webapp bundle: mattermost-file-list\ngithub.com/mattermost/mattermost-server/plugin.(*Environment).Activate\n\t/go/src/github.com/mattermost/mattermost-server/plugin/environment.go:241\ngithub.com/mattermost/mattermost-server/app.(*App).SyncPluginsActiveState\n\t/go/src/github.com/mattermost/mattermost-server/app/plugin.go:100\ngithub.com/mattermost/mattermost-server/app.(*App).InitPlugins\n\t/go/src/github.com/mattermost/mattermost-server/app/plugin.go:133\ngithub.com/mattermost/mattermost-server/app.(*Server).RunOldAppInitalization.func6\n\t/go/src/github.com/mattermost/mattermost-server/app/server_app_adapters.go:148\ngithub.com/mattermost/mattermost-server/config.(*emitter).invokeConfigListeners.func1\n\t/go/src/github.com/mattermost/mattermost-server/config/emitter.go:35\nsync.(*Map).Range\n\t/usr/local/go/src/sync/map.go:333\ngithub.com/mattermost/mattermost-server/config.(*emitter).invokeConfigListeners\n\t/go/src/github.com/mattermost/mattermost-server/config/emitter.go:33\ngithub.com/mattermost/mattermost-server/config.(*commonStore).set\n\t/go/src/github.com/mattermost/mattermost-server/config/common.go:90\ngithub.com/mattermost/mattermost-server/config.(*FileStore).Set\n\t/go/src/github.com/mattermost/mattermost-server/config/file.go:107\ngithub.com/mattermost/mattermost-server/app.(*App).SaveConfig\n\t/go/src/github.com/mattermost/mattermost-server/app/config.go:378\ngithub.com/mattermost/mattermost-server/app.(*App).EnablePlugin\n\t/go/src/github.com/mattermost/mattermost-server/app/plugin.go:333\ngithub.com/mattermost/mattermost-server/api4.enablePlugin\n\t/go/src/github.com/mattermost/mattermost-server/api4/plugin.go:298\ngithub.com/mattermost/mattermost-server/web.Handler.ServeHTTP\n\t/go/src/github.com/mattermost/mattermost-server/web/handlers.go:146\ngithub.com/NYTimes/gziphandler.GzipHandlerWithOpts.func1.1\n\t/go/src/github.com/mattermost/mattermost-server/vendor/github.com/NYTimes/gziphandler/gzip.go:336\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:1995\ngithub.com/gorilla/mux.(*Router).ServeHTTP\n\t/go/src/github.com/mattermost/mattermost-server/vendor/github.com/gorilla/mux/mux.go:212\ngithub.com/mattermost/mattermost-server/app.(*RateLimiter).RateLimitHandler.func1\n\t/go/src/github.com/mattermost/mattermost-server/app/ratelimit.go:108\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:1995\nnet/http.serverHandler.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2774\nnet/http.(*conn).serve\n\t/usr/local/go/src/net/http/server.go:1878\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1337"}

I see same, is there a solution?

This looks weird as the logs say that the the server did not have enough permissions to move some files around.
A person from the MM team did test that release on the official docker image so I'm not sure what's wrong:
https://github.com/Amonith/mattermost-file-list/issues/3
Soon I will release an update for the plugin with some changes to the configuration reading mechanism and I will target a newer version of MM (5.15+) so maybe let's test that again on that version.

What I noticed is that it is in general not possible to delete directories in my environment. I run several instances of the server in a local Kybernetes cloud and the mounted drives are shared between instances. Each directory has a . file that cannot be removed, therefore directories cannot be removed. One can only rename directories. Maybe there is an attempted move that fails?

Hi @parapar, @ewumnrr ,
Please check out the latest release 0.6.0:
https://github.com/Amonith/mattermost-file-list/releases/tag/v0.6.0
It now uses new official API for reading the config introduced in MM v5.16 and the package was built on docker with alpine-based container. Maybe this will solve the problem. Feel free to reopen the issue if it still doesn't work.


Edit link to Authorization from CREATE CHANGEFEED

Closes #5357.

This change is

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/aa1be0766cc3ecff8be8ea725b6f05bcb9bf58da/
Edited pages:

v19.1/create-changefeed.md


Bank: Invisible bank filters.

Self explanatory.
Looking for an option that allows me to hide bank filters WHILE using them.

Duplicate of #8751


ClusterLoader: copy unexported legacy function

This function was moved to private in k8s >=1.16,
but ClusterLoader still depends on it in a few places.
Copying the function in the meantime unblocks upgrading Go,
upgrading k8s, and moving to Go modules in ClusterLoader.
Suggested in https://github.com/kubernetes/perf-tests/pull/1171#discussion_r409777034 that I do this PR first.

/ok-to-test
/lgtm
/approve


test somewhere that Model._latex() successfully returns a string.

make sure it works for a Model with substitutions


Issue with Strip Scaling

Hi, I have a single strip of 210 WS2182B connected and when I use the scaling function, the strip works for a few seconds and then starts blinking all on/off. When I set the scale back down to 150 it seems to start working again. Any idea?
Code I'm using:
#include <CorsairLightingProtocol.h>
#include <FastLED.h>

#define DATA_PIN_CHANNEL_1 2

CRGB ledsChannel1[210];

CorsairLightingFirmware firmware = corsairLightingNodePROFirmware();
FastLEDController ledController(true);
CorsairLightingProtocolController cLP(&ledController, &firmware);
CorsairLightingProtocolHID cHID(&cLP);

void setup() {
  FastLED.addLeds<NEOPIXEL, DATA_PIN_CHANNEL_1>(ledsChannel1, 210);
  ledController.addLEDs(0, ledsChannel1, 60);
  ledController.onUpdateHook(0, []() {
    CLP::scale(&ledController, 0, 210);
  });
}

void loop() {
  cHID.update();

  if (ledController.updateLEDs()) {
    FastLED.show();
  }
}

Maybe a problem with your power supply? How do you power the strip and which Arduino do you use?

I'm powering the strip via an external power supply and I'm using a Leonardo. I haven't had issues driving the strip with this setup before as I was using this exact setup for a different lighting setup and it was working fine. I did some more testing and the issue happens more with rainbow mode. I think the arduino might be getting overloaded and dropping data.

you only define 60 leds in iCUE so it should not be overloaded with this.

Which version of this library (CorsairLightingProtocol) do you use?

Figured it out, my power supply was going bad, tried with another one and now its functioning correctly.


Property Bag Values on Groups/New Modern Sites

[ ] Question
[ ] Typo
[x ] Bug
[ ] Additional article idea

Expected or Desired Behavior
I am trying to set the property bag value of a group - per my understanding the process is:

disable DenyAddAndCustomizePages
set the property bag value
enable DenyAddAndCustomizePages

Observed Behavior
I get the error:
Set-PnPPropertyBagValue : The pipeline has been stopped.
At E:\0-install\3M\projects\DWP-SiteCollRpt\testScript.ps1:43 char:1
+ Set-PnPPropertyBagValue -Key "SiteType" -Value "Group" -Indexed
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : WriteError: (:) [Set-PnPPropertyBagValue], PipelineStoppedException
    + FullyQualifiedErrorId : EXCEPTION,SharePointPnP.PowerShell.Commands.SetPropertyBagValue

Steps to Reproduce
Clear-Host

#Import-Module -Name SharePointPnPPowerShellOnline -DisableNameChecking

# Shorten name!
$z=(pwd).path
$Component="O365"
try {
$weburl="https://me.sharepoint.com/teams/windowfilms2"
$AdminURL = 'https://me-admin.sharepoint.com'
$UserID = ([System.Security.Principal.WindowsIdentity]::GetCurrent().Name.Split('\',2))[1]
$UserIDFile = $z + "\..\..\SecuredCredentials\" + $UserID + "-" + $Component + "credID.txt"
$PasswordFile = $z + "\..\..\SecuredCredentials\" + $UserID + "-" + $Component + "credPassword.txt"
$Global:O365UserID = get-content $UserIDFile
$Global:O365password = get-content $PasswordFile | convertto-securestring
$Global:PScred = new-object -TypeName System.Management.Automation.PSCredential -ArgumentList $Global:O365UserID, $Global:O365password

Connect-PnPOnline -Url $adminurl -Credentials $PScred

$context = Get-PnPContext
$site = Get-PnPTenantSite -Detailed -Url $weburl
if ($site.DenyAddAndCustomizePages -ne "Disabled") {
	Write-Host "Disabling customize pages"
	$site.DenyAddAndCustomizePages = "Disabled"
	$site.Update()
	$context.ExecuteQuery()
}
#Connect-SPOnline -Url $SiteUrl -Credentials $PScred
Connect-PNPonline -Url $weburl -Credentials $PScred
$customizeValue=Get-PnPTenantSite -Detailed -Url $weburl | select DenyAddAndCustomizePages
$currentValue=Get-PnPPropertyBag -Key "SiteType"
$currentSearchValue = (Get-PnPPropertyBag | select key,value |where {$_.Key -eq "vti_searchversion"}).Value
Write-Host "Site URL - " (Get-PnPSite).Url

Write-Host "DenyAddAndCustomizePages - $($customizeValue.DenyAddAndCustomizePages)"
Write-Host "Search - $currentSearchValue"
Write-Host "siteType - $currentValue"
Set-PnPPropertyBagValue -Key "SiteType" -Value "Group" -Indexed

# To Enable
$site.DenyAddAndCustomizePages = "Enabled"
$site.Update()
$context.ExecuteQuery()

Get-PnPTenantSite -Detailed -Url $weburl | select DenyAddAndCustomizePages

Disconnect-PnPOnline
} catch {
	Write-Error $_.InvocationInfo
	Write-Error $_
}

Thanks for your feedback.  Could you please provide more information about the error?  For example, a correlation ID or a more specific error message from SharePoint?

there is no correlation ID as this is executed via Powershell... how do I get one for you?  Please advise

These PowerShell cmdlets use CSOM to communicate with SharePoint.  Using Fiddler, for example, you can get the correlation ID for a CSOM request (look for a POST to _vti_bin/client.svc/ProcessQuery) and get the value of the SPRequestGuid response header.

Hi suz,
the problem was in the PowerShell script where the context was mixed up cross admin and normal site, so your updates were not properly applied. Here's updated and validated script to do this using PnP PowerShell. I'll close the issue now, but obviously please let us know if there are any follow-up things to discuss.
$adminUrl = "https://tenant-admin.sharepoint.com"
$weburl = "https://tenant.sharepoint.com/sites/Test-Modern-Group"

Connect-PnPOnline -Url $adminurl
$site = Get-PnPTenantSite -Detailed -Url $weburl
if ($site.DenyAddAndCustomizePages -ne "Disabled") {
	Write-Host "Disabling customize pages"
	$site.DenyAddAndCustomizePages = "Disabled"
	$site.Update()
	$site.Context.ExecuteQuery()
}

## Update property bag value
Connect-PnPOnline -Url $weburl
$customizeValue=Get-PnPTenantSite -Detailed -Url $weburl | select DenyAddAndCustomizePages
$currentValue=Get-PnPPropertyBag -Key "SiteType"
$currentSearchValue = (Get-PnPPropertyBag | select key,value |where {$_.Key -eq "vti_searchversion"}).Value
Write-Host "Site URL - " (Get-PnPSite).Url

Write-Host "DenyAddAndCustomizePages - $($customizeValue.DenyAddAndCustomizePages)"
Write-Host "Search - $currentSearchValue"
Write-Host "siteType - $currentValue"
Set-PnPPropertyBagValue -Key "SiteType" -Value "Group" -Indexed

# To Enable noscript again - Notice that we need to reconnect,
# since currently context is pointing to actual site, not admin site
Connect-PnPOnline -Url $adminurl
$site = Get-PnPTenantSite -Detailed -Url $weburl
if ($site.DenyAddAndCustomizePages -ne "Enabled") {
	Write-Host "Disabling customize pages"
	$site.DenyAddAndCustomizePages = "Enabled"
	$site.Update()
	$site.Context.ExecuteQuery()
}

I have found the root of the issue…  when I do:
•	Create a group
•	Run the script
•	All is well ....YAY
When I do:
•	Someone else creates a public group
•	Does not add me as a specific member
•	Run the script
•	I cannot update the property bag.
So the question is:
How do I make myself a member of a public group via powershell?
suz

this appears to work now

@VesaJuvonen I am running into 401 unauthorized errors using your above script when executing the Get-PnPTenantSite cmdlet from within an Azure Function. At first I thought this issue spawned from my use of app-only access but I'm seeing the same error passing in -Credentials as well.
Outside of my azure function, the same script executes successfully.
Any idea on what could be causing this? I'm looking to incorporate property-bag updates into a site provisioning solution extending site designs with PnP PowerShell.

Thats correct. You will run the 401 errors because the below lines are not correct.
Connect-PnPOnline -Url $weburl $customizeValue=Get-PnPTenantSite -Detailed -Url $weburl | select DenyAddAndCustomizePages
After connecting PnPOnline for web url you cannot connect to Tenant Site using Get-PnPTenantSite without connecting to admin url again. So you need to move second line to first line to get it work. Here is complete code.
`$adminUrl = "https://tenant-admin.sharepoint.com"
$weburl = "https://tenant.sharepoint.com/sites/Test-Modern-Group"
Connect-PnPOnline -Url $adminurl
$site = Get-PnPTenantSite -Detailed -Url $weburl
if ($site.DenyAddAndCustomizePages -ne "Disabled") {
Write-Host "Disabling customize pages"
$site.DenyAddAndCustomizePages = "Disabled"
$site.Update()
$site.Context.ExecuteQuery()
}
Update property bag value
$customizeValue=Get-PnPTenantSite -Detailed -Url $weburl | select DenyAddAndCustomizePages
Connect-PnPOnline -Url $weburl
$currentValue=Get-PnPPropertyBag -Key "SiteType"
$currentSearchValue = (Get-PnPPropertyBag | select key,value |where {$_.Key -eq "vti_searchversion"}).Value
Write-Host "Site URL - " (Get-PnPSite).Url
Write-Host "DenyAddAndCustomizePages - $($customizeValue.DenyAddAndCustomizePages)"
Write-Host "Search - $currentSearchValue"
Write-Host "siteType - $currentValue"
Set-PnPPropertyBagValue -Key "SiteType" -Value "Group" -Indexed
To Enable noscript again - Notice that we need to reconnect,
since currently context is pointing to actual site, not admin site
Connect-PnPOnline -Url $adminurl
$site = Get-PnPTenantSite -Detailed -Url $weburl
if ($site.DenyAddAndCustomizePages -ne "Enabled") {
Write-Host "Disabling customize pages"
$site.DenyAddAndCustomizePages = "Enabled"
$site.Update()
$site.Context.ExecuteQuery()
}`
-Praveen.


Bad response from server: (500 [error,list]) rtorrent

How to solve this problem?I have 5000 torrents in rutorrents...

try increasing php memory limits find the variable memory_limit in  /etc/php5/fpm/php.ini and increase it to 512M then restart php


FR: add custom label to ignore nodes from clab topo definitions

Introduce a custom label to mark nodes in clab topo definitions yaml that should be ignored during visualization.

Use graph-hide: yes label in clab topology definition YAML like the following:
    graphite:
      kind: linux
      image: netreplica/graphite
      labels:
        graph-hide: yes


Adding ProductBotManagement product enablement

Adding ProductBotManagement product enablement.

Check the instructions in TESTING.md in the root of the repository; you'll need to run some commands to generate fixtures that represent API interactions.

@kpfleming The tests are passing now.

Thanks! I'll get a release made today.


Update Graph Info Every 5min

Every 5 minutes, the following code should be executed:
loadedStuff = false;
m.redraw()

Probably in a timeout instead of an interval, though if it is an interval, it should be outside of the class' code.

Also, supposedly init() shouldn't be called again when doing a m.redraw(), so maybe I should create something that will work in all cases... :/


error[E0786]: found invalid metadata files for crate when building a rust host application (extism 0.2.0)

Hello, I get this after running cargo run:
   Compiling log4rs v1.2.0
   Compiling wiggle v4.0.0
error[E0786]: found invalid metadata files for crate `file_per_thread_logger` which `wasmtime` depends on
  --> /home/ubuntu/.cargo/registry/src/github.com-1ecc6299db9ec823/wiggle-4.0.0/src/lib.rs:36:13
   |
36 |     pub use wasmtime::*;
   |             ^^^^^^^^
   |
   = note: failed to open rmeta metadata: '/home/ubuntu/samples/extism-xp/demo/target/debug/deps/libfile_per_thread_logger-81223c493d0f04ac.rmeta'
   = note: failed to open file '/home/ubuntu/samples/extism-xp/demo/target/debug/deps/libfile_per_thread_logger-81223c493d0f04ac.rlib': Operation not permitted (os error 1)

error: error writing dependencies to `/home/ubuntu/samples/extism-xp/demo/target/debug/deps/wiggle-c1426c5fb8af1d0f.d`: Operation not permitted (os error 1)

For more information about this error, try `rustc --explain E0786`.
error: could not compile `wiggle` due to 2 previous errors
warning: build failed, waiting for other jobs to finish...

Hey @k33g, can you post your rustc version?

Also can you specify what the project is? Is it a rust project using the rust SDK? running cargo run from where exactly?

👋 Hello @bhelx

rustc 1.66.1 (90743e729 2023-01-10)
I use the Rust Host SDK with the sample of the doc https://extism.org/docs/integrate-into-your-codebase/rust-host-sdk

.
├── demo
│  ├── Cargo.lock
│  ├── Cargo.toml
│  ├── code.wasm
│  ├── src
│  │  └── main.rs
│  └── target

I run cargo run from the root of demo (cd demo; cargo run)

@k33g - I have a feeling this is likely due to some lack of architecture support for your VM within the wiggle crate, or one of its dependencies.
If you could, try to reduce the issue by creating a very simple project using wiggle alone:
cargo new issue-reduction
cd issue-reduction
cargo add wiggle
cargo build

If the same error message appears, we may need to take this to the wiggle authors, which happen to be the wasmtime team.

yeah I can't seem to reproduce. On M1 (arm) Mac:
cargo new demo --bin
cd demo
echo 'extism = { git = "https://github.com/extism/extism.git", version = "0.2.0" }' >> Cargo.toml
cargo build # runs fine

Do you need to pull it from git? Why not get it from the crates.io. Change your Cargo.toml:
-extism = { git = "https://github.com/extism/extism.git", version = "0.2.0" }
+extism = "0.2.0"

That might unblock you if you are stuck.

@nilslice @bhelx, the build was ok - I will re-create a VM and do all tests from the beginning

I did the same test with a new VM, more logs:
    Blocking waiting for file lock on build directory
   Compiling extism-runtime v0.2.0
   Compiling extism v0.2.0
error[E0786]: found invalid metadata files for crate `crypto_common` which `extism_runtime` depends on
 --> /home/ubuntu/.cargo/registry/src/github.com-1ecc6299db9ec823/extism-0.2.0/src/lib.rs:2:9
  |
2 | pub use extism_runtime::{
  |         ^^^^^^^^^^^^^^
  |
  = note: failed to open rmeta metadata: '/home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libcrypto_common-f8cde36a6dd62a42.rmeta'
  = note: failed to open file '/home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libcrypto_common-f8cde36a6dd62a42.rlib': Operation not permitted (os error 1)
  = note: failed to open rmeta metadata: '/home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libcrypto_common-9876bd7ced42c215.rmeta'

error[E0786]: found invalid metadata files for crate `digest` which `extism_runtime` depends on
 --> /home/ubuntu/.cargo/registry/src/github.com-1ecc6299db9ec823/extism-0.2.0/src/lib.rs:2:9
  |
2 | pub use extism_runtime::{
  |         ^^^^^^^^^^^^^^
  |
  = note: failed to open rmeta metadata: '/home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libdigest-3c74de6b03f8bfb7.rmeta'
  = note: failed to open file '/home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libdigest-3c74de6b03f8bfb7.rlib': Operation not permitted (os error 1)
  = note: failed to open rmeta metadata: '/home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libdigest-3c7a59f6be345859.rmeta'

error[E0786]: found invalid metadata files for crate `sha2` which `extism_runtime` depends on
 --> /home/ubuntu/.cargo/registry/src/github.com-1ecc6299db9ec823/extism-0.2.0/src/lib.rs:2:9
  |
2 | pub use extism_runtime::{
  |         ^^^^^^^^^^^^^^
  |
  = note: failed to open rmeta metadata: '/home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libsha2-0537ce112573444d.rmeta'
  = note: failed to open file '/home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libsha2-0537ce112573444d.rlib': Operation not permitted (os error 1)
  = note: failed to open rmeta metadata: '/home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libsha2-82f7887b1a67d9ca.rmeta'

error[E0786]: found invalid metadata files for crate `digest` which `extism_runtime` depends on
 --> /home/ubuntu/.cargo/registry/src/github.com-1ecc6299db9ec823/extism-0.2.0/src/context.rs:3:63
  |
3 | pub struct Context(pub(crate) std::sync::Arc<std::sync::Mutex<extism_runtime::Context>>);
  |                                                               ^^^^^^^^^^^^^^
  |
  = note: failed to open rmeta metadata: '/home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libdigest-3c74de6b03f8bfb7.rmeta'
  = note: failed to open file '/home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libdigest-3c74de6b03f8bfb7.rlib': Operation not permitted (os error 1)
  = note: failed to open rmeta metadata: '/home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libdigest-3c7a59f6be345859.rmeta'

error[E0786]: found invalid metadata files for crate `digest` which `extism_runtime` depends on
  --> /home/ubuntu/.cargo/registry/src/github.com-1ecc6299db9ec823/extism-0.2.0/src/context.rs:15:13
   |
15 |             extism_runtime::Context::new(),
   |             ^^^^^^^^^^^^^^
   |
   = note: failed to open rmeta metadata: '/home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libdigest-3c74de6b03f8bfb7.rmeta'
   = note: failed to open file '/home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libdigest-3c74de6b03f8bfb7.rlib': Operation not permitted (os error 1)
   = note: failed to open rmeta metadata: '/home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libdigest-3c7a59f6be345859.rmeta'

error[E0786]: found invalid metadata files for crate `digest` which `extism_runtime` depends on
  --> /home/ubuntu/.cargo/registry/src/github.com-1ecc6299db9ec823/extism-0.2.0/src/context.rs:24:56
   |
24 |     pub(crate) fn lock(&self) -> std::sync::MutexGuard<extism_runtime::Context> {
   |                                                        ^^^^^^^^^^^^^^
   |
   = note: failed to open rmeta metadata: '/home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libdigest-3c74de6b03f8bfb7.rmeta'
   = note: failed to open file '/home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libdigest-3c74de6b03f8bfb7.rlib': Operation not permitted (os error 1)
   = note: failed to open rmeta metadata: '/home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libdigest-3c7a59f6be345859.rmeta'

error[E0786]: found invalid metadata files for crate `digest` which `extism_runtime` depends on
 --> /home/ubuntu/.cargo/registry/src/github.com-1ecc6299db9ec823/extism-0.2.0/src/plugin.rs:5:9
  |
5 |     id: extism_runtime::PluginIndex,
  |         ^^^^^^^^^^^^^^
  |
  = note: failed to open rmeta metadata: '/home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libdigest-3c74de6b03f8bfb7.rmeta'
  = note: failed to open file '/home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libdigest-3c74de6b03f8bfb7.rlib': Operation not permitted (os error 1)
  = note: failed to open rmeta metadata: '/home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libdigest-3c7a59f6be345859.rmeta'

error[E0460]: found possibly newer version of crate `digest` which `extism_runtime` depends on
  --> /home/ubuntu/.cargo/registry/src/github.com-1ecc6299db9ec823/extism-0.2.0/src/plugin.rs:26:49
   |
26 |         functions: impl IntoIterator<Item = &'a extism_runtime::Function>,
   |                                                 ^^^^^^^^^^^^^^
   |
   = note: perhaps that crate needs to be recompiled?
   = note: the following crate versions were found:
           crate `digest`: /home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libdigest-3c7a59f6be345859.rmeta
           crate `extism_runtime`: /home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/libextism_runtime-2be858830823a3f7.rmeta

error: could not write output to /home/ubuntu/samples/rust-experiments/hello-world/target/debug/deps/extism_runtime-2be858830823a3f7.extism_runtime.e0d3a70c-cgu.2.rcgu.o: Operation not permitted

error: could not compile `extism-runtime` due to previous error
warning: build failed, waiting for other jobs to finish...
For more information about this error, try `rustc --explain E0786`.
error: could not compile `extism` due to 8 previous errors

I will try to do the same on a PI4 (8Go RAM)

@k33g i'm gonna assume you got this working because we watching your demo live at Wasm I/O :)
feel free to open it up again if you are stuck though. Be sure to upgrade to 0.4.0 while you are at it.

@liudonghua123 - what version of Extism are you running, and can you share a bit about your environment / OS / architecture?

@liudonghua123 - what version of Extism are you running, and can you share a bit about your environment / OS / architecture?

I'm not running Extism, I encountered the similar error when building a tauri demo app.


Removed engine requirements

Our pipeline uses node 16. This engine requirement broke our build. Removing this engine requirement because the packages that changed in release 1.6.0 doesn't seem to require node 18. The README also says that this package supports node v12+. That's no longer the case with the 1.6.0 update.
If this engine requirement is still necessary, I recommend that we revert the 1.6.0 changes and then upgrade the major version of this package instead. The engine requirement is a breaking change.

Thanks for fix this :) :+1:

Thank you very much for your contribution. Since Node v16 reached end of life on 11/09/2013 (see https://nodejs.dev/en/about/releases/), I will no longer support it.
I would ask you to upgrade to Node v18 or use another package.

Hey @joelvoss if that's the case, then I recommend that this node engine requirement should be a major version update (2.0.0) rather than a minor version update since it's a breaking change.
For those having issues with this recent Node v18 update, there are two things that can fix this.
If you're using this package as an indirect dependency (it is used as a subdependency in any level) , you can use dependency resolutions to fix this. https://classic.yarnpkg.com/lang/en/docs/selective-version-resolutions/. Please add the following to your package.json file:
"resolutions": {
  "plimit-lit": "1.5.0",
  "queue-lit": "1.5.0"
}

If you're a direct dependency, you can fix this by using the exact version of 1.5.0.

I've published v1.6.1 setting the required node version to 12 (this should fix your pipeline).
In addition I re-published the package as v2.0.0 requiring Node v18.

Thanks. I think you would need to do the same with queue-lit because queue-lit enforces node v18 - which breaks the build

Thanks. I think you would need to do the same with queue-lit because queue-lit enforces node v18 - which breaks the build

Ah yes. Have done it there, too.
To be honest, I wasn't expecting anyone besides myself to use this package. But now I know 👍

Lol that's what happens when you publish stuff in NPM registry. I only encountered this issue because one of our dependencies uses your stuff as a dependency. Thanks for fixing this

Yep. It was problem with versioning.some codebasses can not update to v18 currently (because other deps :) ). It's nice to build 1.6.1 with old node, because of ^ mark in tsc-alias package.json and other deps are downloading current version. Thanks


perfect-hash: init at 0.4.1

Description:
Generate a minimal perfect hash function for a given set of keys. A
given code template is filled with parameters, such that the output
is code which implements the hash function. Templates can easily be
constructed for any programming language.

Things done

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

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

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

Result of nixpkgs-review pr 97823 run on x86_64-linux 1

1 package built:

perfect-hash

@SuperSandro2000 Applied.

Result of nixpkgs-review pr 97823 run on x86_64-linux 1

1 package built:

perfect-hash

Result of nixpkgs-review pr 97823 run on x86_64-darwin 1

1 package built:

perfect-hash


Configure Azure Pipelines

This pipeline configuration builds the application and produces a build for the Release configuration.

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


add some seccomp knobs

In particular,

make the default seccomp config optional
add a knob to block x32 syscalls on amd64 (enabled by default)
add a way for users to inject their own seccomp stuff

Signed-off-by: Tycho Andersen<EMAIL_ADDRESS>

Ok, how about:
security.syscalls.blacklist_default => defaults to true
security.syscalls.blacklist_compat => defaults to true
security.syscalls.blacklist => a '\n' separated list of syscalls to blacklist
security.syscalls.whitelist => a '\n' separated list of syscalls to whitelist (mutually exclusive with any security.syscalls.blacklist* option)
raw.seccomp => a custom seccomp policy that is mutually exclusive with any of security.syscalls.* being set (i.e. it is not append like raw.lxc or raw.apparmor, but is a replace operation)

I'll also change the default reply to ENOSYS instead of EPERM, in hopes that more software will DTRT when it gets ENOSYS. We could have knob to change what the default reply is, but I think at that point people probably just want to write their own policy.

Hmm, so I'm not sure that setting blacklist_compat to true by default is a good idea. That's going to break all existing users of 32bit code (such as multiarch or random static binaries) inside 64bit containers.
It will also break nesting 32bit containers inside 64bit ones.
The option is definitely very valuable to reduce the attack surface when you know that your container won't need running 32bit code on 64bit, but I don't think we can do it by default.

On Tue, May 24, 2016 at 08:43:02AM -0700, Stéphane Graber wrote:

Hmm, so I'm not sure that setting blacklist_compat to true by default is a good idea. That's going to break all existing users of 32bit code (such as multiarch or random static binaries) inside 64bit containers.
It will also break nesting 32bit containers inside 64bit ones.

Are these common use cases? I don't really mind either way, but I
didn't figure most people were really using 32bit compat stuff.

The option is definitely very valuable to reduce the attack surface when you know that your container won't need running 32bit code on 64bit, but I don't think we can do it by default.

Cool. Do the names seem reasonable? If so, I'll go ahead and rework
the implementation.

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/lxc/lxd/pull/2041#issuecomment-221313293

I'm not sure how common the nesting case is but it'd definitely affect the demo service for example and anyone else using LXD for a VPS like environment where the user can assume to have a normal Linux environment.
The multi-arch case is rather common. Ubuntu comes with the 32bit archive enabled on 64bit systems by default and it's very common for out of archive packages to be 32bit only and rely on multiarch.
I think the names are fine. blacklist_default isn't particularly clear as to what it blocks but I guess it's kinda the point. The actual list may evolve so we probably can't just call it blacklist_unsafe (as they're not actually reported unsafe, they just might be) or blacklist_legacy (as they may not all be legacy).

On Tue, May 24, 2016 at 08:47:55AM -0700, Stéphane Graber wrote:

I'm not sure how common the nesting case is but it'd definitely affect the demo service for example and anyone else using LXD for a VPS like environment where the user can assume to have a normal Linux environment.
The multi-arch case is rather common. Ubuntu comes with the 32bit archive enabled on 64bit systems by default and it's very common for out of archive packages to be 32bit only and rely on multiarch.

Sure, although I wonder how many people are actually using multiarch.
Anyway, I don't mind defaulting it to off. We can always set it to
default-on later. Or perhaps this is an "ultra secure" mode for one of
the profiles we need to design.

I think the names are fine. blacklist_default isn't particularly clear as to what it blocks but I guess it's kinda the point. The actual list may evolve so we probably can't just call it blacklist_unsafe (as they're not actually reported unsafe, they just might be) or blacklist_legacy (as they may not all be legacy).

Ok, sounds good. I'll rework it.

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/lxc/lxd/pull/2041#issuecomment-221314936

Quoting Tycho Andersen (notifications@github.com):

Ok, how about:
security.syscalls.blacklist_default => defaults to true
security.syscalls.blacklist_compat => defaults to true

one more thing here - Kees has pointed out repeatedly that blacklisting
is far less safe in the long run than whitelisting.  So I wonder if
we should consider whitelisting by default.  This would be more work on
our part, requiring a per-architecture list to be maintained.  But might
be worthwhile.

On Tue, May 24, 2016 at 09:41:44AM -0700, Serge Hallyn wrote:

Quoting Tycho Andersen (notifications@github.com):

Ok, how about:
security.syscalls.blacklist_default => defaults to true
security.syscalls.blacklist_compat => defaults to true

one more thing here - Kees has pointed out repeatedly that blacklisting
is far less safe in the long run than whitelisting.  So I wonder if
we should consider whitelisting by default.  This would be more work on
our part, requiring a per-architecture list to be maintained.  But might
be worthwhile.

Yes, I'll punt on this for now though :)

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/lxc/lxd/pull/2041#issuecomment-221331379

go fmt please

So how does the 32bit on 64bit magic work on other arches?

If the arch for the directives doesn't match the host arch, the directives are ignored, so everything works just fine. However, liblxc does still install the policy, even if it is empty, so I'll send a patch to have LXD not even invoke the compat bits when not on amd64. Also, perhaps we can reject setting the compat bit when not on amd64 too, I'll have a look.

As this is a new feature which won't work with older LXD, we need to add an API extension flag for this.
We can call it "syscalls_filtering" or something like that.

On Tue, May 31, 2016 at 12:42:42PM -0700, Stéphane Graber wrote:

As this is a new feature which won't work with older LXD, we need to add an API extension flag for this.
We can call it "syscalls_filtering" or something like that.

Ok, I've just added the api extension. However, do we really need it?
A LXD which doesn't support these configuration keys will simply
reject them, indicating that the server doesn't support it.

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/lxc/lxd/pull/2041#issuecomment-222797910

@tych0 we won't check it ourselves in our client, but it is a useful thing for other clients to know about.
I'm basically treating any new configuration option exposed over the API, any new keyword in one of the existing API endpoints or any new endpoint as an extension of the original LXD 2.0 API.

Which reminds me, I think I let one slip (some storage zfs option), I'll send a branch that adds an API extension for this.

I think we'll want to better document when config keys are added and what API extension they relate to in the documentation, but I'll figure out the format and send a branch for that myself.