Improve zh-Hant translation

Resolved / Related Issues
Items resolved / related issues by this PR.

None (Sorry I know that it's written in Contributing guidelines; however, translations seem not really required that?)

Details of Changes

Un-translated "Bundles" widget in order to differentiate from "favorites".
Assumed the "Empty Recycle Bin" of No. 835 meant to empty it rather than meant it's an empty one.
Fixed some mistakes.
Made some of them more readable.

Validation
How did you test these changes?

[ ] Built and ran the app
[ ] Tested the changes for accessibility

Screenshots (optional)
(None)

None (Sorry I know that it's written in Contributing guidelines; however, translations seem not really required that?)

@timsu92 translations are fine.


Patch for avoiding maximum recursion error in Python

With the current issue of order of operations causing a maximum recursion error, this PR will re-order the states enough to ensure proper installation of all packages and successful execution of each state.

No longer valid, all changes captured in next branch.


v-model with custom element that wrap checkbox.

Hi,
I am using vuejs 2.0.1 and I want to create a component that looks like this:
    <vue-checkbox v-model="page.ads_able"></vue-checkbox>

As from the api page that v-model is a syntactic sugar combinding :value and @input.
So I write a template with a props name value and a method for input event like this:
...
<input type="checkbox" :value="value" @input="onInput" />
...

...
props: {
        value: {},
},
methods: {
        onInput(event) {
            this.$emit('input', event.target.value)
        }
}
...

But it doesn't work. I don't know if there any special care about checked attribute of the checkbox. I tried the exact same thing with <select> and it's worked as aspect though. Any suggestion?

Well, I think I find a solution to my own question.
I need set a data to accept value from props and change that data at the corresponding event. Something along these lines:
template
<input type="checkbox"
           value="1"
           :checked="checked"
           @change="change"
    />

And in javascript:
      data: function() {
            return {
                checked: this.value
            };
        },
        props: ['value'],

       methods: {
            change: function() {
                this.checked = !this.checked;
                this.$emit('input', this.checked);
            }
       }

That's work now. :D

@phatchai Here is a work around for the issue.
https://jsfiddle.net/cv2tL9oy/

Issues are for bugs and feature requests only. Please use forum.vuejs.org or Gitter.

@phatchai Your example works not correctly. When we change parent model - yours checkbox component wouldn't change.
We need to take checked from props and emit event 'input' onChange, and don't store local state.
Here is my example:
<template>
    <input type="checkbox" :checked="value" @change="changeHandler">
</template>

<script>
export default {
    name: 'v-switch',
    props: ['value'],
    methods: {
        changeHandler () {
            this.$emit('input', !this.value)
        }
    }
}
</script>

There needs to be better documentation on v-model. Everywhere I look says it's just a shorthand for :input="$emit('input', event.target.value)" but this issue proves otherwise. The bug here is lack of documentation.

@myxibrium solution didn't work to me but this did (changing :value for :checked):
<template>
    <input type="checkbox" :checked="value" @input="$emit('input', $event.target.checked)" />
</template>

<script>
export default {
    props: ['value']
};
</script>

I can also bind a group of checkboxes to an array. The array will then contain a list of the values of the checked checkboxes, see 2nd example in the documentation https://vuejs.org/v2/guide/forms.html#Checkbox
How to wrap a checkbox correctly so that this behavior will also be preserved?

I can also bind a group of checkboxes to an array. The array will then contain a list of the values of the checked checkboxes, see 2nd example in the documentation https://vuejs.org/v2/guide/forms.html#Checkbox
How to wrap a checkbox correctly so that this behavior will also be preserved?

https://vuejs.org/v2/api/#model
Use a custom model prop and event. Eg.
model: {
  prop: 'modelValue',
  event: 'change'
}

Bind the @change to the checkbox and $emit the value differently based on whether the v-model value (this.modelValue) is an array (multiple checkboxes) or not (single checkbox).

@vincesp I managed to solve this by using @rjoo 's answer and a bit of array checking when the box change.
methods: {
    change() {
      const checked = this.checked;
      const found = checked.indexOf(this.value);
      if (found !== -1) {
        checked.splice(found, 1);
      } else {
        checked.push(this.value);
      }
      this.$emit("change", checked);
    }
  }
};

codesandbox here: https://codesandbox.io/s/5x0296z7jp
I didn't put handling of single select boxes in there, but that's fairly trivial to do. Hope it helps.

Don't know about Vue 2 but for Vue 3. it's as simple as this.
props: {
    modelValue: [Boolean, Array]
}

<input
    type="checkbox"
    v-model="modelValue"
    @change="$emit('update:modelValue', modelValue)"
>

Not sure if things have changed since the above was written, but none of the above worked for me.
The Vue docs talk about the need for emits:  https://vuejs.org/guide/components/events.html#usage-with-v-model
So I added it in, and it works. I tweaked their example a bit so that it works for checkbox:
<template>
    <input type="checkbox" :checked="modelValue" @change="$emit('update:modelValue', $event.target.checked)" />
</template>

<script>
  export default {
    props: ['modelValue'],
    emits: ['update:modelValue']
  }
</script>


rust v1.73.0 error on install

error[E0186]: method should_emit_errors has a &mut self declaration in the trait, but not in the impl
--> C:\Users\jax.cargo\registry\src\index.crates.io-6f17d22bba15001f\hyperlink-0.1.31\src\html\parser.rs:264:5
|
264 |     fn should_emit_errors() -> bool {
|     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected &mut self in impl
|
= note: should_emit_errors from trait: fn(&mut Self) -> bool
For more information about this error, try rustc --explain E0186.
error: could not compile hyperlink (bin "hyperlink") due to previous error

is this with cargo install? try cargo install --locked

no response, closing


new release candidate

includes fix for links on Basic Drawer

Fixes https://github.com/OrigenStudio/material-ui-layout/issues/57


Residence Address: Add Homeless

Stacey wants to be able to write "Homeless" on Residence Address. Just typing in "homeless" produces an error - it does not save. However, if Stacey adds Washington, DC, Zip, then it saves. That's inaccurate.
Not sure what the fix is - need to investigate.

Do any of the application pdfs incorporate homelessness?

This seems to save when I try it.  Were you doing something different?

Testing this, I was able to save with Homeless:

However, the Residence title doesn't work unless there is a city added. Would it make sense to validate the street address and display "Homeless" instead of "Residence at"?

Yes, that should be a simple edit for someone to make in the address model.

Hey, I'm working on this in a fork. After I install the pdftk dependency I'll make this edit.
I couldn't recreate the not saving issue, but I'll make the display fix.


Recompute solrbackup's .Status.NextScheduledTime on changes to .Spec.Recurrence.Schedule

Currently, changing the schedule property leaves the "Next Scheduled" time untouched, which causes a delay in when the schedule property is actually able to "take effect".
e.g. Changing Schedule from "@every 1w" to "@every 1d" will increase the frequency, but not until "NextScheduledTime" comes around (which may be up to a week away!).
Exactly how the "Next Scheduled Time" should be recomputed is a good question that I can see arguments on either side of.  e.g. Continuing the example above: should the next backup be one day from the previous backup?  One day from the current time?  Something else?
But regardless of opinions there, any of those options seem preferable to not recomputing NextScheduledTime at all.

Good catch, this was an intentional decision made by myself when implementing. I definitely should have mentioned it in the Issue or PR though, so thanks for bringing this up.
I decided to not recompute this every time, because it seems like a somewhat expensive call (have not tested this, so my fears might be completely unfounded), and if we do support recomputing then we will have to recompute the schedule on every single reconcile loop. So my thought was "at first, just recompute once every time, and don't waste the time".
If the backup had sub-resources we could do fun things like store the last used schedule as an annotation on the sub-resource, and only recompute the next restart time whenever the schedule differs between the SolrBackup spec and the sub-resource annotation. But since the solrbackup resource doesn't manage sub-resources, we would have to store the last used schedule in the annotations of the SolrBackup (which I am not a fan of), or add a field in the SolrBackup.Status, which is an option. Maybe I'm just worrying about nothing and we should always recompute at the start of the reconcile loop.
As for your question about how it should be computed, the clear answer in my mind is to ALWAYS compute based off of the last time a backup was started. Given the Kubernetes APIs, we aren't necessarily given the time when a field has been changed, so that is a rabbit hole of using "current time" (except for the first backup of course).


Function source comparison shows diffs when there are none

System information:

Operating system (distribution) and version: Windows 10
DBeaver version: <IP_ADDRESS>002011957
Java version: 1.8.0_191-b12
Additional extensions: None

Connection specification:

Database name and version: Postgresql
Driver name: PostgreSQL JDBC Driver
Do you use tunnels or proxies (SSH, SOCKS, etc): No

Describe the problem you're observing:
When I compare two identical functions using the Simple Compare tool with the Compare functions/scripts option, it always shows the source as being different.
Steps to reproduce, if exist:

Create a function
Create an identical function with a different name
Select the two functions
Right click and choose Compare/Migrate->Simple Compare
Check Compare scripts/procedures
Run the compare
Compare report will show the source as a mismatch

I attached an example.
Function Compare.docx
Include any warning/errors/backtraces from the logs
There are none.

thanks for the bug report

If functions have different names then these functions are different.
But in your sample they have the same name (probably they are in different database).
But I can't reproduce this bug then.

In the example that I attached I was using two different databases and the same function with the same name.  Updated reproduction steps:

Apply the function below to 2 different databases
Select the two functions
Right click and choose Compare/Migrate->Simple Compare
Check Compare scripts/procedures
Run the compare
Compare report will show the source as a mismatch

CREATE OR REPLACE FUNCTION public.min_uuid(uuid, uuid)
RETURNS uuid
LANGUAGE plpgsql
STABLE
AS $function$
BEGIN
-- if they're both null, return null
IF $2 IS NULL AND $1 IS NULL THEN
RETURN NULL ;
END IF;
-- if just 1 is null, return the other
IF $2 IS NULL THEN
    RETURN $1;
END IF ;
IF $1 IS NULL THEN
    RETURN $2;
  END IF;

-- neither are null, return the smaller one
IF $1 > $2 THEN
    RETURN $2;
END IF;

RETURN $1;

END;
$function$

@theldberg
is it still actual?

there are not any updates on issue. Ticket will be closed.
If issue is still actual for you - feel free to reopen the ticket


Pin pyee (versions newer than 9.0 no longer support python3.5)

Fixes issue https://github.com/balenalabs/balena-cam/issues/99

Wrong branch


Fix error message

Fauled -> Failed

Current coverage is 54.85% (diff: 0.00%)

Merging #1278 into master will increase coverage by 0.07%

@@             master      #1278   diff @@
==========================================
  Files            78         78
  Lines         12428      12428
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           6808       6817     +9
+ Misses         4678       4669     -9
  Partials        942        942

Powered by Codecov. Last update 058bc22...93e1a43

LGTM


Not able to test against 413 PAYLOAD_TOO_LARGE

Because of some reason I'm not able to test against PAYLOAD_TOO_LARGE status code.
No matter how I set limits for request size in Spring, controller method is being called. This is not expected. I would rather expect that my exception handler is being called (which sets 413 status for response and also builds response body).
My tests looks as following:
    @Test
    @DisplayName("Response status is 413 due to payload size exceeding limit")
    void shouldFailOnTooLargePayload() {

      //@formatter:off
      given()
          .mockMvc(mockMvc)
          .multiPart("request", new File("src/test/resources/test-data/simpleRequest.json"), "application/json")
          .multiPart("files[]", new File("src/test/resources/test-data/sample.pdf"), "application/pdf")
          .multiPart("files[]", new File("src/test/resources/test-data/sample.pdf"), "application/pdf")
          .contentType( MediaType.MULTIPART_FORM_DATA_VALUE)
          .headers(headers)
      .when()
          .post("api/send")
      .then()
          .assertThat()
              .statusCode(413);
      //@formatter:on
    }

Spring application-test.yaml (this is being read: "The following profiles are active: test"):
spring:
  servlet:
    multipart:
      enabled: true
      max-file-size: 100KB
      max-request-size: 100KB

sample.pdf is about 420KB big

Exception handler (works just fine with running application, when I call endpoint with too big request I do get 413 error code):
  @ExceptionHandler(MaxUploadSizeExceededException.class)
  @ResponseStatus(value = HttpStatus.PAYLOAD_TOO_LARGE)
  @ResponseBody
  public RestError handleMultipartException(HttpServletRequest request) {

    // code returning RestError
  }

Closing as not related to RESTAssured


Fix firestore adapter reference options order

Fixes #611

@googlebot I signed it!

@googlebot I fixed it.

@jamesdaniels Hi, thank you  for accepting.. Does this mean you plan to continue working on emberfire?

Yes.

Thank you very much. I am working on a project running emberfire@3, I've forked it to fix some bugs, will check if I can contribute some other fixes.

That would be appreciated as I don't think any of us are actively using Ember ATM. So we lack the hands on experience.


Is Propel dead dead now?

Would like to hear about the status of Propel.  We manage a large application that actually still runs on Propel 1.  Preparing the codebase for migration to Propel 2 (or so we thought), has been a slow process of eliminating the PEER classes and organizing our query logic.  That said, we're basically to the point now where we have very few PEER calls in our code and most of our query logic put into a custom repository layer.  We could actually pull off the migration now.
While migrating to Propel 2 probably still makes sense for us, even given that there isn't a stable release and it's been abandoned, looking forward, if and when the time comes for us to actually make a move, that decision path is getting fuzzy.
Propel 1 mostly works, but there are some absolutely crazy gotchas that require some even crazier hacks.
Aside from the question on the status.  I'd like to know if there is a migration path, or migration suggestions/instructions to move from Propel 2 to Propel 3.  Does Propel 3 even work?  Is Propel 3 anymore stable than Propel 2?  Cheers!

@jstrzal it seems so - been nearly a year and a PR hasn't been merged.

Yupp, seems so.


TypeError: formattedExpression.trim is not a function

Hi :wave:
I'm getting this error on all my erb files! Any suggestion?
$ node -v
v12.21.0

$ yarn prettier --check app/**/*.rb
yarn run v1.22.11
Checking formatting...
All matched files use Prettier code style!
✨  Done in 3.01s.

$ yarn prettier --check 'app/**/*.erb'
Checking formatting...
app/views/administrador/_tabla_estudios_contables.html.erb[error] app/views/administrador/_tabla_estudios_contables.html.erb: TypeError: formattedExpression.trim is not a function
[error]     at /Users/pablo/Projects/xxx/node_modules/prettier-plugin-erb/lib/formatter.js:28:46
[error]     at Array.map (<anonymous>)
[error]     at formatMultilineExpressions (/Users/pablo/Projects/xxx/node_modules/prettier-plugin-erb/lib/formatter.js:7:6)
[error]     at Object.print (/Users/pablo/Projects/xxx/node_modules/prettier-plugin-erb/lib/printers.js:22:27)
[error]     at callPluginPrintFunction (/Users/pablo/Projects/xxx/node_modules/prettier/index.js:13787:21)
[error]     at mainPrintInternal (/Users/pablo/Projects/xxx/node_modules/prettier/index.js:13725:17)
[error]     at mainPrint (/Users/pablo/Projects/xxx/node_modules/prettier/index.js:13707:14)
[error]     at printAstToDoc (/Users/pablo/Projects/xxx/node_modules/prettier/index.js:13694:13)
[error]     at coreFormat (/Users/pablo/Projects/xxx/node_modules/prettier/index.js:14055:15)
[error]     at formatWithCursor$1 (/Users/pablo/Projects/xxx/node_modules/prettier/index.js:14284:14)

I'm seeing this too.

Same for me as well

Same here.

Same!

It seems like the issue occurs in combination with the new release of version 2.0.0 of @prettier/plugin-ruby. I downgraded to "@prettier/plugin-ruby": "1.6.1" and formatting is working now again as expected 🚀

It seems like the issue occurs in combination with the new release of version 2.0.0 of @prettier/plugin-ruby. I downgraded to "@prettier/plugin-ruby": "1.6.1" and formatting is working now again as expected 🚀

This didn't work for me. I restarted VS Code and still got the "..trim" error

@akimthedream  Hello, can we please see  your package.json, tried to downgrade  but it wipes out much of the code on save and changes the html tags to  I'm trying to guess which combination we need.
It would be big help! thank you, if you have time.
"devDependencies": {
   "@prettier/plugin-ruby": "1.6.1",
   "prettier": "1.9.0",
   "prettier-plugin-erb": "^0.4.0",
   "webpack-dev-server": "^3"
 }

This combination worked for me -
    "@prettier/plugin-ruby": "1.6.1",
    "prettier": "2.2.0",
    "prettier-plugin-erb": "^0.4.0"

This is all related to #49


Vulnerable components (CVEs) in docker images

According to Docker Store, the latest 9.6.3 has 4 vulnerable components:
In Bash:
CVE-2017-5932
The path autocompletion feature in Bash 4.4 allows local users to gain privileges via a crafted filename starting with a " (double quote) character and a command substitution metacharacter.
CVE-2016-9401
popd in bash might allow local users to bypass the restricted shell and cause a use-after-free via a crafted address.
In pcre:
CVE-2015-3217
PCRE 7.8 and 8.32 through 8.37, and PCRE2 10.10 mishandle group empty matches, which might allow remote attackers to cause a denial of service (stack-based buffer overflow) via a crafted regular expression, as demonstrated by /^(?:(?(1)\.|([^\\W_])?)+)+$/.
CVE-2017-6004
The compile_bracket_matchingpath function in pcre_jit_compile.c in PCRE through 8.x before revision 1680 (e.g., the PHP 7.1.1 bundled version) allows remote attackers to cause a denial of service (out-of-bounds read and application crash) via a crafted regular expression.
In expat:
CVE-2016-6702
A remote code execution vulnerability in libjpeg in Android 4.x before 4.4.4, 5.0.x before 5.0.2, and 5.1.x before 5.1.1 could enable an attacker using a specially crafted file to execute arbitrary code in the context of an unprivileged process. This issue is rated as High due to the possibility of remote code execution in an application that uses libjpeg. Android ID: A-30259087.
In libxml2:
CVE-2016-4448
CVE-2016-9318
CVE-2017-8872
CVE-2015-6838
CVE-2015-6837
CVE-2017-5969
Full details of scan (Requires logging in with your Docker Hub account):
https://store.docker.com/images/postgres/plans/cfa7881b-dad1-4d72-8dca-58b5d15bfc71/scans/library/postgres/9.6.3

We get these reports quite often, and they usually involve a large amount of digging which ends up in very little which is actionable.  See the list below for an example of where I dove into a lot of these reports and found most of them to be either false positives or out of our hands (because Debian upstream hasn't patched the vulnerabilities, usually because they looked into it and deemed it to be a minor issue).
If there are actionable items we can resolve, we're happy to do so (and do so actively). We update all Debian based images to include any updates in apt packages at least monthly (we regenerate the base images and then rebuild all dependent images).

CVE-2017-5932, fixed in the version that is installed, https://security-tracker.debian.org/tracker/CVE-2017-5932
CVE-2016-9401, "[jessie] - bash  (Minor issue)", https://security-tracker.debian.org/tracker/CVE-2016-9401. In other words the Debian Security Team has decided not to port the upstream fixes to the version available in Debian Jessie (RedHat has also not published a fix for bash in RHEL 7).
CVE-2015-3217,  "[jessie] - pcre3  (Minor issue)",, https://security-tracker.debian.org/tracker/CVE-2015-3217 (many of the RedHat packages with this CVE are "will not fix" for RHEL 7)
CVE-2017-6004, fixed in the version that is installed, https://security-tracker.debian.org/tracker/CVE-2017-6004
CVE-2016-6702, not applicable to Debian since it is an Android specific patch, https://security-tracker.debian.org/tracker/CVE-2016-6702
CVE-2016-4448, "Minor impact; too intrusive to backport", https://security-tracker.debian.org/tracker/CVE-2016-4448
CVE-2016-9318,  "[jessie] - libxml2  (Minor issue)", https://security-tracker.debian.org/tracker/CVE-2016-9318
CVE-2017-8872, [jessie] - libxml2  (Minor issue)", https://security-tracker.debian.org/tracker/CVE-2017-8872
CVE-2015-6838, PHP bug not libxml2, https://security-tracker.debian.org/tracker/CVE-2015-6838
CVE-2015-6837, PHP bug not libxml2, https://security-tracker.debian.org/tracker/CVE-2015-6837
CVE-2017-5969, "[jessie] - libxml2  (Minor issue, only a denial-of-service when using recover mode)" https://security-tracker.debian.org/tracker/CVE-2017-5969

Related issues:
https://github.com/docker-library/openjdk/issues/112
https://github.com/docker-library/drupal/issues/84
https://github.com/docker-library/official-images/issues/2740
https://github.com/docker-library/ruby/issues/117
https://github.com/docker-library/ruby/issues/94
https://github.com/docker-library/python/issues/152
https://github.com/docker-library/php/issues/242
https://github.com/docker-library/buildpack-deps/issues/46


Migrate to CircleCI 2.0

This should keep the same functionality, although I did bump node up to the latest LTS build. Closes #37

Codecov Report

Merging #48 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master    #48   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           6      6
  Lines         108    108
  Branches       45     45
=====================================
  Hits          108    108

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 615dbc3...72cdb0c. Read the comment docs.

lgtm thanks a bunch!


Entry CSS integrity issues on CDN

Hi,
We're trying to add a CDN to our project but once this CSS gets served from the CDN we get the following security issue:
Subresource Integrity: The resource 'https://staging-cdn.***********.com/_nuxt/entry.D43X-ZjV.css' has an integrity attribute, but the resource requires the request to be CORS enabled to check the integrity, and it is not. The resource has been blocked because the integrity cannot be enforced.
For some reason, only this single entry.*.css gives the error. And after looking at the page source, it appears as this may be because the link tag for this CSS file doesn't have crossorigin parameter as the rest of the files (?). See screenshot:

Now, I'm not sure if this is the actual cause but was just wondering if there is a reason that this particular CSS link tag doesn't have the crossorigin parameter in it, or if there is any option to enable it.
Thank you, cheers.

Hi @ptdev
You need to have the crossorigin: anonymous value in the tag.
It is normally the case by default with Nuxt though. How did you include this file?

Hi @vejja
Thanks for the quick reply. But I'm not adding this file (or any CSS) manually anywhere.
All I have is some files on the css property inside nuxt.config.ts.
So I'm guessing that entry.*.css is automatically added by nuxt (?)

Ah ok, I think I understand: you are building the website HTML for a given domain, and then manually moving only the CSS and JS files to another CDN, is that right ?
Normally all static assets are supposed to be served from the same origin, otherwise you'll get into crossorigin limitations.
I do believe that Nuxt has a cdnURL option for this though, you should try that.

Hi,
Yes, and we are using app.cdnUrl: 'staging-cdn.ourdomain.com' on nuxt config.
We're not copying any files to the CDN host.
The CDN we're trying (gcore.com) works by having us create a CNAME that is then pointed to their server.
Requests to that CNAME then fetch and cache the files on their CDN.

Ok, very clear.
The issue is not on our end, and I'm not sure where it could come from.
I found this on the Vite repo: https://github.com/vitejs/vite/pull/17930, so apparently something similar was fixed upstream recently and it looks like it was included in the latest Nuxt version.
Which version of Nuxt are you using?

Hi,
We're using the latest nuxt version (v3.13.2).
That issue does indeed appear to be the same or similar to what we're getting.
After having navigated a bit through our site, other CSS files eventually get the same error (so, not just the entry js file as initially reported).
Apparently, when navigating between pages and Nuxt dynamically adds/removes CSS files, then the link tag is added with the crossorigin parameter. (see screenshot)

But when refreshing the browser and loading from the server, Nuxt adds the CSS link tags without crossorigin, which I assume is what is causing this issue with CDNs. (see screenshot)

We removed our lockfile and reinstalled all dependencies to see if vite somehow got updated, but we still get the same issue, even with all latest packages.

Hi again,
Was looking further into this and it appears as it will definitely most likely be a nuxt or vite issue.
I've opened an issue on Nuxt's repo with a better repro link and description of the issue.
Closing here, thanks for the hints 👍

Thanks once again @vejja for jumping into this 💚

FYI @ptdev - I could reproduce and confirm the issue. The upgrade to Vite 5.4.7 does not solve the problem.
As far as providing an immediate workaround, I can only see 2 options:
1- Not using your CDN subdomain for static assets. Serving everything from the same origin will solve the CORS issue.
2- Not using the Subresource Integrity feature of Nuxt Security, by disabling it with { security: { sri: false } }

Ooops sorry @danielroe, talked too fast here. Unless I'm missing something I believe that :

We have crossorigin set for <link rel="prefetch", as="style">
But we are still missing crossorigin for <link rel="stylesheet">

There is one more place we need to update it...

See https://github.com/nuxt/nuxt/pull/29138. I'd appreciate if you have a look in the rest of the renderer file to see if there are other places we should be adding crossorigin attributes.

See nuxt/nuxt#29138. I'd appreciate if you have a look in the rest of the renderer file to see if there are other places we should be adding crossorigin attributes.

From a security perspective, subresource integrity hashes are only valid

on <script> tags with have a src attribute
and on <link> tags with rel being either stylesheet, preload or modulepreload

The W3C RFC provides that other tags may be added to the list in the future, but it is not part of the standard currently so we only add the integrity attribute on the elements listed above.

@danielroe : To be clear I believe it's only on <link rel="stylesheet"> that we would need it. See screenshot below after the vue-bundle-renderer hotfix:

Hi,
Thanks for the updates but the issue still appears to remain the same on my end. 😞
I forked the original reproduction that was posted on the issue at Nuxt's repo:
https://stackblitz.com/edit/nuxt-starter-d6e555?file=README.txt
Ran npx nuxi upgrade as suggested but when loading a page directly from the server the CSS links still do not have the crossorigin attribute.
See screenshot:

Only when navigating from another page, the crossorigin attribute is correctly defined.

Yes, you'll need to wait for https://github.com/nuxt/nuxt/pull/29138 to be released first 🙏

Daniel, not sure if feasible but if yes - would you mind backporting it to 3.14 ?

for sure! I'm backporting all non-breaking changes (features as well as bugfixes)

Hi @vejja
Yes, we've updated to 3.14 and can confirm that we can now use a CDN through the cdnUrl parameter without any issues.
Thanks for everything, cheers! 👍


[BUG] The Host field is set incorrectly when the upstream is nginx.

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
When the reverse proxy upstream is NGINX's service, all request headers will be sent upstream as they are, while the Host request header is special, which will lead to 403 if it is incorrect.
For example, the proxy http://www.weather.com.cn/, if the Host field is passed as the request Host of the gateway, the server returns 403, and the value of Host that should be passed is www.weather.com.cn.
If this is a bug, please assign it to me and I'll fix it.
Expected Behavior
Host field is www.weather.com.cn
Steps To Reproduce

Reverse proxy www.weather.com.cn
Access
result 403

Environment
ShenYu version(s): Latest

Debug logs
No response
Anything else?
No response

I got the same problem. But fixed it with " httpProcess->request " plugin, add correct "host" header.

I got the same problem. But fixed it with " httpProcess->request " plugin, add correct "host" header.

Yes. It can be solved by doing so, but it should be a defect.

I found this commit.

@yu199195 Hi. Please confirm, Will this change bring about this problem?

@iwangjie  maybe should fix it

@iwangjie maybe should fix it

ok. I'll submit a PR later.


chore(demos): use full polyfills

Short description of what this resolves:
We should use our full polyfills instead of just the ng polyfills for browsers like edge and safari. With just the ng polyfills edge breaks on the demos because it does not support the closest dom method.
Changes proposed in this pull request:

use full polyfills instead of just ng polyfills

Ionic Version: 2.x
Fixes: #9861

Merged into treeshaking branch.
https://github.com/driftyco/ionic/commit/784f0c2b57d3d65ca028be4f276db94d14ebb79f


CPU-GPU copies instead of GPU-GPU MPI communications in cg_mpi ?

Hello,
I am using the cg_mpi.ccp sample from rocALUTION to test GPU-GPU MPI communications.
When running cg_mpi with 2 MPI tasks and 1 GPU per task on a AMD MI250X node (with Trento CPU) I can see 2 arrays transfered from GPU to CPU (green) and back (purple) for each solver iteration step (see rocprof profiling below). Note that I modified the source code with ls.InitMinIter(10);.

By exporting ROCALUTION_LAYER=1, I can see that the data sizes correspond to the ghost cells. I assume that an MPI communication is then done to update gost cell values.
I was expecting to avoid this GPU-CPU ping pong since the MI250X node has everything needed (hardware + software stacks) to perform GPU to GPU MPI communications. Does rocALUTION MPI calls support GPU device addresses ? Or am I missing something here ?
The same pattern is observed on our application and we would like to understand (and if possible avoid) these costly data exchange.
Feel free to ask me any details if needed.
Thank you in advance.

Currently, rocALUTION does not support direct GPU-GPU communication. This is something we will be adding in a future release, however.

Thanks for you quick answer.
Do you have an idea of when this feature will be supported ?

I am not able to give you a specific release. May I ask why you are interested in such feature? I do not expect any performance improvement on most solvers, as time critical algorithms such as SpMV can fully hide communication by computation.

I understand your point but the bench case we are working on shows that about 10% of the time of each rocALUTION solver call (1 per time step) is dedicated to hipMemcpy for these ghost cells exchange, with almost no computational kernels overlap. We use the CG solver with the c-amg preconditionner. It would have been nice to try this feature on AMD nodes specifically designed to do so. We will test it when it will be available :).

There is going to be a change soon, which will introduce multiple streams in order to overlap packing and sending with the interior computation. If you are using MPI, I guess you compile from source. I'll update this issue, once that change has been implemented, so you can re do your performance tests.

Sounds a good feature to try, thanks !

I have merged some major modifications to GlobalMatrix::Apply() in order to overlap communication and packing with interior matrix vector multiplication. This should slightly improve SpMV performance and scale linear with additional nodes / GPUs. Let me know, if this fixes the issue you have been observing.
Note, that you will have to checkout develop branch, in order to see those changes.


Coda Daemon is crashed

The following command is used to run one snark worker:
coda daemon  -peer filet-mignon.o1test.net:8303 -run-snark-worker tNci4dpqGY9UsWrCNPJEua6FdGyk2KFqBC8ovC5EdGZ8gUiVQcKw8tdVEBma86yGiXY4gDFdwHJSJuCnzn4ZyH9CEuz8FoGnRgpzUj5UVjMR62GDB2UJNo1B5qC2gLZKK4bXRc9XU1wkqT -snark-worker-fee 1
And the crash log is attached.
coda_crash_report_2019-09-27_03-08-11.384908.tar.gz

I just followed the link to launch the testnet:
https://codaprotocol.com/docs/getting-started/
My cloud machine configuration is:
CPU - 4 core, 2.5G
Memeory - 8G

Thanks @StarLI-Trapdoor we're looking into this issue!

Closing this issue as it is stale for a long time.


Bump minio-go v<IP_ADDRESS> to latest

minio-go v<IP_ADDRESS> has a known bug https://github.com/minio/minio-go/issues/1681/ which we run into and that causes unnecessary restarts to our thanos store pods.
I think we should update it to <IP_ADDRESS> or greater.

cc @SuperQ


Avoid creation of array in Info::SchemaCompiler.visit_set

The goal of visit_set is visit the nodes using their target, but while it does it also creates an array is not used on the method.

Thanks!


devicetree: gen_defines: Generate label to node name mappings

DT_NODE_NAME macro has been added that allows mapping of node label.
Supporting code, generating the mapping, has been added to
gen_defines.py.
Signed-off-by: Dominik Ermel<EMAIL_ADDRESS>
[ ] tests

Purpose of this commit is to allow using node labels to get node names, for example to get access to identifiers that have been generated with node names in path, but for some reason user wants to use label.

@galak the ultimate goal is https://github.com/zephyrproject-rtos/zephyr/pull/24522

What is the actual use you have in mind for this?

For example I generate list of subnodes for path pointing to "fixed-partitions" compatible, e.g
#define PARTITIONS partition_0, partition_8000, etc.

For these partitions that are given labels, e.g boot_partition is partition_0 I can use DT_NODE_NAME(boot_partition) to get the partition_0 when generating path to property.
Or in my case, as @mbolivar-nordic has noted, to use labels to name partitions I want to access in code.


Sum of the Array in Java

Write a program to calculate the total Sum of the Array in Java

I will do this please assign me @Zohaib-Sathio

I will do this please assign me @Zohaib-Sathio

Assigned.

i will be able to do please assign me this @Zohaib-Sathio

assign this to me

Please assign me this issue

hi @Zohaib-Sathio can you assign me this

I am interested in this work.
Please assign it to me.


New marker types - ring, kite, scalene

Pull Request
Hi,
Thanks for helping us improve the Predix UI platform by submitting a Pull Request.
To help us merge your Pull Request as fast as possible, please fill out the following sections:

A description of the changes proposed in the pull request:

A reference to a related issue (if applicable):

@mentions of the person or team responsible for reviewing proposed changes:

working tests:

The tests need to be functional and/or unit tests, written for the wct framework, and placed in the test folder, following our testing guidelines.

thanks, @benoitjchevalier !  Good to know about the debugger version - wasn't aware of that previously!


[Q] Macro/VBAScript injection in a new Excel file

💬 Questions and Help
Hello, I'm looking into creating a custom excel file that incorporates VBAScripts for data validation.
My use case includes creating a template VBA Script and updating the variables inside that script so that they can be used as a dropdown list in an excel cell.
If Exceljs doesn't support this, suggestions and approaches to this problem are welcome !
Cheers.

+1 - I would also love to be able to add VBA code to the Excel file. Ultimately my team would like to have a dropdown where we can select multiple values from the list and this can be achieved via VBA.

@buckwheat24 we ended up using data validation formulaes that are available in this library, using multiple hidden sheets that contain the dropdown list data.

This works but I'm trying to make the dropdowns dynamic, so based on the value of one dropdown, we display other dropdowns. anyway to achieve this?

For me, I used the INDIRECT formula with defined names to achieve cascading dropdown

@radiumrasheed We used a combination of INDEX and MATCH to achieve the same result :) cheers, although it would've been nice to get the support for macros ! 😅


Checking bullets when used with LCAmmoCheck will make the gun invisible

Describe the bug
Checking bullets when used with LCAmmoCheck will make the gun invisible
Reproducible Test
I tried to lower the versions of these two MODs, but the result remained the same
Anything else?
No response

By the way, I have no problem using LCAmmoCheck OLD

If you delete BetterShotgun, will AmmoCheckAnimation_OLD work fine? And did you disable AmmoCheckAnimation in the config?

This problem is related to the LCAmmoCheck mod, not BetterShotgun


config: add StopSignal

Close #541
@stevvooe @vbatts PTAL I probably forgot something
Signed-off-by: Antonio Murdaca<EMAIL_ADDRESS>

LGTM
I am not sure if we should add StopTimeout, as well. StopSignal is fairly portable, but the timeout can be deployment specific.

On Mon, Jan 30, 2017 at 12:26:08PM -0800, Antonio Murdaca wrote:

M config.md (4)
M specs-go/v1/config.go (3)

This also needs a JSON Schema change and fs.go rebuild, although that
can happen as a follow-up PR if folks prefer.
I'd rather address this with an annotation 1, because then we don't
have to add property-specific documentation for how this should be
translated into the runtime config (in flight as #492).  But
documenting translation for another property isn't that hard, so it's
not a big deal either way.

Updated schema-fs as well

I am not sure if we should add StopTimeout, as well. StopSignal is fairly portable, but the timeout can be deployment specific.

what exactly are the criteria here? this seems a bit loose; I thought we were going from a versioned docker config type?

@runcom can you please list the valid strings in this field? And ideally write a test case?

@philips sure

@jonboulle Portability is just a measure of whether config is made with respect to the internals of the image or the host environment. Specifying the stop signal for a process is going to operate regardless of host machine (on the same os), whereas stop timeout may be very specific to how a machine is configured or what it is running. From a docker perspective, stop timeout exists in the image config, but there could be an argument that this is host specific, hence not included here automatically. Granted, I am favoring caution here, as it is easy to add but impossible to remove.
It would be good for someone else to lodge an informed opinion here.

@philips updated

@stevvooe sorry, my question was imprecise - I meant criteria with respect to what fields we add to this config object. e.g. I thought this was basically https://github.com/docker/docker/blob/master/image/spec/v1.md#image-json-description , except now we're extending beyond that.

god i hate this schema/fs.go file. It causes senseless number of rebases. :frowning_face:
Can you rebase please?

@vbatts done!

LGTM

@runcom Please rebase!

@stevvooe done

I still feel we shouldn't allow numbers unless there is a really good reason.

I still feel we shouldn't allow numbers unless there is a really good reason.

@runcom Is this easy to do? If not, let me know and we can merge this and open an issue.

@runcom Is this easy to do? If not, let me know and we can merge this and open an issue.

I think it's fine, this is the spec and it's just wording afaict. I can drop the number stuff in the stop signal paragraph I guess.

@philips @stevvooe updated

BTW, this is the original conversation when stopsignal was added in docker https://github.com/docker/docker/pull/15307#issuecomment-128387259 and Dan raised the issue that matching syscall names against a table is often outdated. Not sure that's a real argument though, but still, something to consider when deciding to use numbers as well.

BTW, this is the original conversation when stopsignal was added in docker docker/docker#15307 (comment) and Dan raised the issue that matching syscall names against a table is often outdated. Not sure that's a real argument though, but still, something to consider when deciding to use numbers as well.

I wonder if we could look these up dynamically.

@runcom Looks like we require another rebase. Sorry.

Rebased

LGTM

LGTM


Enable integration tests for MarkLogic

Adds an installer script for MarkLogic and adds it to the travis build matrix. Only the filesystem integration tests are enabled atm, all regression tests are skipped.
Also fixes a couple issues discovered thanks to the improved QScript generation.

Can one of the admins verify this patch?

Current coverage is 64.31% (diff: 0.00%)

Merging #1543 into master will increase coverage by 0.93%

@@             master      #1543   diff @@
==========================================
  Files           326        326
  Lines         15369      15142   -227
  Methods       14860      14860
  Messages          0          0
  Branches        151        143     -8
==========================================
- Hits           9740       9738     -2
+ Misses         5629       5404   -225
  Partials          0          0

Powered by Codecov. Last update fcf59f7...d6d0787

@mossprescott Looks like it worked, back in your court.

Really happy to be getting this into the build 😀
I'm obviously just getting acquainted with this codebase, and of course at this point there are lots of areas for future attention. You can take my questions about testing as suggestions for that.
So, just the one comment that seems wrong and the caching thing and I'll merge.


[5.8] Fixes clearing facades resolved instances after bootstrap app in testing

This pull request addresses this issue: https://github.com/laravel/framework/issues/28053.
Note: I am not sure about the regressions this pull request can cause.
The problem: Currently, using a service provider, if someone alters the a mutable object resolved by a  facade, the altered object will be reset after bootstrapping the application in the setUp in testing environments.
Service provider:
    public function register()
    {
        \App\MyFacade::addData('foo');
    }

Test:
    public function testBasicTest()
    {
        dd(\App\MyFacade::getData()); // empty array
    }

The fix: Clear the resolved facades before bootstrapping the application the mimic the http/console enviroments.

This could use a regression test.

Not merging anything with such uncertainty.

Is this a regression test from 5.7? If so, what caused it?

The problem: Currently, using a service provider, if someone alters the a mutable object resolved by a facade, the altered object will be reset after bootstrapping the application in the setUp in testing environments.

It's not clear how this is a problem, and not just a behavior. How is this wrong? Shouldn't the altered objects be reset? Is the problem more focused on when the facades are reset, and not if they should be?
So far you're describing a mutable static application state. Some call them globals. Those are always fun, and slightly weird in test scenarios...

This is present in Laravel 5.7 also:
You can recreate with the exact same steps (and results) using this repository:
https://github.com/fideloper/facade-bug57

For now I'll go about this in a different way - altho this is a bit wonky in that it behaves differently within a web request (works) than unit test.
In terms of timing, @sisve, this appears to clear the Facade within the same request cycle. Bootstrapping adds to the facade (My AppServiceProvider adds the data into the Facade), but then the Facades are cleared afterward.
That seems a bit edge-casey to me, so going about this another way seems fine and easy enough.

Just a note, orchestra/testbench always clear facades instances between creating a new application instance and registering service providers.

Furthermore, Laravel already reset facades during Illuminate\Foundation\Bootstrap\RegisterFacade which is run before Illuminate\Foundation\Bootstrap\RegisterProviders (see https://github.com/laravel/framework/blob/5.8/src/Illuminate/Foundation/Console/Kernel.php#L63-L71). Therefore the line in setUp() is redundant.

Going to hold off on this in case it introduces more breaking changes.


nixos/nginx: add option rejectSSL exposing ssl_reject_handshake

Motivation for this change
Alternative to #119039 as suggested in this comment.
Exposes nginx 1.19.4's ssl_reject_handshake directive. This is useful in default server blocks, to avoid serving the certificate for another vhost. For example, assuming I have a wildcard DNS record for *.example.com:
{ pkgs, ... }: {
  services.nginx = {
    enable = true;
    package = pkgs.nginxMainline;
    recommendedTlsSettings = true;
    virtualHosts = {
      "foo.example.com" = {
	forceSSL = true;
	# ...
      };

      default = {
	default = true;
	rejectSSL = true;
	extraConfig = "return 444;";
      };
    };
  };
}

Now accessing http://unknown.example.com results in a connection reset, and https://unknown.example.com results in a TLS error.
See https://trac.nginx.org/nginx/ticket/195 for additional context.
Things done

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

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[X] Tested this on my own server
[X] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

@SuperSandro2000 is there a style guide somewhere?

@aanderse @lukegb any opinion on this?

My opinion is:
ship it


[hw] Modify makefile to allow using entropy buffer

This PR modifies hw/Makefile to allow using entropy buffers for generating synthesis constants.
This file uses variable USE_BUFFER to indicate which source of randomness to use:

python PRNG (if USE_BUFFER=0)
Files with entropy (if USE_BUFFER=1)

To use entropy from files run:
export USE_BUFFER=1
cd hw/ && make all
Precondition:
Files with entropy need to be present in the following locations:
-./util/topgen_entropy_buffer.txt (minimum size 20000 bytes)
-./util/design/lc_entropy_buffer.txt(minimum size 1000 bytes)
-./util/design/otp_mmap_entropy_buffer.txt(minimum size 2000 bytes)
For testing purposes, these buffers can be generated using ./util/entropy_buffer_generator.py, e.g. by running
./util/topgen/entropy_buffer_generator.py --sec -n 20000 -o ./util/topgen_entropy_buffer.txt
./util/topgen/entropy_buffer_generator.py --sec -n 1000 -o ./util/design/lc_entropy_buffer.txt
./util/topgen/entropy_buffer_generator.py --sec -n 2000 -o ./util/design/otp_mmap_entropy_buffer.txt

This

2. Are we 100% sure that nothing in the flow keeps using Python's random under the hood even if this new Makefile argument is used?

I've inspected the LOG file after running make all and it seems that no other scripts are using random.py

Thanks @timothytrippel for your input.
Indeed, we need to make sure that dvsim can pick up the entropy files. Currently the toplevel tests fail (as expected) if we use buffer (USE_BUFFER=1) to generate the target. I will proceed to work on this.
I have one question regarding this point

3. we need to generate different entropy buffer files based on the dvsim build / run seeds in the nightlies to feed the above (so we can continue to run sims with different netlist consts / random OTP image values) both via a dvsim pre-run command (like is done for some of the OTP images) and via a bazel rule so that the Bazel-generated OTP images will have these files as a dep

Do we want to use entropy buffers for the nightlies? My understanding was that the flow with entropy buffers will be used only once before the tapeout, and that the regular nightly regressions will continue to use unsecure_generate_from_seed()
Perhaps this is a question for @msfschaffner and @vogelpi
I suggest to continue discussion on this topic in issue #15144

@vogelpi The PR is ready to merge now. The remaining changes towards integrating strong_random will not touch the Makefile


Fix Protoss Natural wall on Pillars of Gold LE

Describe the bug
The natural wall is build inside 2nd base incorrectly.

Fixed in commit f98ffdf.


x/sync/errgroup: Group.Wait may return before all Group.Go calls are finished

Go version
go version go1.23.1 darwin/amd64
Output of go env in your module/workspace:
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/Users/haaawk/Library/Caches/go-build'
GOENV='/Users/haaawk/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/haaawk/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/haaawk/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_amd64'
GOVCS=''
GOVERSION='go1.23.1'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/haaawk/Library/Application Support/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/_y/nj5hcsh93l12tmsszxgx7ntr0000gn/T/go-build2396141927=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?
When following code is run:
package main

import (
	"runtime"

	"golang.org/x/sync/errgroup"
)

func main() {
	runtime.GOMAXPROCS(1)
	g := &errgroup.Group{}
	g.SetLimit(1)
	ch := make(chan struct{})
	wait := make(chan struct{}, 2)
	g.Go(func() error {
		<-ch
		wait <- struct{}{}
		return nil
	})
	go g.Go(func() error {
		println("I'm not blocked")
		wait <- struct{}{}
		return nil
	})
	println("Ok let's play")
	close(ch)
	g.Wait()
	println("It's over already?")
	<-wait
	<-wait
}

https://go.dev/play/p/xTIsT1iouTd
What did you see happen?
The program printed:
Ok let's play
It's over already?
I'm not blocked

What did you expect to see?
The program printing:
Ok let's play
I'm not blocked
It's over already?

Related Issues

golang.org/x/sync/errgroup: strange data race  #65045 (closed)
Importing net/http prevents goroutine deadlock error in particular case #40489 (closed)
x/sync/errgroup: clarify that Go calls the function regardless of prior errors #54045 (closed)
testing: inconsistent behaviors between running tests directly and after compiling the code first #59879 (closed)
affected/package: os/exec, context not work. #53700 (closed)
cmd/go: test gets hung #27720 (closed)
sync: wait group produces data race when waiting before adding in separate goroutine #56728 (closed)
affected/package: sync #50544 (closed)
need help: different call using the same channel. #35094 (closed)

Related Discussions

Potential Issue in errgroup

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

I send a patch here https://go-review.googlesource.com/c/sync/+/627075

go g.Go(
I don't think this is what you meant to write.

go g.Go(
I don't think this is what you meant to write.

It is exactly what I meant to write. Otherwise the g.Go would block.

Your program contains a data race, because it's not valid to increment a waitgroup with 0 count while waiting on it.  Your submitted patch doesn't change this.

No.  You would need additional synchronization to guarantee this.
package main

import (
        "runtime"

        "golang.org/x/sync/errgroup"
)

func main() {
        runtime.GOMAXPROCS(1)
        g := &errgroup.Group{}
        g.SetLimit(1)
        ch := make(chan struct{})
        wait := make(chan struct{}, 2)
        insideGo := make(chan struct{})
        g.Go(func() error {
                <-ch
                wait <- struct{}{}
                return nil
        })
        go g.Go(func() error {
                close(insideGo)
                println("I'm not blocked")
                wait <- struct{}{}
                return nil
        })
        println("Ok let's play")
        close(ch)
        <-insideGo
        g.Wait()
        println("It's over already?")
        <-wait
        <-wait
}

@jrick is right. go g.Go(...) is not what you want. g.Go is intentionally blocking to limit the number of active goroutines. You've called g.SetLimit(1), so that limits it to 1 active goroutine a time. If you don't want that limit, you can remove that line, or set a higher limit.
In your case, there is no synchronization between g.Wait and the g.Go call in the new goroutine created by go g.Go(...). If is possible that g.Wait has finished while the new goroutine created by go g.Go(...) hasn't run. So this works as intended. Your CL doesn't seem to change it either: g.Wait can still finish even before the new goroutine reaches g.Go.
In general, if you have questions about how to use the API, please see https://go.dev/wiki/Questions . Thanks.

This was just my failed attempt to have a simple reproducer to the issue that's still there.
In the code below the order is always right and the program still prints the same result. The problem is that g.Go can wake up from sem in a group that was already waited on.
Let me thing of less artificial example and come back. It will need to be more complex unfortunately.
package main

import (
	"runtime"
	"time"

	"golang.org/x/sync/errgroup"
)

func main() {
	runtime.GOMAXPROCS(1)
	g := &errgroup.Group{}
	g.SetLimit(1)
	ch := make(chan struct{})
	wait := make(chan struct{}, 2)
	g.Go(func() error {
		<-ch
		wait <- struct{}{}
		return nil
	})
	go g.Go(func() error {
		println("I'm not blocked")
		wait <- struct{}{}
		return nil
	})
	println("Ok let's play")
	time.Sleep(1 * time.Second)
	close(ch)
	g.Wait()
	println("It's over already?")
	<-wait
	<-wait
}

In the code below the order is always right and the program still prints the same result.

This program has a race: the second call to Go races with Wait. Consider: the goroutine created by the first Go function could complete (along with println, Sleep, close) before the goroutine created by the go statement even begins to execute the second call to g.Go.

In the code below the order is always right and the program still prints the same result.

This program has a race: the second call to Go races with Wait. Consider: the goroutine created by the first Go function could complete (along with println, Sleep, close) before the goroutine created by the go statement even begins to execute the second call to g.Go.

I know it's not properly synchronized and I never said it is. I said that the order is right. I wouldn't expect runtime to stay idle during sleep and not execute the runnable goroutine.
I guess a race free reproducer could be:
package main

import (
	"runtime"
	"runtime/pprof"
	"strings"
	"time"

	"golang.org/x/sync/errgroup"
)

func main() {
	runtime.GOMAXPROCS(1)
	g := &errgroup.Group{}
	g.SetLimit(1)
	ch := make(chan struct{})
	wait := make(chan struct{}, 2)
	go func() {
		println("Starting task scheduler")
		println("Scheduling first task")
		g.Go(func() error {
			<-ch
			println("First task ran")
			wait <- struct{}{}
			return nil
		})
		println("Scheduling second task")
		g.Go(func() error {
			println("What about me?")
			wait <- struct{}{}
			return nil
		})
	}()
	time.Sleep(1 * time.Second)
	var b strings.Builder
	pprof.Lookup("goroutine").WriteTo(&b, 1)
	close(ch)
	if strings.Contains(b.String(), "errgroup.go:71") {
		g.Wait()
		println("Game over")
	} else {
		println("Second task not blocked yet")
	}
	<-wait
	<-wait
}

https://go.dev/play/p/Zg5GpZJz2bK
but I have to admit, there's probably no way to reproduce the problem in a completely race free way. If g.Go and g.Wait are in two different goroutines then runtime can always preempt g.Wait in the middle and then schedule g.Go to run and set g.wg.Add(1) while g.Wait is running with counter equal to 0.

I guess it would be cleaner if the docs were saying explicitly that g.Wait has to be called only after all calls to g.Go finish. This is not obvious without looking into the implementation. One could imagine an implementation that does not have a data race when g.Wait and g.Go are called concurrently.

I guess it would be cleaner if the docs were saying explicitly that g.Wait has to be called only after all calls to g.Go finish. This is not obvious without looking into the implementation. One could imagine an implementation that does not have a data race when g.Wait and g.Go are called concurrently.

It's fine to call Go concurrently with Wait, and indeed useful, if one item of work might add others to the queue. But you can't use SetLimit in this scenario or else the Group will stop accepting work. We could certainly document that, but we should not try to disallow concurrent calls to Go.

I guess it would be cleaner if the docs were saying explicitly that g.Wait has to be called only after all calls to g.Go finish. This is not obvious without looking into the implementation. One could imagine an implementation that does not have a data race when g.Wait and g.Go are called concurrently.

It's fine to call Go concurrently with Wait, and indeed useful, if one item of work might add others to the queue. But you can't use SetLimit in this scenario or else the Group will stop accepting work. We could certainly document that, but we should not try to disallow concurrent calls to Go.

It is a very unintuitive requirement which is really driven by implementation details not the best API design but you're right.

It is a very unintuitive requirement which is really driven by implementation details not the best API design

I think your criticism of the design is unfair. The doc comment for SetLimit says that it "limits the number of active goroutines", and that "any subsequent call to the Go method will block ...". The alternative that you propose would remove the blocking behavior, which would be an incompatible change (since it removes happens-before edges), and it would require that Group maintain an arbitrarily large queue of functions provided to Go before a goroutine is available to run them, which could cause an application to use unbounded memory when dealing with very long streams of tasks.

My criticism is about the fact that calling Wait and Go concurrently with no synchronization is a data race and the docs don't say a word about it. Calling Go from a goroutine running inside a group is a form of synchronization. The requirement is really specific - "You can call Go concurrently with Wait only if you have guaranteed that at least 1 other goroutine that is already running inside the group won't finish until after either Go or Wait finishes first - or both.

True, but the exact same principle applies to plain old WaitGroups: to add an item to the group you call Add(1) and later Done. In the simple case you make all the Add calls in sequence and all the Dones happen asynchronously. In more complex cases a task begets more tasks, so it calls Add (for the child) before calling Done for itself, preserving the invariant. But you get into trouble if you make the Add asynchronous to the Wait without otherwise ensuring that the semaphore is nonzero.
Perhaps we could add some clarifying documentation.

BTW I came up with this issue because I found in the codebase I'm working on the following code outside of group goroutines:
	if !w.g.TryGo(f) {
		go w.g.Go(f)
	}

and it seemed fishy from the concurrency point of view so I kept digging. Apparently someone was misled by errgroup.Group docs/API.

Reopening as a doc change request.


pod install does not work after adding a new test/watch/extension/other target with Xcode 16

CocoaPods does not work with Xcode 16 since it has not yet been updated to handled synchronized groups/folders https://github.com/CocoaPods/CocoaPods/issues/12456
Add flutter tooling support that detects the Xcode project contains PBXFileSystemSynchronizedRootGroup, and outputs a warning linking to this issue or https://stackoverflow.com/a/79003357/431116 or similar with the workaround.
Around here check if the error contains "unknown ISA `PBXFileSystemSynchronizedRootGroup`"
https://github.com/flutter/flutter/blob/64d96eaa492527c670f064edf6584c602c721eb5/packages/flutter_tools/lib/src/macos/cocoapods.dart#L396
From https://discord.com/channels/608014603317936148/1295165633931120642/1295166301626564628
The issue encountered after adding the native Unit/UI tests target for macOS in the example app by following Flutter instructions of Enabling XCTests or XCUITests, which prevent running or building the example app, causing failure when running pod install or flutter run -d macos

Use latest version of Flutter stable channel (Dart 3.5.3, Flutter 3.24.3) with latest CocoaPods (1.15.2) and Xcode 16.
Clone flutter/packages repo and cd into a plugin that have support for macOS but doesn't have native UI/Unit tests. https://github.com/flutter/packages/tree/main/packages/image_picker/image_picker_macos/example/macos is an example.
Run pod install in the example macOS app or run the Flutter app directly with flutter run -d macos.
Follow the steps in https://github.com/flutter/flutter/blob/master/docs/ecosystem/testing/Plugin-Tests.md#enabling-xctests-or-xcuitests to enable XCTests or XCUITests.
Run the Unit test directly in Xcode, works as expected.

### Command

/opt/homebrew/Cellar/cocoapods/1.15.2_1/libexec/bin/pod install

...
### Error

RuntimeError - `PBXGroup` attempted to initialize an object with unknown ISA `PBXFileSystemSynchronizedRootGroup` from attributes: `{"isa"=>"PBXFileSystemSynchronizedRootGroup", "explicitFileTypes"=>{}, "explicitFolders"=>[], "path"=>"RunnerTests", "sourceTree"=>"<group>"}`
If this ISA was generated by Xcode please file an issue: https://github.com/CocoaPods/Xcodeproj/issues/new
/opt/homebrew/Cellar/cocoapods/1.15.2_1/libexec/gems/xcodeproj-1.25.0/lib/xcodeproj/project/object.rb:359:in `rescue in object_with_uuid'

Originally posted by @jmagman in https://github.com/flutter/flutter/issues/153402#issuecomment-2411770264

In your flutter project, open up macos/Runner.xcworkspace or ios/Runner.xcworkspace by right clicking, and clicking Show package contents

Inside your .xcworkspace file, you should have a list of your folders on the left. All folders that are highlighted in blue is a synchronized group/folder. For each of these, right click, and click Convert to Group

Back in your macos or ios folder, run pod deintegrate, then pod install. Everything should now work as expected!

CocoaPods has fixed this and now supports Xcode 16 synchronized groups.  Please update to a minimum of 1.16.2 (fixed in 1.16, but .1 and .2 have important bug fixes).
https://guides.cocoapods.org/using/getting-started.html#installation


Review desired_glyph_data (diverges too much from Google Fonts collection)

The vast majority of the font files in the Google Fonts collection have glyphs with a number of contours that is not expected in the model described by the desired_glyph_data data structure used on com.google.fonts/test/153.

We should review and possibly improve that data model, otherwise it may not be so much useful.

that single ERROR is described at #1599

@m4rc1e could you please take a look at this when you have some time (perhaps next year) ?

Any further thoughts here, @m4rc1e?

Anything being done here?
I'm currently getting complaints about the number of contours in box drawing (for corners with single and double line, FB expects strictly two contours, I have one) and shading (e.g. Contours detected: 84, Expected: 46) characters. It's kind of counter-productive.

@felipesanches, ping? This issue has been prioritised as important, and yet nothing is being done with it for seven years and counting. :disappointed:

It's kind of counter-productive.

If you know they're wrong, ignore them. WARNs are WARNs, not FAILs.

It's kind of counter-productive.

If you know they're wrong, ignore them. WARNs are WARNs, not FAILs.

They are. But these WARNS still have a yellow icon next to them, produce noise and serve as a distraction.
Do you actually think that checking box drawing and block shading characters for an overly strictly prescribed number of contours is valuable? Maybe you could at least relax that strict number then? Because none of the messages below are useful:
- Glyph name: uni2552	Contours detected: 1	Expected: 2
- Glyph name: uni2553	Contours detected: 1	Expected: 2
- Glyph name: uni2555	Contours detected: 1	Expected: 2
- Glyph name: uni2556	Contours detected: 1	Expected: 2
- Glyph name: uni2558	Contours detected: 1	Expected: 2
- Glyph name: uni2559	Contours detected: 1	Expected: 2
- Glyph name: uni255B	Contours detected: 1	Expected: 2
- Glyph name: uni255C	Contours detected: 1	Expected: 2
- Glyph name: uni255E	Contours detected: 1	Expected: 2
- Glyph name: uni2561	Contours detected: 1	Expected: 2
- Glyph name: uni2569	Contours detected: 2	Expected: 3
- Glyph name: uni2591	Contours detected: 84	Expected: 46
- Glyph name: uni2592	Contours detected: 12	Expected: 85
- Glyph name: uni2593	Contours detected: 85	Expected: 73

You can set the logging level to skip warns. Do this by adding -l FAIL to your fb command. It will now only print out the failing checks,.

And what if I mess up another glyph where this warning would be useful, but I never get the warning because I use -l FAIL? What about all other warnings which might be useful as well?
I thought that these warnings were supposed to be helpful. Looking at the initial bugreport, this one clearly isn't, so I really don't understand why you're so keen on keeping it as it is. If it's time that is the issue, it's fine, but I'd rather know that you'll get to this eventually than that you see no problem at all with this check.

We know there's a problem with this check. That is why there is an open issue about it.

What about all other warnings which might be useful as well?

You can still have all the other WARN level checks run if you exclude this one with -x contour_count

It's kind of counter-productive.

If you know they're wrong, ignore them. WARNs are WARNs, not FAILs.

They are. But these WARNS still have a yellow icon next to them, produce noise and serve as a distraction.
Do you actually think that checking box drawing and block shading characters for an overly strictly prescribed number of contours is valuable? Maybe you could at least relax that strict number then? Because none of the messages below are useful:
- Glyph name: uni2552	Contours detected: 1	Expected: 2
- Glyph name: uni2553	Contours detected: 1	Expected: 2
- Glyph name: uni2555	Contours detected: 1	Expected: 2
- Glyph name: uni2556	Contours detected: 1	Expected: 2
- Glyph name: uni2558	Contours detected: 1	Expected: 2
- Glyph name: uni2559	Contours detected: 1	Expected: 2
- Glyph name: uni255B	Contours detected: 1	Expected: 2
- Glyph name: uni255C	Contours detected: 1	Expected: 2
- Glyph name: uni255E	Contours detected: 1	Expected: 2
- Glyph name: uni2561	Contours detected: 1	Expected: 2
- Glyph name: uni2569	Contours detected: 2	Expected: 3
- Glyph name: uni2591	Contours detected: 84	Expected: 46
- Glyph name: uni2592	Contours detected: 12	Expected: 85
- Glyph name: uni2593	Contours detected: 85	Expected: 73

If you agree with us that some of the numbers are sometimes too strict, then please help us by listing which better values we should use.
You could send a pull request with the desired changes. Or you could describe them and we can review and possibly adopt them.

@felipesanches, would it be okay if I also converted unicode codepoint numbers from decimal to hex in glyphdata.py and maybe reordered the list by unicode value?
I could do that in a separate PR, or at least in a separate commit.
https://github.com/fonttools/fontbakery/blob/3edb21eb8a731a0208dcfe141df4cfbd2e99f486/Lib/fontbakery/glyphdata.py#L1-L2126

No probs if you sort the list by unicode and convert the ints to 0x.
You raise a good point regarding shaded glyphs since they can contain an arbitrary amount of points. It may make sense to simply remove these glyphs from the list.

@m4rc1e, here we go! :)

I'm tempted to make this file only focus on glyphs which often have MM problems.

While porting this check I discovered that we actually went in the opposite direction - the check just gets skipped on variable fonts! I'm going to massively rework this for fontspector.


6.2.0 Release

Cutting new release.  Did a bump on the minor since the public API didn't change and i simply updated a dependency.

There has to be a bump somewhere in the version in order to following semver.  Also I was basing the non-breaking change off the recommendation in the semver doc.


Question re testing / debugging macPPM to work...

It was great to come across macPPM as it looks like exactly what I've been looking for to help my son use his RC controller with X-plane - way better than our crappy joystick
I'm not sure how to confirm that the various aspects are working as they should, though...
When I run your macPPM binary (on Mac OS 10.12.5)  with the -t option (test mode), it says "Initializing..." but no text output beyond that.
With the -t option it also outputs a steady buzzing sound.
This buzzing seems  to be independent of audio input  - e.g. it sounds just the same whether line or microphone in is selected, and if line is selected, it sounds the same whether or not the RC transmitter buddy cable is plugged in.
When plugging the buddy cable in there is definitely activity from the transmitter being picked up- this can clearly be seen in the audio control panel .
So I am wondering if you have any ideas for identifying what is or isn't working?
One thing that I am not clear about is - if I am running it from the binary (as I'm not really experienced at compiling from source) how do I provide the libportaudio dependency? There is a directory called  libportaudioBinary in the download, but this appears to contain only source code. I found a binary called libportaudio.dylib elsewhere but it is not quite clear where this should go...
Finally, sometimes but not always, I see the following error:
"Unable to create HID device - hope that it exists already. "
If you've got any ideas for how I might diagnose, that would be great!
Thanks for any tips
Matt
PS
Incidentally, the transmitter I am using is a  Saturn 2.4 GHz FHSS transmitter very similar to this one. http://airtekhobbies.com/downloads/esale6.pdf
I'm anticipating that the coding of its buddy system may or may not be Futaba-compatible, but at before delving into that just want to confirm that macPPM is correctly installed, and can pick up anything on the line-in...

Hi Matt,
what happens if you try the -t and -c options together? Depending on how your cable is wired the signal is either on the left or right channel and the -c option switches between them. What you are looking for is a clearly audible change in the buzzing sound while moving the controls on your transmitter. libportaudio.a is statically linked into the binary, so it is only needed for compilation.

Hi there.
Amazing! Thanks for this.
I was sure I'd tried the -tc option, but I just tried it now and it worked
perfectly - all performing as expected in terms of returning numbers that
vary as I move the controls.
I have also now compiled from source myself, which worked but only once I
found  and downloaded pa_mac_core.h from another source as it complained
that was missing initially. I think maybe that also needs to be in your
portaudio binary zip file?
Now that I have it compiling, should be easy enough to tweak joystick
mappings if need be. I guess you can add Saturn to the list of controllers
which are known to work!
Thanks again for rapid response, and for sharing this!
Matt
On 20 July 2017 at 21:28, albhm<EMAIL_ADDRESS>wrote:

Hi Matt,
what happens if you try the -t and -c options together? Depending on how
your cable is wired the signal is either on the left or right channel and
the -c option switches between them. What you are looking for is a clearly
audible change in the buzzing sound while moving the controls on your
transmitter. libportaudio.a is statically linked into the binary, so it is
only needed for compilation.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/albhm/macPPM/issues/1#issuecomment-316820416, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AHjjBgLCs4eDXZ-oEHD1TA3haUoiM2QGks5sP7hWgaJpZM4OeKQZ
.

Nice to hear it's working so far!
I updated the portaudio zip file to include pa_mac_core.h - thanks for the hint!
Regarding the mapping: the columns of numbers seen while using -t are in order.
So if the value in the third column changes while you move the x-axis of the left stick, change
joy.x = (getBuddyBoxThreadInputChannelValue(&pasBB, 0)-0.5) * 255;
to
joy.x = (getBuddyBoxThreadInputChannelValue(&pasBB, 2)-0.5) * 255;
in main.c - and so on. Maybe I'll add some sort of option or config file to accomplish that without having to recompile.

The nice thing about X-Plane is that it provides a full GUI for mapping/calibrating inverting axes, so all can be sorted within the app. No code change needed - though I did tweak to flip the default audio channel (perhaps code could automatically try one then the other as part of calibration?)
Anyway, it works just great. Thanks again!

On 21 Jul 2017, at 08:43, albhm<EMAIL_ADDRESS>wrote:
Nice to hear it's working so far!
I updated the portaudio zip file to include pa_mac_core.h - thanks for the hint!
Regarding the mapping: the columns of numbers seen while using -t are in order.
So if the value in the third column changes while you move the x-axis of the left stick, change
joy.x = (getBuddyBoxThreadInputChannelValue(&pasBB, 0)-0.5) * 255;
to
joy.x = (getBuddyBoxThreadInputChannelValue(&pasBB, 2)-0.5) * 255;
in main.c - and so on. Maybe I'll add some sort of option or config file to accomplish that without having to recompile.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.


shim-v2: fix shim leak when hypervisor exit unexpectly

Fixes: #1929
in containerd-kata-v2, container can only be deleted in Delete
interface, or other shim operates(like kill/delete) all fails
since can not get container info.

thanks @Ace-Tang
cc @lifupan

/test

Hi @Ace-Tang
I can't figure out why this patch could resolve your named "shim" leak.  In my opinion it's containerd's responsible to send shutdown rpc call to stop the shimv2, but containerd didn't.

@lifupan , when containerd call delete shim, since container has be deleted in watchAgent, the function Delete can not get container, then delete ops was error

@lifupan , when containerd call delete shim, since container has be deleted in watchSandbox, the function Delete can not get container, then delete ops was error

Did/n't  https://github.com/kata-containers/runtime/blob/8ad6b0ea9312ac10bff4b6f887109657c2ac4835/containerd-shim-v2/service.go#L669 check  the container's status and return directly?

Seems no place update container status container.status

But it can be add, if you think that will better

Seems no place update container status container.status

In theory this line https://github.com/kata-containers/runtime/blob/00e0aaa6e43cec27077484ef6700e131202c874c/containerd-shim-v2/wait.go#L68  should change the container status once the qemu process terminated, and BTW, in your code, since the sandbox has been deleted by watchSandbox, then you shouldn't get the container status from sandbox, isn' t it?

I add set containers status in watchSandbox, would you check again

/test

restarting centos CI


Could not init with jsx_preact plugin

Version
latest
Platform
Linux
What steps will reproduce the bug?
deno run -Ar https://deno.land/x/lume/init.ts, choose y for Typescript and select the following plugins: jsx_preact mdx tailwindcss postcss
How often does it reproduce? Is there a required condition?
Always
What is the expected behavior?
No response
What do you see instead?
Lume configuration file saved: _config.ts
error: Uncaught (in promise) ReferenceError: __DENO_NODE_GLOBAL_THIS_1673619784__ is not defined
    at file:///home/guillaume/.cache/deno/npm/registry.npmjs.org/preact/10.11.3/dist/preact.mjs:1:18

Additional information
No response

It looks like a Deno issue on loading npm packages dynamically.
It will be fixed in the next version. Thanks!


nixos: nixos-generate-config: document all the common things

Motivation for this change
Combination of https://github.com/NixOS/nixpkgs/issues/17126#issuecomment-315190218 and https://github.com/NixOS/nixpkgs/pull/35292#issuecomment-367714173 got me over the edge.
Things done

[X] It evaluates.

Feel free to point to typos I probably missed.

Both nitpicks fixed.

this file is getting huge, but i do think several the tips you recommend are good / useful

this file is getting huge

It is, but it now documents literally everything you commonly need to know about configuring your system after reading the first 12 items of the installation chapter of the manual. All of my configuration.nix files (except those that I use for tests) touch all of the mentioned variables. I assume that most people read first 12 items and then start editing configuration.nix, so it is the most appropriate place to put all of that.
The part about nix-env and allowUnfree should still be copied to the manual (actually, to both nix and nixos manuals), but that's out of scope of this PR.

Fixed a tiny typo/OCD thing.
What's holding this? While this ferments some people encounter the problem described in #17126, say "f*ck it" and drop NixOS while others unwittingly enable the PA daemon.
Unless there's a problem with this I would merge this ASAP and cherry-pick to 18.03 too.
/cc @grahamc @vcunat

I think these newlines confuse it, where without the newline it is clearly tied to the section.

Ok, fixed everywhere. It now groups things with an empty comment line.

"To search packages"

Fixed.

List of packages for the system profile, by attribute name.

Fixed.

-qaP '.*wget.*'

Fixed everywhere.

the NixOS channels

Fixed.

Maybe add See man configuration.nix.

Done.

Probably a bit much :)

It's not. See https://www.youtube.com/watch?v=yBA6u5IsXyc

I think removing this section about mediakeys would make it easier to merge, since mediakeys being an option is a bit contentious.

IIRC the contention was "I run X11, my WM does this, I don't want this, please remove it". Since it's not enabled by default I don't think it's a valid argument.
Anyway, I moved that doc to the mediaKeys docstring and made into a tiny note. This way it should make the thing much less contentious, I hope. If you think it's still too much, I'm ok with removing it, but I think it's useful to keep it.

Should probably drop this previous section, because the section about enabling sound explains it well enough I think.

I disagree, grepping the whole of nixpkgs for apulse gives no results that explain how and when to use it except this. Since Mozilla keeps pushing people to PA I think it's only fair to inform people that they can work around it with a single line of config.
Anyway, I rewrote that part to be shorter.

I think all of the changes following here should probably be in the wiki instead.

I disagree.
I think the default configuration.nix should include everything you need to set to reboot into the new configuration and see properly working X11 desktop (including acceleration) with your favorite apps. So allowUnfree, GPU and desktop stuff is essential.
The network user account thing is more contentious, I agree. Note, however, that NixOS already does exactly this for system (as opposed to user) services (hence, another reason to distrust PA, just sayin') and that is not considered contentious for some reason (I suppose, because it requires zero configuration). However, I think it's essential to inform as many users as possible of the easiness of doing things this way. Many security-oriented sites recommend installing software that manages your keys/wallets onto your Android phone (seriously, Android phone!) instead of your desktop because Android does separate users for different apps by default. This makes me mad (because they recommend keeping secrets on a device that almost never updates it's kernel), twice so since they are essentially correct that it still gives more security than your average Linux install (because of the above), trice so since it's super easy to fix on OSes with declarative configs like NixOS. Which is why I wrote this part in the first place.
Anyway, I moved the stateVersion thing to the top, and added "you can ignore all of this" note before the thing to make it less contentious. I think it should stay. (Actually, I hope to eventually add notes on QubesOS-like setups there too, when NixOS accepts patches required to do that.)
Also, I think the wiki is either dead or should be dead and everything should be greppable directly in the repo. Also, related, I hate that most code in nixpkgs refers to manual pages via nixos.org URLs instead of just pointing to the text files in the repo itself. This is crazy, but it is understandable, because those files are in unreadable docbook format. The only thing that prevents "you only need to clone nixpkgs and you get everything" utopia is docbook. But that's outside of the scope of this PR.
Anyway, see the new patch. Will squash if all is ok.

I can't speak to the docbook, but nixos.wiki is a happy and healthy source of pretty high quality information now, thanks to fadenb, lassalus, makefu, mic92, samueldr, and many many others.

While I appreciate the work, I don't like the idea. I think we already had a wiki before and saw what that turned itself into. The problem with wikis tied to software projects is that after initial wave of enthusiasm they get out of sync with the code even faster than the documentation that ships with the code.
Ask yourself. Your last ten nixpkgs problems. How many solutions to them were on the wiki? Somewhere else on the web? In GitHub issues? In the git log? I usually start by grepping the repo, the git log, and GitHub issues (I archive and index all of them, so searching them is easy) (in parallel with a simple script), 99.9% of the time I find the solution before the web browser window appears on my screen.
My point is that we should point users to places developers update directly, because that's where all the fish is. Unless nixos.wiki becomes a submodule of nixpkgs I will not touch it. (But if it becomes a submodule then I would ask why can't we just rewrite all nixpkgs documentation in a saner format and just assimilate the wiki up.)
In short, I think documentation related to nixpkgs usage should be in the nixpkgs repo itself, updatable simultaneously with the code, and browsable with just grep, cat and git log.
Arch and Gentoo Linux wikis and StackOverflow are, IMHO, nice examples of how things get outdated fast. Every singe topic I know anything about usually has a bunch of outdated info in the most prominent places of the articles/answers.
Philosophically, what I think is needed here are not wikis, but proper upstream documentation that is compiled into a typechecked hypertext. Bear with me for a second.
Imagine a world where all the documentation is written in org-mode format. The beauty of it is that not only it's easy to read and write, but it's also easy to parse (line-based) and it can be compiled to all the common formats like HTML or texinfo (I once wrote wiki->HTML converter in three pages sed, just for fun, org-mode is even simpler), and it supports references by GUIDs and a set of org-mode files can be checked for broken links automagically.
Now imagine that all upstream packages have proper documentation in said org-mode format. Now, not only can you refer directly to any piece of their documentation, but you can also build your own documentation by linking and including pieces of documentation from upstream projects and that could be compile-time checked.
I.e. imagine NixOS manual having something like
* Setting up sound
** ALSA {{INCLUDESUBTREE|${pkgs.alsaLib}/share/doc/alsa/index.org}}
** JACK {{INCLUDESUBTREE|${pkgs.jackd}/share/doc/jack/index.org}}
** PulseAudio {{INCLUDESUBTREE|${pkgs.pulseaudio}/share/doc/pulseaudio/index.org}}

or
* Setting up sound
** ALSA {{INCLUDESUBTREEBYID|ca45533c-1e07-413c-8a87-8b4d1e4cade3}}
** JACK {{INCLUDESUBTREEBYID|...}}
** PulseAudio {{INCLUDESUBTREEBYID|...}}

({{}} are macros, nice names for them are up to debate) and the documentation build would then just check those links and fail if something gets out of sync.
But since the human race is not yet ready for this alien technology I prefer to put everything into a single repo and generate all kinds of usable documentation formats from it (not just HTML, see #11499).
(Also note that I didn't mention SLNOS even once in the above :])

The risk of putting too much in this file is it is never updated again, making it drift further and further away from reality. I like the idea of putting more information here, but want it to lead to updatable sources.

Then how about adding "review nixos-generate-config" to the release checklist. You do have release checklist, right?

I didn't say it was completely worthless, just a bit much.

Please elaborate what exactly is your problem here. The "galaxy"? How would you write it?

Note that you don't need to enable PulseAudio daemon to get either

of sound playback or software sound mixing. It will out of the box

over ALSA. If you do want to run PulseAudio daemon, however, you

may safely disable sound.enable.

Also note that you can emulate PulseAudio API over ALSA for apps

that refuse to work over ALSA themselves by running them under

apulse. This way you can run one daemon less which benefits your

security (some people claim that PulseAudio codebase lacks in

quality to be connected to untrusted data sources like the browser

by default).

environment.systemPackages = [ pkgs.apulse ];

:-1:  but would accept For more information, see nixos.wiki/something-about-sound...

I don't understand which part you disagree with. Do you want me to stop mentioning apulse? Do you want me to stop informing users that, contrary to a common misconception, they probably don't even need to run PulseAudio daemon to get all the features they want. Both? (I'm not trolling, I honestly don't understand the argument.)
See above about the wiki.

:-1: it shouldn't be near the top if they shouldn't touch it.

Ok, will fix.

:-1: this file will be immediately out of date because nothing can update it.

Eh? "nothing can update it"? What?
If you mean keeping it in sync, then we can add some more markup to the file and the add some nixos tests that would check that different combinations of uncommented options evaluate or whatever.

We shouldn't be talking about best practices or general techniques. This belongs in other documentation elsewhere. The parts about unfree software are universally true. The remainder of this should definitely not be in this config file, but instead in the documentation or wiki.

See above about the wiki.
However, on this and the rest of your :-1:s, I do see you point. I now see that, indeed, this is not the best place to present a bunch of stuff that gets updated frequently, GPU and DE stuff should be moved to the configuration.nix(5) manual and only pointers should be left here.
However, I feel that this argument does not apply to PA stuff above. Because that piece tries to resolve a common misconception born out of suckiness of ALSA documentation. Until ALSA gets a proper documentation we can refer to directly I would like the above piece about PA to stay there.
At the very least I want it to mention that you don't need PA for most sane things and refer to apulse for insane things. I'm ok with moving the snarky comments into the docstring for apulse package and halving the space it takes. Will that be agreeable?

Eh? "nothing can update it"? What?
Once this file is generated, it is installed as configuration.nix on the user's system, and no automated tool ever touches it afterwards.

I think we already had a wiki before and saw what that turned itself into.

For the record: it turned out that a MediaWiki with an open registration requires either too much skill or too much effort to prevent from becoming a spam dump (with spam even overwriting content). Nixos.Wiki seems to hope that a unique CAPTCHA will delay this problem, and in the worst case GitHub login can be made the only option.

@7c6f434c you are only partly right. The first step to fight spam obviously is a technical measure (captchas), however the new wiki is watched over closely by  by a number of volunteers. There is a wiki-update bot in #nixos-wiki and we at least sight changes to ensure quality.
Some time ago someone asked how the archlinux wiki can stay such a wealthy resource and the answer was simple, there were people who cared. Now that the wiki is lead by a number of people and not a single person i think we can do something similar for the nixos community.
If you would like to help the effort you can join nixos-wiki on freenode!

@makefu well, you still need technical foundation to match — I mean, at some point I tried to roll back a spam attack on the old NixOS MediaWiki and suddenly understood that I just cannot understand how to untangle this sequence of history-masking-redirection-tricks. Some people did try to care, it just turned out that the people who cared at any given moment didn't have a combination of skill (and maybe MediaWiki access level?) to maintain defense efficiently.
Of course I do not deny the main effort of the team — creating and maintaining high-quality content. I just say that you have enough technical options to guarantee avoidance of the despair event horizon that the old wiki had.
(As for me, I am a person who can entertain people by describing how non-trivially my system is configured, and how it is not fully NixOS — so I can help people debug via IRC, but writing useful Wiki content without immediate feedback would be hard)

Updated.
Most frequently changing things are now gone to the configuration.nix(5). I left some of the DE setup in because xfce and slim are the most stable pieces of DE software ever, they are not going to change frequently (unlike Gnome and KDE). If you want to remove those lines I suggest we remove all DE setup then starting with KDE, since it's the most frequently changing thing in this config.
Unfree examples use "hello-unfree" package and so they are very un-corporate now.
I think I answered to all other nitpicks, feel free to reiterate if you disagree with the current state of the file.

No attempt on aarch64-linux (full log)
The following builds were skipped because they don't evaluate on aarch64-linux: hello-unfree
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnfree = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnfree = true; }
to ~/.config/nixpkgs/config.nix.

No attempt on x86_64-linux (full log)
The following builds were skipped because they don't evaluate on x86_64-linux: hello-unfree
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnfree = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnfree = true; }
to ~/.config/nixpkgs/config.nix.

A tiny piece of this was already merged in 92265e807e60fac8bbf3c08a82715b575b5e4e7e, I split other weakly-related parts into #41763 and #41764.
Ping!

No attempt on x86_64-linux (full log)
The following builds were skipped because they don't evaluate on x86_64-linux: hello-unfree
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnfree = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnfree = true; }
to ~/.config/nixpkgs/config.nix.

No attempt on aarch64-linux (full log)
The following builds were skipped because they don't evaluate on aarch64-linux: hello-unfree
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnfree = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnfree = true; }
to ~/.config/nixpkgs/config.nix.

No attempt on aarch64-linux (full log)
The following builds were skipped because they don't evaluate on aarch64-linux: hello-unfree
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnfree = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnfree = true; }
to ~/.config/nixpkgs/config.nix.

No attempt on x86_64-linux (full log)
The following builds were skipped because they don't evaluate on x86_64-linux: hello-unfree
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnfree = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnfree = true; }
to ~/.config/nixpkgs/config.nix.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/128

There some useful bits in here that could be cherry-picked into our configuration. However given that the author is no longer working on this pull request, I will close this one.


chore: update repository template to 5c66cd06

Updated repository templates to https://github.com/ory/meta/commit/5c66cd0662b16ad195beaf72d8a892af20eb8e9d.

Coverage remained the same at 43.429% when pulling 45c2f99081b2925e5ad9b8e28567ef760d39be87 on meta-12-14-20-20-10-13 into d0c037489810d5f03877c070fbe31fa1d8572992 on master.


why extract-css-chunks-webpack-plugin is disable for server side?

I am using css module, when do server side rendering, I need to export my css files into a file, then use it in my component, why this is disabled?
https://github.com/zeit/next-plugins/blob/82e944a271c25cba7706db66b01d7e35b534aee1/packages/next-css/css-loader-config.js#L111

Hi, thanks for creating an issue. We currently recommend using https://nextjs.org/docs/basic-features/built-in-css-support as the plugins have been deprecated in favor of the built-in support.


Revert "Refactor the cainjector to only have 1 leader election"

Reverts jetstack/cert-manager#3187
Fixes: https://github.com/jetstack/cert-manager/issues/3251
Revert de-duplication of cainjector leader-election to fix scenario where it crashes at startup due to broken webhook.

/cherrypick release-1.0

/approve
/lgtm

/kind bug


Supernova lacks any way to discover what commands it supports.

supernova help doesn't work as one would expect, but my bad for not RTFMing first.
However, supernova --help delete or similar does not yield any relevant information.  In fact, there isn't even a way to know (without reading the source) what commands it supports.  From a usability POV, this is jarring and shatters flow while trying to use it in a development context.

N/M; after reading the code, I see supernova is a wrapper around nova.  Sorry for confusion.


Fix the path to the example api of budget-manager

I had to find it with some google-fu. Nuff said.

Ah, yeah! Thanks :)


verify-docker-install error

verification looks for install.sh in a build directory which does not exist, either create it to change the verify-docker-install

I think this is intentional; see the Makefile how it's used; https://github.com/docker/docker-install/blob/dd4d114074ecd649c37aa17e688c55fbd4c032fb/Makefile#L11-L23


Query: Investigate perf regressions from 2.0 related to sync Include queries

Specifically, the Query | Include test.

Is this still relevant?


Add tile_suffix_mask and quadint2xy to the API

Couple of commits to add these two functions to the python API. Also I've updated the documentation (at least the part related to conversions) so it should fix https://github.com/CartoDB/python-quadkey/issues/3

:es:


Additional fix for RHARDOC-1235

Ha! I approved the previous fix, did I? I must have been blind :-)


fallback icons don't display properly

the system for getting server information while rendering the forum layout is kind of rubbish ... coz when you get the avatar for a user, and it errors, the cached user info for that user has its icon set to the fallback, but it only applies to avatars with images chosen after the fact. so if the image fails to load after everything has loaded then the images will remain 404ed and the fallback wont display

fixed by c8920b11f9bd04b0169b536cb9e6451d78b64fcc