first version of smart selection dice algorithm

#14
First version, there are a lack of tests now, also it doesn't contain feature "preserve max number of same element".

I fix one logical error and improve last part code. I fixed all remarks on my code, except one on BIG_INT (don't know how to fix it nicely).
Also I merged master branch, sorry if something wrong, I can fix it later.

Hi, thanks again for your commits. Well done.
Big Int Problem
The BIG_INT problem can be solved by filtering out the situations that will return None.
So you make your _how_mush_omni..._to_spend() function assume the first if is True.
And write another function to check the if the condition holds.
So your code on line 88 will be
    [elem,
    self._how_much...to_spend(
        ...
    )
    for ...
    if new_function(...)
    ]

I noticed you have quite a number of dictionary accesses in the list comprehension. Writing the code as above might make it too chunky. There are some ways to solve the problem.

convert it to a for loop and skip None values
do a second pass to your first list generated by list comprehension, filtering out ones that contain None. (not very efficient)
make your _how_mush...to_spend() return a tuple[int, int] where the first int is 1 if valid or 0 if invalid, or otherwise to fit your sorting. The second int will be what that function were returning originally.

Merge master
If you ran the tests and they all pass, then there isn't likely to be anything very wrong. But I'll check manually when doing the code review.

Please let me know when the pull request is ready to be reviewed again. Have a good day/night.

I think review needed later. BIG_INT and one bug fixed.
But I didn't get list of dices from proper location (now it is in module variables in dices.py and it repeat list in classes). Also code about OMNI filling enough overcomplicated for me, however.
By the way, how to make autopep8 format code with
def big_function(
    a,
    b,
    c,
    d,
    e
)

style, not
def big_function(
    a,
     ....
    e)

?

Regarding the styling, I do it manually. (sorry this isn't very helpful)

But I didn't get list of dices from proper location (now it is in module variables in dices.py and it repeat list in classes). Also code about OMNI filling enough overcomplicated for me, however.

I don't quite get what you mean above (^). Please quote relevant code or provide more context. Thanks.

I use the following constant
https://github.com/Jarvis-Yu/Dottore-Genius-Invokation-TCG-Simulator/blob/244f8fbdd29ac741ca242f3bd0937679964cc987/dgisim/src/dices.py#L40

instead of existing
https://github.com/Tookser/Dottore-Genius-Invokation-TCG-Simulator/blob/244f8fbdd29ac741ca242f3bd0937679964cc987/dgisim/src/dices.py#L220
, probably it is better to use it...

This part of code

https://github.com/Jarvis-Yu/Dottore-Genius-Invokation-TCG-Simulator/blob/244f8fbdd29ac741ca242f3bd0937679964cc987/dgisim/src/dices.py#L369
(filling OMNI need) is big and requires refactoring. May be I'll try to do it on the next weekend.

Got it.
Regarding the first point 1., declaring them in class as a class variable is the same as declaring them directly in the module. As they are used only by the dices selection algorithm, it it better to put them inside the class. Also, these constants don't need to be in __all__ for now, and mark them private by naming them starting with _ like _ELEMENTS_ORDERD.
class WhatEver:
    value = complex_calculation()  # computed once and shared among instances of this class

Once again, appreciate your help.

I ask you for review.

Hello!
I fixed all remarks, please, review.

Fixed all except order of step, write reasons above.

The motive for me to suggest the reordering of the first two steps is the function below:
    @staticmethod
    def _omni_filler_priority(*,  # btw the format of this method doesn't look like any other method in the project
                              omni_supply: int,
                              omni_needed: int,
                              element_supply: int,
                              element_needed: int,
                              element_prioritized: bool
                              ) -> tuple[int, int]:
        ...

Whenever I review your code, it always takes me a while to figure out the logic behind this part. It works of course, just imo not very straight forward.
So in the function, there's this section of code:
            if element_prioritized:
                return element_needed + omni_needed, element_needed + omni_needed - element_supply
            else:
                omni = max((element_needed + omni_needed) - element_supply, 0)

The logic above takes the element_needed into account, making the overall logic more complex if the element_needed is not a problem. So why is element_needed a problem? It is because you need to fill up the pure elements later.
So if you fill up the pure elements first, and then the OMNI requirement. Then the def _omni_filler_priority() method doesn't need to take the parameter element_needed (and even omni_supply can be omitted).
So imo, the function can be simplified to:
def _omni_filler_priority(omni_needed: int, element_supply: int, element_prioritized: bool) -> tuple[int, int]:
    """
    Returns the tuple[
        OMNI required + first-priority elem spent to fill OMNI,
        OMNI required
    ]
    """
    actual_omni_needed = max(0, omni_needed - element_supply)
    return (
        omni_needed if element_prioritized else actual_omni_needed,
        actual_omni_needed,
    )

So your elem_cost_mapping will be like:
elem_cost_mapping: list[tuple[Element, tuple[int, int]]] = [
    (
        elem,
        self._omni_filler_priority(need[Element.OMNI], supply[elem], elem in first_priority_elements),
    )
    for elem in _PURE_ELEMS
    if supply[Element.OMNI] >= need[Element.OMNI] - supply[elem]

Anyways, this is just my personal opinion that the reordered steps makes the logic clearer, you are free to keep your code as it is right now, and I'll still accept it in this Pull Request.

Hello!
I didn't forget. I don't know if steps reordering is possible, because in my opinion distribution of pure elements depends on choice of omni-filler element. I understand your point a little more now, I think it will be okay if I save this commit (tag it in local repo) and then try to rewrite code. If current tests will succeed, then it will be ready for merge.

Hello!
I'm sorry. I think I can't rewrite this code now, too much work at my job. So I think it can be merged, maybe somebody (maybe I) can rewrite it later.
Sorry :-(

Understood, thanks a lot for all your help. I'll merge the PR shortly. Have a nice day!


DO NOT MERGE: Swift 3.1 test modules revert

First step trying to bisect a modules issue.

@swift-ci please test


delete snapshots with no corresponding test

Refs #1925
This doesn't introduce anything that will fail if we prune, as requested in #1925 (I don't think snap-shot-it has this feature) but it does remove the snapshots with no corresponding test.

Messages

:book:

:sparkles: Thanks for your contribution to Shields, @chris48s!

  Generated by :no_entry_sign: dangerJS


WIP: Add OpenAPI parameter-processing util method (and test)

OpenAPI supports multiple values for named parameters, using various formats. (For some background, see
https://swagger.io/docs/specification/describing-parameters/
https://swagger.io/docs/specification/serialization/
https://www.ibm.com/support/knowledgecenter/en/SS4SVW_beta/designing/api_defining_mapping_http_parameters.html)
This PR adds a utility method to the Helidon OpenAPI project that developers can use to parse such a multi-valued parameter into a List.
The utility method will also be used in the generated Helidon SE classes from the OpenAPI generator tooling.

Thanks to @batsatt for the review comments so far. I have marked this as WIP to forestall further reviews -- for the moment -- because I plan to improve the utility class to be even more helpful in dealing with the different locations (e.g., path, query, header, cookie), styles (simple, label, matrix), and explode (t/f) settings.
Doing so will further simplify the OpenAPI generator template for Helidon SE as well as be more useful to developers not using the generator who want to deal with endpoint parameters.
Stay tuned.


SPYWARE CYBER-LEGIT CRYPTO RECOVERY AGENCY

The way I Reclaimed My 260,000 Bitcoin Again Employing  Spyware Cyber soon after It Had been Robbed
When I first began investing in Bitcoin over a decade ago, I never could have imagined how valuable my holdings would become. At the time, I purchased around 260,000 Bitcoin for just pennies apiece. As the price of Bitcoin skyrocketed over the years, reaching a peak of nearly $20,000 per coin, my modest investment transformed into a fortune worth over $5 billion. I was ecstatic about this windfall, but also anxious about properly securing my newfound wealth. Unfortunately, despite my best efforts at protecting my private keys, a hacker was able to gain access and empty my entire Bitcoin wallet, robbing me of my hard-earned fortune. I was devastated when I discovered the theft. I felt like I had lost a limb as my net worth evaporated overnight. However, I refused to accept defeat. After months of digging, I finally uncovered a potential path to reclaiming my coins. A cryptographic wizard known only as  Spyware Cyber  had a reputation for helping victims recover stolen cryptocurrency when all other options were exhausted. I was skeptical at first, but the testimonials checked out. Spyware Cyber  revolutionary recovery technology exploited flaws in blockchain security to essentially rewrite transaction histories and revert stolen funds back to their rightful owners.  Spyware Cyber went to work on penetrating the thief's wallet security utilizing this novel technique. Incredibly, after several grueling weeks, I logged into my Bitcoin wallet one morning to see my massive holdings restored in full. Thanks to Spyware Cyber miraculous skills, I had reclaimed my $5 billion fortune once again! The joy of having my life's work returned was indescribable. I learned my lesson about properly securing cryptocurrency the hard way, but now I truly understand the meaning of perseverance paying off. With my Bitcoin back under my control, I look forward to prudently managing and growing my wealth once more.  I was lured in by the promise of earning 20% on each trade. Unfortunately, the platform turned out to be a scam, and I lost all my funds.
After weeks of feeling devastated, I found TREK Tech Corp, a cryptocurrency recovery expert. I reached out to their support team, explaining my situation. They asked for some information, and within 12 hours, they had traced, tracked, and recovered all my stolen funds without any hassle or hidden charges. It was a relief to have my money back.
If you've lost cryptocurrency due to scams or fraud, TREK Tech Corp is the best team to help you recover your digital assets.
Contact email<EMAIL_ADDRESS>/<EMAIL_ADDRESS>


terraform state output as .Values

Thoughts on adding support for terraform as a temptable values data source?  Opening this to think through design and integration.
An opposite option would be to have a terraform helmfile provider where the provider can pass in additional variables to helmfile.

My vote is for option 2: terraform-helmfile-provider

I second option 2

Option 3: Implement gomplate datasource that reads terraform states

I would like to see generic data source support.  So we could at sometime have terraform state, vault, etc support.  Personally I'm not overly fond of the terraform provider approach.

The reason why I am fond of the terraform provider approach is the majority of our Helmfiles depend on resources we can only provision with terraform. For example, IAM roles, RDS clusters, S3 buckets, EFS filesystems. With a Helmfile provider we could easily provision a service along with its dependencies in one phase.
On the other hand, today we need to provision those things in 2 different phases and pass the values between them.
I would much rather distribute a terraform module that provisioned a service e2e with all dependencies, both those in Kubernetes (helm) and those outside (IAM roles, etc)

@osterman Yeah that makes sense!
Probably loading terraform outputs is just for ease of interoperability for anyone wants Helmfile as the entry point for k8s deployments. The terraform-provider approach is for managing your whole infra as a whole while leveraging helmfile as a module.
How about forking a dedicated issue for the provider approach and moving towards actually implementing it?

@sstarcher, @mumoshu has now made this possible with https://github.com/mumoshu/terraform-provider-helmfile

JFYI @sstarcher, For the generic data source support you've suggested earlier, we already have vals integration in Helmfile.
https://github.com/variantdev/vals
#906
Terraform states/ouputs are planned but not implemented. For other sources like AWS SSM, SeceretsManager, Vault, SOPS, you can use the vals integration.

I wonder how come this feature is not in higher demand.
I believe most of the community is using Terraform and it would be great if you could use its state as a source for variables such as IAM role, security group ID, etc.
The Helm provider is not a viable solution since it does not provide the diff output.
The Helmfile provider also does not provide a proper diff output - [https://github.com/mumoshu/terraform-provider-helmfile/issues/7#issue-547532834]
Perhaps it is possible to read the Terraform state using the exec function and template the values file accordingly?

Really very weird to not put this feature at the top of the top of priority !

As another data point, we prefer to decouple these. What we end up doing is using the tf template provider to create a yaml file as output that represents the state of the infra at that specific apply point and then bring that into the process for helmfile. Pretty similar approach (using outputs from tf to supply to helmfile) — just a matter of preference I think.
There are enough other features in helmfile that could stand to be added/improved, this seems an odd one to advocate for when there are very easy (and stable/safe) approaches already out there.

Thanks @kyounger, I like your approach :)
Btw, we already have the terraform output as values. Try using ref+tfstate as documented in https://github.com/variantdev/vals#terraform-tfstate

Hi @mumoshu,
I've tried using vals with ref+tfstate and got the following error: no provider registered for scheme "tfstate"

@dudicoco Thx for reporting. I believe that's fixed in v0.120.0. Would you mind testing it out?

@mumoshu I've tested it with  v0.120.0 and can confirm that it's working!
Two issues though:

The tfstate must be a local file - is it possible to use a remote backend such as S3?
Is it possible to read from the state outputs block rather than the resources block?

Thanks

@dudicoco Thanks!
Regarding the remote backend and the outputs, I've updated the documentation to cover those. Please refer to https://github.com/variantdev/vals#terraform-tfstate

Thanks @mumoshu
I wasn't able to get the remote backend to work with the following backend configuration:
{
  "backend": {
    "type": "s3",
    "config": {
      "bucket": "terraform",
      "region": "us-east-1",
      "key": "path/file.tfstate"
    }
  }
}

Getting the following error:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1d71e0e]

goroutine 543 [running]:
github.com/fujiwara/tfstate-lookup/tfstate.(*TFState).Lookup(0x0, 0xc000270e9c, 0x17, 0x275d920, 0xc00009be60, 0xc000270e9c)
	/home/circleci/workspace/helmfile/vendor/github.com/fujiwara/tfstate-lookup/tfstate/lookup.go:167 +0x8e
github.com/variantdev/vals/pkg/providers/tfstate.(*provider).GetString(0x31ebc58, 0xc000270e80, 0x33, 0x0, 0x0, 0xc000270e00, 0x33)
	/home/circleci/workspace/helmfile/vendor/github.com/variantdev/vals/pkg/providers/tfstate/tfstate.go:33 +0x193
github.com/variantdev/vals.(*Runtime).Eval.func3(0xc00003c554, 0x3d, 0x41, 0xc000270e40, 0x8, 0x8)
	/home/circleci/workspace/helmfile/vendor/github.com/variantdev/vals/vals.go:237 +0xe57
github.com/variantdev/vals/pkg/expansion.(*ExpandRegexMatch).InString(0xc0003c3238, 0xc00003c550, 0x41, 0xc00039e018, 0x104993e, 0xc000039768, 0x10)
	/home/circleci/workspace/helmfile/vendor/github.com/variantdev/vals/pkg/expansion/expand_match.go:40 +0xe1
github.com/variantdev/vals/pkg/expansion.(*ExpandRegexMatch).InMap.func1(0xc00003c550, 0x41, 0xc000038730, 0xc00039e030, 0x10e2351, 0xc0008cc040)
	/home/circleci/workspace/helmfile/vendor/github.com/variantdev/vals/pkg/expansion/expand_match.go:52 +0x42
github.com/variantdev/vals/pkg/expansion.ModifyStringValues(0x1f51300, 0xc00082cbf0, 0xc00039f1d0, 0x1f51300, 0xc00082cbf0, 0xc000039700, 0x0)
	/home/circleci/workspace/helmfile/vendor/github.com/variantdev/vals/pkg/expansion/maputil.go:42 +0xe3e
github.com/variantdev/vals/pkg/expansion.ModifyStringValues(0x1ffb7e0, 0xc0001de060, 0xc0003c31d0, 0x1ffb7e0, 0xc0001de060, 0x0, 0x0)
	/home/circleci/workspace/helmfile/vendor/github.com/variantdev/vals/pkg/expansion/maputil.go:60 +0xb54
github.com/variantdev/vals/pkg/expansion.ModifyStringValues(0x1ffb7e0, 0xc0001de000, 0xc0003c31d0, 0x1ffb7e0, 0xc0001de000, 0xc000039600, 0x0)
	/home/circleci/workspace/helmfile/vendor/github.com/variantdev/vals/pkg/expansion/maputil.go:60 +0xb54
github.com/variantdev/vals/pkg/expansion.ModifyStringValues(0x1ffb7e0, 0xc000503f80, 0xc0003c31d0, 0x1ffb7e0, 0xc000503f80, 0xc000039600, 0x0)
	/home/circleci/workspace/helmfile/vendor/github.com/variantdev/vals/pkg/expansion/maputil.go:60 +0xb54
github.com/variantdev/vals/pkg/expansion.ModifyStringValues(0x1ffb7e0, 0xc000503f50, 0xc0003c31d0, 0x1ffb7e0, 0xc000503f50, 0x0, 0x0)
	/home/circleci/workspace/helmfile/vendor/github.com/variantdev/vals/pkg/expansion/maputil.go:60 +0xb54
github.com/variantdev/vals/pkg/expansion.ModifyStringValues(0x1ffb7e0, 0xc000503ec0, 0xc0003c31d0, 0x1ffb7e0, 0xc000503ec0, 0xc000136500, 0x0)
	/home/circleci/workspace/helmfile/vendor/github.com/variantdev/vals/pkg/expansion/maputil.go:60 +0xb54
github.com/variantdev/vals/pkg/expansion.ModifyStringValues(0x1ffea20, 0xc000503e90, 0xc0003c31d0, 0x0, 0xc00039f260, 0x13a5619, 0xc00039f2a0)
	/home/circleci/workspace/helmfile/vendor/github.com/variantdev/vals/pkg/expansion/maputil.go:83 +0x2d6
github.com/variantdev/vals/pkg/expansion.(*ExpandRegexMatch).InMap(0xc00039f238, 0xc000503e90, 0x0, 0xc000150000, 0x1f215a0)
	/home/circleci/workspace/helmfile/vendor/github.com/variantdev/vals/pkg/expansion/expand_match.go:51 +0x66
github.com/variantdev/vals.(*Runtime).Eval(0xc000502ae0, 0xc000503e90, 0x4f6, 0x1f215a0, 0xc0003940f8)
	/home/circleci/workspace/helmfile/vendor/github.com/variantdev/vals/vals.go:286 +0xcd
github.com/roboll/helmfile/pkg/state.(*HelmState).RenderValuesFileToBytes(0xc000135680, 0xc000270c40, 0x39, 0x6, 0xc000270980, 0x39, 0xc00082c720, 0x1)
	/home/circleci/workspace/helmfile/pkg/state/state.go:1839 +0x34a
github.com/roboll/helmfile/pkg/state.(*HelmState).generateTemporaryValuesFiles(0xc000135680, 0xc000260c20, 0x2, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
	/home/circleci/workspace/helmfile/pkg/state/state.go:1918 +0x90b
github.com/roboll/helmfile/pkg/state.(*HelmState).generateVanillaValuesFiles(0xc000135680, 0xc0002f8280, 0x0, 0x0, 0x0, 0x0, 0xc0000d38f0)
	/home/circleci/workspace/helmfile/pkg/state/state.go:1975 +0x279
github.com/roboll/helmfile/pkg/state.(*HelmState).generateValuesFiles(0xc000135680, 0x279d1c0, 0xc000978100, 0xc0002f8280, 0x1, 0xc000260b40, 0x0, 0x2, 0x4, 0x21fefdd)
	/home/circleci/workspace/helmfile/pkg/state/state.go:2013 +0x4d
github.com/roboll/helmfile/pkg/state.(*HelmState).namespaceAndValuesFlags(0xc000135680, 0x279d1c0, 0xc000978100, 0xc0002f8280, 0x1, 0xc0009042c0, 0x4, 0x4, 0x0, 0x0, ...)
	/home/circleci/workspace/helmfile/pkg/state/state.go:2036 +0xb1
github.com/roboll/helmfile/pkg/state.(*HelmState).flagsForDiff(0xc000135680, 0x279d1c0, 0xc000978100, 0xc0002f8280, 0x1, 0x0, 0x0, 0x60, 0x60, 0xc0001462a0, ...)
	/home/circleci/workspace/helmfile/pkg/state/state.go:1782 +0x181
github.com/roboll/helmfile/pkg/state.(*HelmState).prepareDiffReleases.func2(0x1)
	/home/circleci/workspace/helmfile/pkg/state/state.go:1063 +0x370
github.com/roboll/helmfile/pkg/state.(*HelmState).scatterGather.func1(0xc000828180, 0xc0000386b0, 0x1)
	/home/circleci/workspace/helmfile/pkg/state/state_run.go:41 +0x30
created by github.com/roboll/helmfile/pkg/state.(*HelmState).scatterGather
	/home/circleci/workspace/helmfile/pkg/state/state_run.go:40 +0x195

@mumoshu please disregard my last comment, my AWS credentials expired.
I  was able to use the tfstate feature with s3 backend, working as expected.
Thank you for this amazing feature! I believe this issue can be closed.

@dudicoco Glad it worked for you. Thanks for confirmation ☺

we just use local_file in terraform with sensitive_content to not show anything in the logs. This local yaml file is than used in helmfile.


Adding support for sending multipart forms

added support for F or form flag in reference to Issue #12

Hi @aki237!
Thank you so much for all the great PRs!  This one is conflicting with your last merged PR unfortunately; I'd like to ask you to reconcile this please, then I can merge it. :-)
Thanks again!

Sure I'll work on it once I reach my home.
On 22-Oct-2017 5:43 PM, "David J Peacock"<EMAIL_ADDRESS>wrote:

Hi @aki237 https://github.com/aki237!
Thank you so much for all the great PRs! This one is conflicting with your
last merged PR unfortunately; I'd like to ask you to reconcile this please,
then I can merge it. :-)
Thanks again!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/davidjpeacock/kurly/pull/62#issuecomment-338472760,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIK_llxBxp5tdmx6yBl4z0hQsD3q8snwks5suzGFgaJpZM4P-_n2
.

I think I have resolved the  merge conflicts by merging your master to my form-support branch. Can you check if it merges fine?


Allow renaming tabs

Closes https://github.com/GraphiteEditor/Graphite/issues/1854

The renaming works, however some other part of the app sometimes throws an error after a document got renamed:
graphite_wasm.js:1255 error
frontend/wasm/src/editor_api.rs:114While handling FrontendMessage ""UpdatePropertyPanelOptionsLayout"",
JavaScript threw an error: JsValue(TypeError: Cannot use 'in' operator to search for 'columnWidgets' in undefinedTypeError: Cannot use 'in' operator to search for 'columnWidgets' in undefined
at http://localhost:8080/src/wasm-communication/messages.ts:753:27
at Array.reduce (<anonymous>)
at http://localhost:8080/src/wasm-communication/messages.ts:752:42
at Array.forEach (<anonymous>)
at patchWidgetLayout (http://localhost:8080/src/wasm-communication/messages.ts:751:16)
at http://localhost:8080/src/components/panels/Properties.svelte?t=1725132032461:286:4
at callCallback (http://localhost:8080/src/wasm-communication/subscription-router.ts:25:9)    at Object.handleJsMessage (http://localhost:8080/src/wasm-communication/subscription-router.ts:33:5)    at http://localhost:8080/src/wasm-communication/editor.ts:18:19
at http://localhost:8080/wasm/pkg/graphite_wasm.js:2388:37)

Sorry, in bed yesterday I noticed that the renaming should be cancel-able.
The PR notifications remembered me to implement that

It may be a few days before I can commit some changes that you can rely on to fix this so it behaves the same as layer renaming. I need to focus on other code priorities but I'll try to do that soon.

@Keavon what is your status on this?

I haven't had time yet. It's probably a couple hours of work, but this feature isn't a priority since it adds no new functionality, so it hasn't been where I've put my focus in the past days. I'll try to avoid letting this rot for too long though.

Actually, on further thought, the hard part isn't what's done by this PR— it's the generalizing of the existing components. It requires unifying how the TextInput and TextLabel can behave like one another to support the exact renaming behavior seen currently, and as of yet exclusively, for layers in the Layers panel. Since, unfortunately, this PR doesn't take that approach, it isn't suitable for merging in its current state. But once I'm able to unify the behaviors of those two components and replace how it's used in the Layers panel, adding it to the document tab and sending that to the backend is about 10 minutes of work and would probably only use a few lines of code present in this PR. So it wouldn't actually make much sense to keep this PR around and reuse it when I have time for that, whenever that might be. The reality is that this is just a tricky frontend task that seems simple but isn't, so I don't suggest having it as a community-contributed task. Hopefully you got to learn a bit about the backend <-> frontend communication in this process, and sorry to waste your time with this @vdawg-git.

All good and thank you for the detailed explanation


Adjustable height

I found https://github.com/coroo/nova-chartjs/issues/64 but it is from 2 years ago. Trying to adjust height via the card does not appear to work.
There's this:
https://github.com/coroo/nova-chartjs/blob/f6603f5767d3deeb531340e71995cdc732d97b2f/resources/js/stripe-chart.vue#L15-L20
but it's not passed from https://github.com/coroo/nova-chartjs/blob/master/resources/js/components/StripeChart.vue unless I'm missing something here. Some guidance would be greatly appreciated.

As a workaround you can do this:

#nova canvas#line-chart {
  height: 70vh !important;
}

is there an update on when the height issue will be resolved, having charts be only 120px tall is a pretty large regression especially when trying to render lots of data sets


Updated the package source resource to accept credentials and updated…

… the code to be more readable
Signed-off-by: John McCrae<EMAIL_ADDRESS>
Description

Related Issue

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Chore (non-breaking change that does not add functionality or fix an issue)

Checklist:

[ ] I have read the CONTRIBUTING document.
[ ] I have run the pre-merge tests locally and they pass.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.
[ ] All commits have been signed-off for the Developer Certificate of Origin.

Can we change the description on line 28 to: Use the **powershell_package_source** resource to register a PowerShell package source and a Powershell package provider.


Functional Testing for Calendar

Key points:

[x] Test all the baseline policies
[x] Test different use cases and edge cases
[ ] For each policy verify if the output as expected when the tests pass/fail
[x] For policies with multiple settings check that only the expected sub-policy will pass/fail and the other
[x] dependent/independent policies are unaffected
[x] Perform tests to verify multiple OU and OU inheritance settings wherever applicable
[ ] Perform tests to verify Group settings wherever applicable
[x] Report and file bugs for any issues found

Testing complete. One bug found, logged as https://github.com/cisagov/ScubaGoggles/issues/395.


[Bug] Editing multiple items causes an error

When checking two items and editing those selected items, any changes to the attributes will result in an error when saving.
To Reproduce:
Selecting 2 prefixes with the checkbox
Editing those prefixes
Changing any attribute
Saving
Results in:
Server Error
There was a problem with your request. This error has been logged and administrative staff have been notified. Please return to the home page and try again.
Per Stretch in IRC 'Status' is missing from the form

This bug was introduced when prefix/VLAN statuses were changed from custom objects to a static ChoiceField (pre-1.0.0). Need to correct the forms to re-include the status field.


add instructions for mdbook docs

I'm submitting a

[ ] bug fix
[ ] feature
[x] documentation addition

Add some instructions to the README.md on how to utilize the mdbook documentation.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (f4fd2c1) 28.26% compared to head (6cf7f10) 28.26%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #386   +/-   ##
=======================================
  Coverage   28.26%   28.26%
=======================================
  Files          85       85
  Lines        2289     2289
=======================================
  Hits          647      647
  Misses       1642     1642

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


GSO fails on some platforms / interfaces

I'm seeing a lot of INTERNAL_ERROR (local): write udp [::]:443->[REDACTED]:42830: sendmsg: invalid argument on the server side, causing the connection to be disconnected. They only happen when the clients are aarch64 (raspberry pi).
Could this be related to the GSO change?

GSO would have been my first guess as well. I suspect that for some reason we manage to enable GSO, but don't correctly recognize that it was successfully enabled. This then causes the failure you're seeing because once enabled, the kernel expects the segment length message for the sendmsg to be set: https://github.com/quic-go/quic-go/blob/21388c86bb2be0de9b5468d8b77f37281b64fcf0/sys_conn_df_linux.go#L70-L83
Can you try manually disabling GSO via the QUIC_GO_DISABLE_GSO environment variable?
https://github.com/quic-go/quic-go/blob/21388c86bb2be0de9b5468d8b77f37281b64fcf0/sys_conn_df_linux.go#L46-L50
This should make the failure go away.
If it's actually due to GSO, can you confirm if the syscall to enable it is successful in
https://github.com/quic-go/quic-go/blob/21388c86bb2be0de9b5468d8b77f37281b64fcf0/sys_conn_df_linux.go#L52-L57

If my suspicion is correct, this would mean that we can't rely on the return value of the syscall that enables GSO. Maybe we need to instead read the value back using GetSockoptInt in maybeSetGSO?

It is indeed GSO:
With QUIC_GO_DISABLE_GSO on v0.36.0:
$ sudo k3s kubectl -n kube-system logs deployment/specter-tunnel -f
{"level":"info","ts":1687509533.946454,"caller":"client/client.go:150","msg":"Connected to specter server","id":8319038888190,"addr":"..."}
{"level":"info","ts":1687509534.009357,"caller":"client/client.go:366","msg":"Reusing existing client certificate","id":8319038888190,"identity":{"id":8319038888190,"token":"..."}}
{"level":"info","ts":1687509534.8210588,"caller":"client/client.go:150","msg":"Connected to specter server","id":8319038888190,"addr":"..."}
{"level":"info","ts":1687509535.0624511,"caller":"client/client.go:150","msg":"Connected to specter server","id":8319038888190,"addr":"..."}
{"level":"info","ts":1687509535.062558,"caller":"client/client.go:105","msg":"Waiting for RTT measurement...","id":8319038888190,"max":3}
{"level":"info","ts":1687509537.8524847,"caller":"client/client.go:465","msg":"Synchronizing tunnels in config file with specter","id":8319038888190,"tunnels":3}
// ...
{"level":"info","ts":1687509540.0839405,"caller":"client/client.go:734","msg":"Listening for tunnel traffic","id":8319038888190}
{"level":"info","ts":1687509540.0855958,"caller":"client/server.go:210","msg":"Local server started","id":8319038888190,"listen":"[::]:1180"}

Without QUIC_GO_DISABLE_GSO on v0.36.0:
$ sudo k3s kubectl -n kube-system logs deployment/specter-tunnel -f
{"level":"info","ts":1687509601.2167587,"caller":"client/client.go:150","msg":"Connected to specter server","id":8319038888190,"addr":"..."}
{"level":"info","ts":1687509601.2458448,"caller":"client/client.go:366","msg":"Reusing existing client certificate","id":8319038888190,"identity":{"id":8319038888190,"token":"..."}}
{"level":"info","ts":1687509601.846103,"caller":"client/client.go:150","msg":"Connected to specter server","id":8319038888190,"addr":"..."}
{"level":"info","ts":1687509602.3856218,"caller":"client/client.go:150","msg":"Connected to specter server","id":8319038888190,"addr":"..."}
{"level":"info","ts":1687509602.3857913,"caller":"client/client.go:105","msg":"Waiting for RTT measurement...","id":8319038888190,"max":3}
{"level":"info","ts":1687509604.3391526,"caller":"client/client.go:465","msg":"Synchronizing tunnels in config file with specter","id":8319038888190,"tunnels":3}
{"level":"error","ts":1687509604.3451564,"caller":"client/client.go:470","msg":"Failed to query available hostnames","id":8319038888190,"error":"twirp error internal: failed to do request: Post \"https://specter-dfw-0.host.con.nect.sh:443/twirp/protocol.TunnelService/RegisteredHostnames\": INTERNAL_ERROR (local): write udp [::]:39575->[REDACTED]:443: sendmsg: invalid argument","stacktrace":"kon.nect.sh/specter/tun/client.(*Client).SyncConfigTunnels\n\t/app/tun/client/client.go:470\nkon.nect.sh/specter/tun/client.(*Client).Initialize\n\t/app/tun/client/client.go:109\nkon.nect.sh/specter/cmd/client.cmdTunnel\n\t/app/cmd/client/tunnel.go:115\ngithub.com/urfave/cli/v2.(*Command).Run\n\t/go/pkg/mod/github.com/urfave/cli/v2@v2.25.7/command.go:274\ngithub.com/urfave/cli/v2.(*Command).Run\n\t/go/pkg/mod/github.com/urfave/cli/v2@v2.25.7/command.go:267\ngithub.com/urfave/cli/v2.(*Command).Run\n\t/go/pkg/mod/github.com/urfave/cli/v2@v2.25.7/command.go:267\ngithub.com/urfave/cli/v2.(*App).RunContext\n\t/go/pkg/mod/github.com/urfave/cli/v2@v2.25.7/app.go:332\nmain.main\n\t/app/main.go:15\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:250"}

This is with debug printout:
$ sudo k3s kubectl -n kube-system logs deployment/specter-tunnel -f
{"level":"info","ts":1687510239.739196,"caller":"quic-go@v0.28.2-0.20230622082411-87dbaf5cbef0/sys_conn_df_linux.go:58","msg":"!! DEBUG !! setErr: <nil>","subsystem":"unknown"}
// ...
{"level":"error","ts":1687510243.1822891,"caller":"client/client.go:521","msg":"Failed to publish tunnel","id":8319038888190,"hostname":"jenkins.box.s0c.net","target":"http://jenkins-service.devops-tools.svc.cluster.local:8080","endpoints":3,"error":"twirp error internal: failed to do request: Post \"https://[REDACTED]:443/twirp/protocol.TunnelService/PublishTunnel\": INTERNAL_ERROR (local): write udp [::]:54254->[REDACTED]:443: sendmsg: invalid argument","stacktrace":"kon.nect.sh/specter/tun/client.(*Client).SyncConfigTunnels\n\t/app/tun/client/client.go:521\nkon.nect.sh/specter/tun/client.(*Client).Initialize\n\t/app/tun/client/client.go:109\nkon.nect.sh/specter/cmd/client.cmdTunnel\n\t/app/cmd/client/tunnel.go:115\ngithub.com/urfave/cli/v2.(*Command).Run\n\t/go/pkg/mod/github.com/urfave/cli/v2@v2.25.7/command.go:274\ngithub.com/urfave/cli/v2.(*Command).Run\n\t/go/pkg/mod/github.com/urfave/cli/v2@v2.25.7/command.go:267\ngithub.com/urfave/cli/v2.(*Command).Run\n\t/go/pkg/mod/github.com/urfave/cli/v2@v2.25.7/command.go:267\ngithub.com/urfave/cli/v2.(*App).RunContext\n\t/go/pkg/mod/github.com/urfave/cli/v2@v2.25.7/app.go:332\nmain.main\n\t/app/main.go:15\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:250"}

GetsockoptInt won't work because it will read back the value correctly:
$ sudo k3s kubectl -n kube-system logs deployment/specter-tunnel -f
{"level":"info","ts":1687510849.0587795,"caller":"quic-go@v0.36.1-0.20230622083630-75a709765faa/sys_conn_df_linux.go:64","msg":"!! DEBUG !! GetsockoptInt: 1, err: <nil>","subsystem":"unknown"}

Like so:
	var setErr error
	if err := rawConn.Control(func(fd uintptr) {
		setErr = unix.SetsockoptInt(int(fd), syscall.IPPROTO_UDP, UDP_SEGMENT, 1)
	}); err != nil {
		setErr = err
	}
	if setErr != nil {
		log.Println("failed to enable GSO")
		return false
	}
	rawConn.Control(func(fd uintptr) {
		val, err := unix.GetsockoptInt(int(fd), syscall.IPPROTO_UDP, UDP_SEGMENT)
		log.Printf("!! DEBUG !! GetsockoptInt: %+v, err: %+v\n", val, err)
	})

Could this be the kernel not supporting GSO fully? On the client, they are running inside docker but on aarch64 hosts, also they are raspberry pi. On the server, the server complaining about invalid argument is also aarch64 but they are Ampere Altra, although in a VM.

Thank you! I would’ve expected the SetSockoptInt to fail in that case, but maybe that’s not how it works?
Any idea how we could determine if GSO is actually available? Seems like we can neither trust SetSockoptInt nor GetSockoptInt. And the „invalid argument“ error is also pretty unspecific, otherwise we could do some kind of error assertion.

I think the argument might be incorrect: https://github.com/torvalds/linux/blob/master/tools/testing/selftests/net/udpgso.c
The value is not 1 or 0 but the size it seems

we have the same issue with Chromebooks (Linux vm in Chromebook).
GSO breaks with IPv6 and works fine with IPv4.
Cloudflare quiche has the same issue (but we have not tested it as much as with quic-go).
To test for GSO, quiche use "1350"  instead of "1" but I've tried to change this in quic-go and the error is still there. (see detect_gso definition and calls)

the issues seems to detect if GSO works ALSO with IPv6.

@jfgiorgi Does the error occur immediately, or only when DPLPMTUD kicks in and attempts to send a packet larger than 1350 bytes (maybe minus IP / UDP header?).

immediately.
here an example with h3ctx (https://github.com/kgersen/h3ctx) with QUIC_GO_LOG_LEVEL set to DEBUG.
to reproduce: QUIC_GO_LOG_LEVEL=DEBUG go run main.go -6 -noh2
    ...
    downloading https://localhost:2222/10000000000
    HTTP3 dialing localhost:2222 -> [::1]:2222
    2023/06/23 20:52:50 Setting DF for IPv4 and IPv6.
    2023/06/23 20:52:50 Activating reading of ECN bits for IPv4 and IPv6.
    2023/06/23 20:52:50 Activating reading of packet info for IPv4 and IPv6.
    QUIC: connected to [::1]:2222 from [::]:44040 (ids=a6e73f9b-da30a13223924d2301b0c6fae1bf)
    2023/06/23 20:52:50 client Starting new connection to localhost ([::]:44040 -> [::1]:2222), source connection ID a6e73f9b, destination connection ID da30a13223924d2301b0c6fae1bf, version v1
    2023/06/23 20:52:50 Adding connection ID a6e73f9b.
    2023/06/23 20:52:50 Increased receive buffer size to 4096 kiB
    2023/06/23 20:52:50 client Not doing 0-RTT.
    2023/06/23 20:52:50 client -> Sending packet 0 (1232 bytes) for connection da30a13223924d2301b0c6fae1bf, Initial
    2023/06/23 20:52:50 client      Long Header{Type: Initial, DestConnectionID: da30a13223924d2301b0c6fae1bf, SrcConnectionID: a6e73f9b, Token: (empty), PacketNumber: 0, PacketNumberLen: 2, Length: 1204, Version: v1}
    2023/06/23 20:52:50 client      -> &wire.CryptoFrame{Offset: 0, Data length: 260, Offset + Data length: 260}
    2023/06/23 20:52:50 client Destroying connection with error: write udp [::]:44040->[::1]:2222: sendmsg: invalid argument
    2023/06/23 20:52:50 Removing connection ID a6e73f9b.
    2023/06/23 20:52:50 client Connection da30a13223924d2301b0c6fae1bf closed.
    closing local quic transport
    client error for https://localhost:2222/10000000000: Get "https://localhost:2222/10000000000": INTERNAL_ERROR (local): write udp [::]:44040->[::1]:2222: sendmsg: invalid argument

    server :2222 shuting down

h3ctx is a client and a server. in this mode, the client tries to connect and get sendmsg: invalid argument immediatly. Nothing is logged server side.
I don't know if this can help but you might want to take a look at how msquic solved this: https://github.com/microsoft/msquic/issues/1360
They also have RSS and Receive Batching implemented which could be nice to have in quic-go

@marten-seemann can we recall the 0.36.0 release? Folks not knowing gso might explode may have their system explodes if they upgraded to 0.36.0 mistakenly

@marten-seemann can we recall the 0.36.0 release? Folks not knowing gso might explode may have their system explodes if they upgraded to 0.36.0 mistakenly

I'm considering it, unless we can figure out a patch within the next day or so. Alternatively, we could also flip the environment variable to QUIC_GO_ENABLE_GSO, so we don't have to recall all the other GSO-unrelated fixes.
cc @mholt @francislavoie, just so you're aware, you'll most likely receive another PR with a patch for Caddy soon.

I don't know if this can help but you might want to take a look at how msquic solved this: https://github.com/microsoft/msquic/issues/1360

@kgersen The fallback is actually not the big problem. I'm fine falling back to a simple sendmsg on systems that don't support GSO for now. The problem is detecting if we're on such a system. Unfortunately, the kernel doesn't give us an error message that says "I don't like that UDP_SEGMENT message you gave me".

I think the argument might be incorrect: https://github.com/torvalds/linux/blob/master/tools/testing/selftests/net/udpgso.c
The value is not 1 or 0 but the size it seems

@zllovesuki Could you try setting the value to 1400 or so and see if that fixes the problem?

Does anyone have any pointer for me how to reproduce this? GSO works fine both on my Ubuntu machine (via Parallels), and on all the Linode cloud servers I have up and running. Ideally some cloud service where I can quickly spin up a machine to play around with.

Thanks for the ping. We'll hold the Caddy 2.7 stable release until a patch is ready. We're fine with either a fix or disabling it.

@marten-seemann Oracle offers aarch64 in their free tier
https://www.oracle.com/cloud/free/

I wonder if this is in fact a kernel bug? Might be one of those aarch64 funzies that @marcan and the Asahi team keeps running into.

@kgersen The fallback is actually not the big problem. I'm fine falling back to a simple sendmsg on systems that don't support GSO for now. The problem is detecting if we're on such a system. Unfortunately, the kernel doesn't give us an error message that says "I don't like that UDP_SEGMENT message you gave me".

So the fix they use is to actually test gso before using it not just believe what the kernel returns.

Can you point me to where they test this?

here: https://github.com/microsoft/msquic/blob/main/src/platform/datapath_epoll.c#L473
They test GSO and then optionally also GRO.
problem I see here if that they use IPv4 lookback ...not sure they would detect the issue on our machines.
I've run the Linux kernel selftests on a machine with the issue and I can confirm, in our case, it's GSO+IPv6 the cultrip:
user@penguin:~/linux-source-5.10/tools/testing/selftests/net$ sudo ./in_netns.sh ./udpgso -6 -C -s
device mtu (orig): 65536
device mtu (test): 1500
ipv6 tx:1 gso:0
ipv6 tx:1452 gso:0
ipv6 tx:1453 gso:0 (fail)
ipv6 tx:1452 gso:1452
./udpgso: send failed while expecting success

with -4 (Ipv4) all tests are ok.

@jfgiorgi Any chance I can spin up a machine like this myself? Would be really helpful if I could debug it myself.

@marten-seemann Oracle offers aarch64 in their free tier
https://www.oracle.com/cloud/free/

You should be able to use the service for free :wink:

@jfgiorgi Any chance I can spin up a machine like this myself? Would be really helpful if I could debug it myself.

unfortunately it's not a VM in the cloud. it's a VM inside of physical device, a Chromebook.
the specs:
the hardware is an Intel I5-7Y57, running ChromeOS (Linux 5.4.247)
inside there is a VM in qemu running Linux 5.15.117
in which there is LXD container running Debian (with shared kernel so Linux 5.15.117).
We only have shell access to the inner LXD container so I don't know which layer is causing the issue.

Seems like it's tied to IPv6 and VMs/containers?
I wonder if this patch is related?
<EMAIL_ADDRESS>

@marten-seemann Oracle offers aarch64 in their free tier
https://www.oracle.com/cloud/free/

You should be able to use the service for free 😉

I tried, and it doesn't work. This user interface is a total mess. Apparently they're "out of capacity" for the aarch64 machines, and they don't let me use the 250 bucks of "free credit" they gave me to play around with beefier machines. And for some reason I'm stuck in the upgrade process of my account, which would allow me to add my credit card. What should I say, Oracle...
Instead, I set up an aarch64 on AWS. However, everything works fine there, I can successfully enable GSO there.
I'm not sure how to continue debugging this. By now I've probably tested on > 10 machines, and every machine I set up works fine, no matter which architecture and which distribution I select.

the specs:
the hardware is an Intel I5-7Y57, running ChromeOS (Linux 5.4.247)
inside there is a VM in qemu running Linux 5.15.117
in which there is LXD container running Debian (with shared kernel so Linux 5.15.117).

I don't think I'll be able to recreate this... ;)

There isn't much to debug. it's clearly a kernel/hardware issue on some machines/configuration not related to quic-go or even Go.
Even the kernel selftest fails.
At this point either spend more time trying to contact the people who made gso in Linux kernel or a Linux kernel/driver support group. may be there is a way to detect the issue (may be a cpu feature is missing or whatnot).
or do like msquic.
or switch gso to opt-in and let quic-go users do their own 'extra detection' when they encounter the issue.
The safest is like msquic: detect gso but don't trust the kernel so perform a test or catch the very first error and retry once without gso.
I'll take a look at Google's  quiche and Chromium source later next week to see how they deal with this since our Chromebooks have the issue.

There's a few things I'd like to try out. As @zllovesuki noticed, the we shouldn't set the option to 1, but the actual packet size. Now what I'd like to experiment with is the following:

What if we set this to a value that fits the initial packet size (~1280 bytes), but doesn't fit larger packet sizes, as PLPMTUD would attempt to send.
Can we just set this value to something > 1500 bytes, or will this call the syscall to fail for Ethernet interfaces (which usually have a smaller MTU)?

here: https://github.com/microsoft/msquic/blob/main/src/platform/datapath_epoll.c#L473 (up to line 535)
They test GSO and then optionally also GRO.

We could implement something similar: Send a packet filled with random bytes in maybeSetGSO, and disable GSO if we get any error. This means that the first packet a newly started QUIC server receives will be random garbage, but we obviously need to be able to deal with that anyway (i.e. discard it).

I discovered a wireguard-go PR crafted by @jwhited which which enables GSO/GRO:
https://github.com/WireGuard/wireguard-go/pull/75
Jordan is a Tailscale developer and recently blogged about the topic: https://tailscale.com/blog/more-throughput/

I discovered a wireguard-go PR crafted by @jwhited which enables GSO/GRO:
WireGuard/wireguard-go#75

@bt90 This is interesting, especially https://github.com/WireGuard/wireguard-go/pull/75/files#diff-83e4954537b2b18d2d74f2a75c311977f45b06185861d08f9715805f708f8ab9.
@zllovesuki Could you try if this would have helped detect the error?

Well i must have done something incorrect, that's not working on the raspberry pi:
diff --git a/errors_default.go b/errors_default.go
new file mode 100644
index 00000000..871aed10
--- /dev/null
+++ b/errors_default.go
@@ -0,0 +1,7 @@
+//go:build !linux
+
+package quic
+
+func errShouldDisableUDPGSO(err error) bool {
+       return false
+}
diff --git a/errors_linux.go b/errors_linux.go
new file mode 100644
index 00000000..9b887a6b
--- /dev/null
+++ b/errors_linux.go
@@ -0,0 +1,23 @@
+package quic
+
+import (
+       "errors"
+       "log"
+       "os"
+
+       "golang.org/x/sys/unix"
+)
+
+func errShouldDisableUDPGSO(err error) bool {
+       var serr *os.SyscallError
+       if errors.As(err, &serr) {
+               // EIO is returned by udp_send_skb() if the device driver does not have
+               // tx checksumming enabled, which is a hard requirement of UDP_SEGMENT.
+               // See:
+               // https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man7/udp.7?id=806eabd74910447f21005160e90957bde4db0183#n228
+               // https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/udp.c?h=v6.2&id=c9c3395d5e3dcc6daee66c6908354d47bf98cb0c#n942
+               log.Printf("!! DEBUG !! error assertion - syscall: %s, error: %+v\n", serr.Syscall, serr.Err)
+               return serr.Err == unix.EIO
+       }
+       return false
+}
diff --git a/sys_conn_oob.go b/sys_conn_oob.go
index fc28f94b..610707f2 100644
--- a/sys_conn_oob.go
+++ b/sys_conn_oob.go
@@ -6,6 +6,7 @@ import (
        "encoding/binary"
        "errors"
        "fmt"
+       "log"
        "net"
        "net/netip"
        "syscall"
@@ -241,12 +242,28 @@ func (c *oobConn) WriteTo(p []byte, addr net.Addr) (int, error) {
 // Callers are advised to make sure that oob has a sufficient capacity,
 // such that appending the UDP_SEGMENT size message doesn't cause an allocation.
 func (c *oobConn) WritePacket(b []byte, packetSize uint16, addr net.Addr, oob []byte) (n int, err error) {
+       var gsoOOB []byte
+RETRY:
        if c.cap.GSO {
-               oob = appendUDPSegmentSizeMsg(oob, packetSize)
+               oobCloned := make([]byte, len(oob))
+               copy(oobCloned, oob)
+               gsoOOB = appendUDPSegmentSizeMsg(oobCloned, packetSize)
        } else if uint16(len(b)) != packetSize {
                panic(fmt.Sprintf("inconsistent length. got: %d. expected %d", packetSize, len(b)))
        }
-       n, _, err = c.OOBCapablePacketConn.WriteMsgUDP(b, oob, addr.(*net.UDPAddr))
+       if c.cap.GSO {
+               n, _, err = c.OOBCapablePacketConn.WriteMsgUDP(b, gsoOOB, addr.(*net.UDPAddr))
+       } else {
+               n, _, err = c.OOBCapablePacketConn.WriteMsgUDP(b, oob, addr.(*net.UDPAddr))
+       }
+       if err != nil {
+               log.Printf("!! DEBUG !! WritePacket error: %+v\n", err)
+       }
+       if err != nil && c.cap.GSO && errShouldDisableUDPGSO(err) {
+               log.Printf("!! DEBUG !! GSO Support is broken\n")
+               c.cap.GSO = false
+               goto RETRY
+       }
        return n, err
 }

I don't see the GSO Support is broken line:
{"level":"info","ts":1687706222.861115,"caller":"quic-go@v0.36.1-0.20230625151457-97d155bd309b/sys_conn_oob.go:260","msg":"!! DEBUG !! WritePacket error: write udp [::]:59922->[REDACTED]:443: sendmsg: invalid argument","subsystem":"unknown"}
{"level":"info","ts":1687706222.861208,"caller":"quic-go@v0.36.1-0.20230625151457-97d155bd309b/errors_linux.go:19","msg":"!! DEBUG !! error assertion - syscall: sendmsg, error: invalid argument","subsystem":"unknown"}

Interesting. Can you confirm if it works if you pass oob (not gsoOOB) to the WriteMsgUDP call?

Thank you @jfgiorgi!
Is my understanding correct that this means:

We can't rely on sending a "GSO probe packet" to localhost, as sending to a remote address might use a different network interface (if we're listening on <IP_ADDRESS>)?
This would imply that we need to test for GSO (and fallback, if necessary) for every remote address individually.
This also means that the oobConn.WriteTo callback always needs a fallback (per packet), since the user passes in the remote address.

I wonder if the NICs would report that they don't support GSO? e.g
ethtool -k eno1

Looks like we're not alone with this problem.
https://github.com/envoyproxy/envoy/issues/21200

If we want to cover all scenarios:

config option to explicitly disable GSO
handle setsockopt error (GSO is disabled for the NIC)
handle EIO in sendmsg (GSO is enabled but NIC doesn't support checksum offloading)

Cases 2&3 should permanently disable GSO for the connection.

@bt90 It seems like your list is missing the scenario that leads to the sendmsg: invalid argument error that @zllovesuki and @jfgiorgi described, doesn't it?

Tried with a poc. See https://github.com/jfgiorgi/testgso

I tried running this on my Ubuntu server that has tailscaled installed and running. How do I reproduce the failure? <IP_ADDRESS> is a device on my tailnet.
remote v4 = <IP_ADDRESS>:1234
remote v6 = ::1:0
Kernel detection:
  IPv4 GSO: true
  IPv6 GSO: true
IPv4 with GSO:
  Write:  n,nb,err = 4000,24,nil
  Write with batch:  n,nb,err = 4000,24,nil
IPv4 without GSO:
  Write:  n,nb,err = 4000,0,nil
  Write with batch:  n,nb,err = 4000,0,nil
IPv6 with GSO:
  Write:  n,nb,err = 4000,24,nil
  Write with batch:  n,nb,err = 4000,24,nil
IPv6 without GSO:
  Write:  n,nb,err = 4000,0,nil
  Write with batch:  n,nb,err = 4000,0,nil

@marten-seemann
same here. I've rechecked.
it seems finally  that it's not all our machines.
with ethtool -k tailscale0, some have tx checksum off , some don't. This matches the detection of the poc code.
I think it's related to /dev/net/tun specs of the machine/kernel and/or wireguard driver version . not sure here but it doesn't matter since both cases exist.
You can try disabling checksum support on your tailscale0 interface to test the detection code:
sudo ethtool --offload tailscale0 rx off tx off

change off to on to revert.

@bt90 It seems like your list is missing the scenario that leads to the sendmsg: invalid argument error that @zllovesuki and @jfgiorgi described, doesn't it?

My bad. Case 3 should cover any ad-hoc GSO problems, broadly speaking.
I don't think we can rely on the first packet going through. It might not be big enough to hit the MTU limit and trigger the error. On top of that there's no guarantee that the configuration of the NIC or the network path stays the same while the connection is active.
The safest bet would be to catch socket configuration and send errors related to GSO at the first occurance and mark the whole connection as non-GSO.
I'm not sure if quic-go should do any logging on its own or if this information should be relayed to a listener so that applications like caddy can decide what and how often to log. This might happen for every single connection and in turn spam the log.

The eth0 interface on PI supports GSO and the wlan0 interface doesn't.
On eth0 everything works. The client example in the repo works fine.
After disconnecting the ethernet cable and connecting only via wifi, the client example in the repo fails:
go run example/client/main.go -v https://google.com
GET https://google.com
Setting DF for IPv4 and IPv6.
Activating reading of ECN bits for IPv4 and IPv6.
Activating reading of packet info for IPv4 and IPv6.
failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Receive-Buffer-Size for details.
client Starting new connection to google.com ([::]:33822 -> <IP_ADDRESS>:443), source connection ID e0fbde68, destination connection ID 44f6c0a49c5d7cef299cd9a182, version v1
Adding connection ID e0fbde68.
client Not doing 0-RTT.
client -> Sending packet 0 (1252 bytes) for connection 44f6c0a49c5d7cef299cd9a182, Initial
client 	Long Header{Type: Initial, DestConnectionID: 44f6c0a49c5d7cef299cd9a182, SrcConnectionID: e0fbde68, Token: (empty), PacketNumber: 0, PacketNumberLen: 2, Length: 1225, Version: v1}
client 	-> &wire.CryptoFrame{Offset: 0, Data length: 267, Offset + Data length: 267}
client Destroying connection with error: write udp [::]:33822-><IP_ADDRESS>:443: sendmsg: input/output error
Removing connection ID e0fbde68.
client Connection 44f6c0a49c5d7cef299cd9a182 closed.
Get "https://google.com": INTERNAL_ERROR (local): write udp [::]:33822-><IP_ADDRESS>:443: sendmsg: input/output error

ethtool -k wlan0 outputs
generic-segmentation-offload: off [requested on]
Similarly
ethtool -k eth0 outputs
generic-segmentation-offload: on
With @zllovesuki's patch I do see the lines
client  -> &wire.CryptoFrame{Offset: 0, Data length: 267, Offset + Data length: 267}
!! DEBUG !! WritePacket error: write udp [::]:56162-><IP_ADDRESS>:443: sendmsg: input/output error
!! DEBUG !! error assertion - syscall: sendmsg, error: input/output error
!! DEBUG !! GSO Support is broken
!! DEBUG !! WritePacket error: write udp [::]:56162-><IP_ADDRESS>:443: sendmsg: invalid argument
client Destroying connection with error: write udp [::]:56162-><IP_ADDRESS>:443: sendmsg: invalid argument

But again only with wlan0 and not with eth0.

@sukunrt could you also check tx-checksumming ?
ethtool -k eth0 | grep -E 'tx-checksumming|generic-segmentation-offload'
ethtool -k wlan0 | grep -E 'tx-checksumming|generic-segmentation-offload'

That's also as we expect. Available on eth0 and not on wlan0
wlan0
ethtool -k wlan0 | grep -E 'tx-checksumming|generic-segmentation-offload'
tx-checksumming: off
generic-segmentation-offload: off [requested on]

eth0
ethtool -k eth0 | grep -E 'tx-checksumming|generic-segmentation-offload'
tx-checksumming: on
generic-segmentation-offload: on

I was able to reproduce the failure by manually disabling GSO and checksum offload on eth0:
ethtool -K eth0 tx off
ethtool -K eth0 generic-segmentation-offload off

Result:
❯ ethtool -k eth0 | grep -E 'tx-checksumming|generic-segmentation-offload'
tx-checksumming: off
generic-segmentation-offload: off

The output of the GSO test tool is now:
❯ go run main.go -r4 <IP_ADDRESS>:1234
remote v4 = <IP_ADDRESS>:1234
remote v6 = ::1:0
Kernel detection:
  IPv4 GSO: true
  IPv6 GSO: true
IPv4 with GSO:
  Write:  gso issue detected
  n,nb,err = 0,0,write udp4 <IP_ADDRESS>:34163-><IP_ADDRESS>:1234: sendmsg: input/output error
  Write with batch:unexpected number of msg sent
  gso issue detected
  n,nb,err = 0,0,write udp <IP_ADDRESS>:34163: sendmmsg: input/output error
IPv4 without GSO:
  Write:  n,nb,err = 4000,0,nil
  Write with batch:  n,nb,err = 4000,0,nil
IPv6 with GSO:
  Write:  n,nb,err = 4000,24,nil
  Write with batch:  n,nb,err = 4000,24,nil
IPv6 without GSO:
  Write:  n,nb,err = 4000,0,nil
  Write with batch:  n,nb,err = 4000,0,nil

This is because GSO was only deactivated on eth0, not on lo (for some reason it doesn't seem possible to disable it on lo).

This is my current mental model why we're seeing these errors:

When setting the GSO socket option, we only get an error if the kernel doesn't support GSO.
We can listen on all interfaces by listening on <IP_ADDRESS>:port. Some of the interfaces might support GSO, others might not. This is why the kernel can't return an error for the syscall. We then get the unix.EIO error we can detect with errShouldDisableUDPGSO. This error occurs regardless of the size of the packet we write, specifically, we don't need to send a packet larger than 1 MTU to trigger the error.

It's annoying that the kernel just doesn't "do the right thing", i.e. chop up the packet if the NIC doesn't support GSO. I don't yet understand the rationale behind that design choice.
I also don't yet understand why we receive an the error that's not unix.EIO as @zllovesuki reported above.

What does this mean in terms of fixing the issue:

For every new QUIC connection, we need to inspect the error returned from the first packet we write: If nil, GSO works fine. If it matches errShouldDisableUDPGSO, we need to disable GSO for that connection (but not for other connections). We can then manually split the first packet from the first Write call and send the packets out one by one. This is ok since we only do this once per connection.
This is really annoying for the WriteTo call: https://github.com/quic-go/quic-go/blob/435444af7eb81b922a412ee80d4caddff26744de/sys_conn_oob.go#L231-L236 If GSO doesn't work for an address, this results in doubling the number of syscalls. I'm not sure how to solve this. One option would be to expose something like a connected UDP socket (related: https://github.com/quic-go/quic-go/issues/3929#issuecomment-1610325613).

I also don't yet understand why we receive an the error that's not unix.EIO as @zllovesuki reported above.

Looks like it's a mixture of EIO and EINVAL:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/udp.c#n923

I've created https://github.com/quic-go/quic-go/pull/3934, which flips the environment variable around. With this PR, GSO would (for now) be disabled by default, until we can figure out a good solution for this issue. We could release this as v0.36.1. Any thoughts on that?

Better to be safe than sorry and delivery a bulletproof mechanism if we enable it by default.

why not allow to also enable per Transport ?

We can do that for the next release. For the patch release, I just want to do the most minimal change.

After playing around with a fallback solution, I've come to the conclusion that we shouldn't set any socket option, as we currently do: https://github.com/quic-go/quic-go/blob/44a58dc425fc0ff2c9a5a9afa3e380d3e47f96ec/sys_conn_df_linux.go#L47-L52
This is consistent with what Tailscale does:
https://github.com/search?q=repo%3Atailscale%2Ftailscale+SetSockopt&type=code
I've reproduced this in C: https://gist.github.com/marten-seemann/36a2558b48d060d063ecb3b005f47320. It's useful to run this with ptrace to see the syscalls being made: strace -e trace=sendmsg -s 1000 ./your_program.

This makes the logic so much nicer:

In the server and the transport, which both need to occasionally send packets (version negotiation, retry, etc.), we don't need to do anything. We just don't append the UDP_SEGMENT cmsg when sending the packet, and everything just works.
We test for GSO support only for QUIC connections by using UDP_SEGMENT. If we get a unix.EIO error at any time, we disable GSO for that path, and continue sending without the UDP_SEGMENT cmsg.

We test for GSO support only for QUIC connections by using UDP_SEGMENT. If we get a unix.EIO error at any time, we disable GSO for that path, and continue sending without the UDP_SEGMENT cmsg.

You can test for kernel support via getsockopt(). EIO is a signal the egress netdev does not support checksum offload, which is a netdev feature requirement of UDP_SEGMENT.

Thank you @jwhited! Apparently testing for kernel support and checking for EIO is not enough, @zllovesuki is still running into the same problem. Any advice what else to check?

Thank you @jwhited! Apparently testing for kernel support and checking for EIO is not enough, @zllovesuki is still running into the same problem. Any advice what else to check?

I would work to identify where the EINVAL is coming from in the kernel. That error indicates something is wrong with the arguments passed via the syscall.
If you're able to reproduce with Tailscale and/or https://github.com/WireGuard/wireguard-go/pull/75 that would also be of interest.

Unfortunately, I don't have a Raspberry Pi with me at the moment. @zllovesuki, can you help us out here?

You can get EINVAL when the split would result in more than 64 datagrams. I grepped for this value in quic-go and I don't see it being enforced, though I may have missed it.
See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/udp.c?h=v6.2&id=c9c3395d5e3dcc6daee66c6908354d47bf98cb0c#n933 and the usage of https://github.com/WireGuard/wireguard-go/pull/75/files?diff=unified&w=0#diff-8fba84ef516815198fc29ef62a2486ad0c8b49e02257af3c3b96171a1cbfdc87R451

That check is implicit. The minimum size of packets we send is 1200 bytes, and we stop adding new packets to a batch as soon as a packet is packed that's smaller than that. Since the size is limited to 64k, we can never have more than 64 packets.

Maybe the way we construct the cmsg doesn't work on all platforms? Just a wild guess, but it might be worth checking that the cmsg looks the same when generated in C vs. what we generate here in Go:
https://github.com/quic-go/quic-go/blob/44a58dc425fc0ff2c9a5a9afa3e380d3e47f96ec/sys_conn_df_linux.go#L67-L80

@marten-seemann do you just need SSH access to a raspberry pi? Send me an email (address on profile) or we can chat over Signal to coordinate

@zllovesuki Thanks for offering. I might get back to you on this in a couple of days.

I've reproduced this in C: https://gist.github.com/marten-seemann/36a2558b48d060d063ecb3b005f47320. It's useful to run this with ptrace to see the syscalls being made: strace -e trace=sendmsg -s 1000 ./your_program.

i've updated this C code to support both IPv4 & IPv6 : https://github.com/jfgiorgi/cgso
on our systems with the gso issue:
#IPv6
clang gsofallback.c && ./a.out 2001:4860:4860::8888
Sending with GSO to [2001:4860:4860::8888]:6121...
GSO failed. Attempting without GSO...
Message sent without GSO.

#IPv4
clang gsofallback.c && ./a.out <IP_ADDRESS>
Sending with GSO to [::ffff:<IP_ADDRESS>]:6121...
Message sent with GSO.

it works if:
. no call to setsockopt is made (uncommeting the setsockopt lines make the fallback fails too)
. fallback if first message fails with UDP_SEGMENT in ancillary data

it works if: . no call to setsockopt is made (uncommeting the setsockopt lines make the fallback fails too) . fallback if first message fails with UDP_SEGMENT in ancillary data

The UDP_SEGMENT sockopt is not a binary flag like UDP_GRO. It sets the split size for all datagrams without the need for an equivalent cmsg. So, setting it to 1 and mixing with cmsg seems unintentional if quic-go is still doing that.

I'm still seeing issues with GSO on arm64 platform:
"error":"INTERNAL_ERROR (local): write udp [::]:443->[redacted]:51157: sendmsg: invalid argument"

Is there any container runtime involved?

This isn't a super helpful comment but I forgot to gather more info and tore down my environment. Figured I would comment something now instead of waiting - I will try to make this more useful though.
On a GCP c3 VM with completely out-of-the-box settings connecting to another C3 VM using the latest version of quic-go, I had to disable GSO or I got the invalid argument. The same code works on my local machine.

package main

import (
	"context"
	"crypto/rand"
	"crypto/rsa"
	"crypto/tls"
	"crypto/x509"
	"encoding/pem"
	"flag"
	"github.com/quic-go/quic-go"
	syscall "golang.org/x/sys/unix"
	"io"
	"log"
	"math/big"
	"net"
	"os"
	"os/signal"
	"sync"
	"time"
)

var (
	remote = flag.String("r", "<IP_ADDRESS>:8080", "remote addresses")
)

func main() {
	flag.Parse()

	go outbound()
	go inbound()
	WaitSignal()
}

func listenUDP(addr string) (*net.UDPConn, error) {
	udpAddr, err := net.ResolveUDPAddr("udp4", addr)
	if err != nil {
		return nil, err
	}
	return net.ListenUDP("udp4", udpAddr)
}

func dialUDP(addr string, tlsConf *tls.Config, conf *quic.Config) (quic.Connection, error) {
	udpConn, err := net.ListenUDP("udp4", nil)
	if err != nil {
		return nil, err
	}
	udpAddr, err := net.ResolveUDPAddr("udp4", addr)
	if err != nil {
		return nil, err
	}
	return quic.Dial(context.Background(), udpConn, udpAddr, tlsConf, conf)
}

func outbound() {
	listener, err := net.Listen("tcp", "<IP_ADDRESS>:15001")
	if err != nil {
		panic(err)
	}

	for {
		conn, err := listener.Accept()
		if err != nil {
			panic(err)
		}
		log.Println("accepted outbound connection")
		go proxyConn(conn, *remote, true)
	}
}
func inbound() {
	pc, err := listenUDP("<IP_ADDRESS>:15006")
	if err != nil {
		panic(err)
	}
	listener, err := quic.Listen(pc, generateTLSConfig(), &quic.Config{
		EnableDatagrams: true,
	})
	if err != nil {
		panic(err)
	}
	for {
		conn, err := listener.Accept(context.Background())
		if err != nil {
			panic(err)
		}
		log.Println("accepted inbound connection")
		_, port, _ := net.SplitHostPort(*remote)
		stream, err := conn.AcceptStream(context.Background())
		if err != nil {
			panic(err)
		}
		go proxyConn(stream, "<IP_ADDRESS>:"+port, false)
	}
}

func WaitSignal() {
	sigs := make(chan os.Signal, 1)
	signal.Notify(sigs, syscall.SIGINT, syscall.SIGTERM)
	<-sigs
}

func proxyConn(incoming io.ReadWriteCloser, dstIP string, useTLS bool) {
	var outgoing io.ReadWriteCloser
	if useTLS {
		c, err := dialUDP(dstIP, generateTLSConfig(), &quic.Config{EnableDatagrams: true})
		if err != nil {
			panic(err)
		}
		stream, err := c.OpenStream()
		if err != nil {
			panic(err)
		}
		outgoing = stream
	} else {
		c, err := net.Dial("tcp", dstIP)
		if err != nil {
			panic(err)
		}
		outgoing = c
	}

	log.Println("connected to upstream")
	t0 := time.Now()
	wg := sync.WaitGroup{}
	wg.Add(1)
	go func() {
		n, err := io.Copy(incoming, outgoing)
		log.Printf("upstream complete, wrote=%v, err=%v", n, err)
		incoming.Close()
		outgoing.Close()
		wg.Done()
	}()

	n, err := io.Copy(outgoing, incoming)
	log.Printf("downstream complete, wrote=%v, err=%v", n, err)
	incoming.Close()
	outgoing.Close()
	wg.Wait()
	log.Println("connection closed in ", time.Since(t0))
}

func generateTLSConfig() *tls.Config {
	key, err := rsa.GenerateKey(rand.Reader, 1024)
	if err != nil {
		panic(err)
	}
	template := x509.Certificate{SerialNumber: big.NewInt(1)}
	certDER, err := x509.CreateCertificate(rand.Reader, &template, &template, &key.PublicKey, key)
	if err != nil {
		panic(err)
	}
	keyPEM := pem.EncodeToMemory(&pem.Block{Type: "RSA PRIVATE KEY", Bytes: x509.MarshalPKCS1PrivateKey(key)})
	certPEM := pem.EncodeToMemory(&pem.Block{Type: "CERTIFICATE", Bytes: certDER})

	tlsCert, err := tls.X509KeyPair(certPEM, keyPEM)
	if err != nil {
		panic(err)
	}
	return &tls.Config{
		Certificates:       []tls.Certificate{tlsCert},
		InsecureSkipVerify: true,
	}
}

When I use quic echo, the same error still occurs, the information is as follows:
[root@Aliyun quic]# QUIC_GO_LOG_LEVEL=DEBUG go run main.go
2023/11/10 22:14:36 Increased receive buffer size to 4096 kiB
2023/11/10 22:14:36 Increased send buffer size to 4096 kiB
2023/11/10 22:14:36 Setting DF for IPv4 and IPv6.
2023/11/10 22:14:36 Activating reading of ECN bits for IPv4 and IPv6.
2023/11/10 22:14:36 Activating reading of packet info for IPv4 and IPv6.
2023/11/10 22:14:36 client Starting new connection to localhost ([::]:47781 -> <IP_ADDRESS>:4242), source connection ID (empty), destination connection ID dedb29535cb7debdda558e64e544722190fdd626, version v1
2023/11/10 22:14:36 Adding connection ID (empty).
2023/11/10 22:14:36 client Not doing 0-RTT. Has sealer: false, has params: false
2023/11/10 22:14:36 client -> Sending packet 0 (1252 bytes) for connection dedb29535cb7debdda558e64e544722190fdd626, Initial
2023/11/10 22:14:36 client      Long Header{Type: Initial, DestConnectionID: dedb29535cb7debdda558e64e544722190fdd626, SrcConnectionID: (empty), Token: (empty), PacketNumber: 0, PacketNumberLen: 2, Length: 1222, Version: v1}
2023/11/10 22:14:36 client      -> &wire.CryptoFrame{Offset: 0, Data length: 279, Offset + Data length: 279}
2023/11/10 22:14:36 client Destroying connection with error: write udp [::]:47781-><IP_ADDRESS>:4242: sendmsg: invalid argument
2023/11/10 22:14:36 Removing connection ID (empty).
2023/11/10 22:14:36 client Connection dedb29535cb7debdda558e64e544722190fdd626 closed.
panic: INTERNAL_ERROR (local): write udp [::]:47781-><IP_ADDRESS>:4242: sendmsg: invalid argument

goroutine 1 [running]:
main.main()
        /root/quic/main.go:29 +0x45
exit status 2

I added QUIC_GO_DISABLE_GSO=true and the problem still exists
[root@Aliyun quic]# QUIC_GO_DISABLE_GSO=true QUIC_GO_LOG_LEVEL=DEBUG go run main.go
2023/11/10 22:14:27 Increased receive buffer size to 4096 kiB
2023/11/10 22:14:27 Increased send buffer size to 4096 kiB
2023/11/10 22:14:27 Setting DF for IPv4 and IPv6.
2023/11/10 22:14:27 Activating reading of ECN bits for IPv4 and IPv6.
2023/11/10 22:14:27 Activating reading of packet info for IPv4 and IPv6.
2023/11/10 22:14:27 client Starting new connection to localhost ([::]:52004 -> <IP_ADDRESS>:4242), source connection ID (empty), destination connection ID 5ee5129391926792fbf5e57e0efbcd75, version v1
2023/11/10 22:14:27 Adding connection ID (empty).
2023/11/10 22:14:27 client Not doing 0-RTT. Has sealer: false, has params: false
2023/11/10 22:14:27 client -> Sending packet 0 (1252 bytes) for connection 5ee5129391926792fbf5e57e0efbcd75, Initial
2023/11/10 22:14:27 client      Long Header{Type: Initial, DestConnectionID: 5ee5129391926792fbf5e57e0efbcd75, SrcConnectionID: (empty), Token: (empty), PacketNumber: 0, PacketNumberLen: 2, Length: 1226, Version: v1}
2023/11/10 22:14:27 client      -> &wire.CryptoFrame{Offset: 0, Data length: 273, Offset + Data length: 273}
2023/11/10 22:14:27 client Destroying connection with error: write udp [::]:52004-><IP_ADDRESS>:4242: sendmsg: invalid argument
2023/11/10 22:14:27 Removing connection ID (empty).
2023/11/10 22:14:27 client Connection 5ee5129391926792fbf5e57e0efbcd75 closed.
panic: INTERNAL_ERROR (local): write udp [::]:52004-><IP_ADDRESS>:4242: sendmsg: invalid argument

goroutine 1 [running]:
main.main()
        /root/quic/main.go:29 +0x45
exit status 2

about my Linux:
[root@Aliyun quic]# uname -a
Linux Aliyun 3.10.0-957.21.3.el7.x86_64 #1 SMP Tue Jun 18 16:35:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[root@Aliyun quic]# go version
go version go1.20 linux/amd64

Linux Aliyun 3.10.0-957.21.3.el7.x86_64

UDP GSO support was introduced in 4.18: https://kernelnewbies.org/Linux_4.18#Networking

Linux Aliyun 3.10.0-957.21.3.el7.x86_64

UDP GSO support was introduced in 4.18: https://kernelnewbies.org/Linux_4.18#Networking

Sorry, I didn't debug at first and came directly to this issue. I found that it was not just GSO that caused this problem. Using QUIC_GO_DISABLE_GSO=true was effective, but my linux did not support ECN, so I had to use QUIC_GO_DISABLE_ECN=true at the same time to solve this problem.

@marten-seemann do you think the invalid argument was coming from ECN related bug instead of GSO?

That would be my suspicion of QUIC_GO_DISABLE_ECN=true solved the problem.


Fix issue #89: Read recipient from encoded hexadecimal notation

Added

Added class Recipient with createFromEncoded()
Added NamespaceId.createFromEncoded()
Added TransactionTransaction.recipient capability to hold Recipient | Address | NamespaceId
Added unit tests for encoded hexadecimal notation interpretation

Fixed

Fixed infrastructure/transaction/CreateTransactionFromDTO for TransferTransaction to parse recipient correctly. (#89 )

Pull Request Test Coverage Report for Build 240

31 of 31 (100.0%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.8%) to 72.456%

Totals

Change from base Build 235:
0.8%

Covered Lines:
1054

Relevant Lines:
1320

💛  - Coveralls

Removed proposed class Recipient in favor of an auxiliary function extractVersion() in transaction/CreateTransactionFromDTO.

Added auxiliary extractMosaics() to differentiate mosaicId from namespaceId in mosaics


Awesome software

Hey Glittershark,
I just wanted to let you know that this is an excellent component. It's a great example of a tool that does one thing and does it exceptionally well. Thanks for open sourcing this tool.
Thanks!
-Thomas

Thanks so much! this totally made my day :grinning:


Add metadata folder, necessary specs in representative formats

It would be helpful to have a folder to organize the different kinds of metadata we need, primarily specs but also whatever additional pieces are needed for the pharmaverse workflow.
We can definitely add multiple versions of specs over time as well to cover the preferred format for as many groups as possible :D

@kyleireton good call - would you be interested in making a PR for this? and collating any metadata from the current examples here.

Hi Ross, yes would be glad to submit the PR for pulling the metadata into one place!

thanks Kyle! be sure to add yourself in the DESCRIPTION file too as a contributor as part of the PR. you can put me down to review.

We now have this via: https://github.com/pharmaverse/examples/tree/main/metadata


add SDK validate docs

related: CIAC-7522

@dorschw Should this table be added to https://docs-cortex.paloaltonetworks.com/r/1/Demisto-SDK-Guide/validate


When I  Use AFN3.0, it does not working

when i  use AFN3.0, then response error
In order to validate a domain name for self signed certificates, you MUST use pinning.
Error Domain=NSURLErrorDomain Code=-999 "cancelled"
UserInfo={NSErrorFailingURLKey=https://kyfw.12306.cn/otn/lcxxcx/query?purpose_codes=ADULT&queryDate=2016-05-25&from_station=BJP&to_station=SHH, NSLocalizedDescription=cancelled, NSErrorFailingURLStringKey=https://kyfw.12306.cn/otn/lcxxcx/query?purpose_codes=ADULT&queryDate=2016-05-25&from_station=BJP&to_station=SHH}
but i open this url on safari , it work
when i use AFN 2.0    no this question.

I think this should answer your question:
http://stackoverflow.com/questions/27808249/problems-with-ssl-pinning-and-afnetworking-2-5-0-nsurlerrordomain-error-1012

OK
I set a certificates, it work


Snapshot Fixes 5/20/2015

Apply policy to only keep last "n" snapshots locally in device mapper.
Use DB for configuration
WIP - implement the backup of the base volume image of the snapshot.

If the base image already exist on the disk, just restore from volume snapshot
If the base image does not exist on disk, copy the base image, and then restore from volume snapshot.

Use files to store configuration instead.
Still WIP on base image.

Still need to hook up cattle part.


implement mihonapp/mihon#326

Switched from the Java zip implementation to Apache Commons Compresses.
Archives are now being read from channels were applicable.
This PR includes the upstream fix mihonapp/mihon#485 ~which has not been merged as of now~.
Removed usage of the TempFileManager were applicable

I also added a new option to load images into memory, in addition to the already existing options of reading them directly from the archive and caching the images to disk.
Credit for mihonapp/mihon#326 and mihonapp/mihon#485 goes to FooIbar

Looks like me cherry picking Mihon commits made conflicts, you can fix those and then I will merge 👍

The remaining detekt detection SerialVersionUIDInSerializableClass was introduced by the upstream, we should wait and copy mihons fix.


Prevent sound upon close

I want to be able to stop the sound that Microsoft plays when i close a query. It's annoying. I've googled, and others are also complaining, no one has found a solution yet. Please allow this to be be switched off
Signed,
Someone with a lot of query tabs

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

ID: 6a1813bf-093a-3fd6-19de-a6b1fced00c8
Version Independent ID: 4eb5a42a-4d69-cf96-55bd-01f3e40042af
Content: Save Changes - SQL Server Management Studio (SSMS)
Content Source: docs/ssms/menu-help/save-changes.md
Product: sql
Technology: ssms
GitHub Login: @markingmyname
Microsoft Alias: maghan

@andrea-tf -- Andrea, thank you for your feedback.  Please add it here:


changed Ti arg name to Tion as standard

tiny PR that changes the arg name on a function so that it matches the other argnames for ion temperature elsewhere in the code (Tion instead of Ti)

Change now included in #27


⚠ GLDDNS Server (ns1.glddns.com) has degraded performance

In 33e2078, GLDDNS Server (ns1.glddns.com) (ns1.glddns.com) experienced degraded performance:

HTTP code: 200
Response time: 1089 ms

Resolved: GLDDNS Server (ns1.glddns.com) performance has improved in f77fd33 after 9 minutes.


Only bold, italic text can be displayed

For anything else "React is not defined" error is returned and app crashes.
H1 through H6 won't make the app crash, but no styles are applied to these elements .

To add, on iOS no styles are applied at all.

Hey @mnemosx! It seems to me like the React is not defined error is caused by a missing React dependency required by some of the functions within the node_modules/react-native-prismic-richtext/lib/services.js file, like for example serializeUl. I have not spent much time looking into it but adding a simple import React from 'react'; in that particular file seems to prevent the error and crash, at least in the instances that I have tested.
Also, I think adding styles for individual elements should be done manually. If, for example, you want to differentiate the H3 element through a bold style, you should add it yourself to the RichText element styles. On both the iOS simulator and my actual device I can see the styles applied correctly.
          <RichText
            richText={prismicRichTextResponse}
            styles={{
              heading3: { fontWeight: 'bold' }
            }}
          />

@Spoutnik97 any chance you could look into the missing React dependency that is currently causing the error and crash? It prevents the library from being used when a rich text field response contains list items, for example. Happy to provide more information on the error and crash. And thank you for creating and sharing this cool package! 🙏

@mnemosx @jacprada this should be fixed with the release today.

@jacprada thanks for the issue. I will correct it today, then I will ping you when the new version is published


eroshare: direct links not working

Converted from https://github.com/4pr0n/ripme/issues/502#issuecomment-298486387
@itscoldoutside:

Certain types of Eroshare links don't work ex. https://eroshare.com/14ld5ka2?
Get error "eroshare album not found in https://eroshare.com/14ld5ka2?, expected https://eroshare.com/album"

Will still be valid after ripmeapp/ripme#29 is merged, but the above link was apparently not saved so we need a new example.


python3Packages.pynetdicom: 2.0.0 -> 2.0.1

Motivation for this change
https://github.com/pydicom/pynetdicom/releases/tag/v2.0.1
Things done

Built on platform(s)

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

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

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

3 packages built:

expliot
python38Packages.pynetdicom
python39Packages.pynetdicom


Add support for HTTP Basic Auth to Jenkins collector

Allows the Jenkins collector to connect to Jenkins servers that require authentication.
To enable basic auth, set the following properties:
jenkins.authRequired=true
jenkins.username=jenkins-username-goes-here
jenkins.apiKey=jenkins-apiKey-goes-here

@MikePulcini Can you submit the CLA?

Just submitted the CLA.


⚠ SolarUser has degraded performance

In abed191, SolarUser ($SOLARUSER_URL) experienced degraded performance:

HTTP code: 200
Response time: 69 ms

Resolved: SolarUser performance has improved in ceb4dcb after 28 minutes.


Issue with social login integration

There is an issue with social login, it is not working, I guess its need to be configure and integrated. You can use laravel package "Laravel Socialite".

You are right, i didn't configure social media login yet. this feature will be available in future.


Datepicker view is not getting changed when onViewChange is used

Datepicker view is not getting changed when onViewChange is used

[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯
Datepicker view is not getting changed when onViewChange is used
Expected Behavior 🤔
Datepicker view should get changed when onViewChange is used
Steps to Reproduce 🕹
Steps:

Open https://codesandbox.io/s/jovial-lovelace-eebt5?file=/src/demo.js
Click the month and year section
If onViewChange is not used, Datepicker view is getting changed
If onViewChange is used, Datepicker view is not getting changed

Context 🔦

Your Environment 🌎
@emotion/react: 11.4.0
@emotion/styled: 11.3.0
@material-ui/core: 5.0.0-alpha.33
@material-ui/lab: 5.0.0-alpha.33

Thanks for the report.
I think we assume that declaring onChangeView means the view is controlled. But that's not how uncontrolled vs controlled components usually work.

@ThilakrajSelvam
On Commenting #L16-L19, things are working fine. Why do We Need to trigger onViewChange for the same?
Demo: https://codesandbox.io/s/gifted-panini-rylg2?file=/src/demo.js:594-606


Feature Request: An option for the location path where cache is stored.

Hi,
I have noticed that all the files used for playback are downloaded under C:\Users\username\AppData\Roaming\Google Play Music Desktop Player\Cache. This happens to be where my SSD is and would love to have the option to use another drive so to save the lifetime of my SSD.
Thank you in advance and keep up the good work.
Noel Scerri
nscerri
OS:
Windows 10
Issue Descriptions:
Steps to Reproduce:

is and would love to have the option to use another drive so to save the lifetime of my SSD.

even if you have a crappy drive with 16nm planar TLC this doesn't matter in any significant way. lets assume the music you listen to would be 10GB / day and you write another 15gb with other applications. a average 500gb ssd with the worst NAND that you can get (16nm TLC) has roughly an endurancerating of 70TB, but realisticly lasts waay longer. So even if you consider worst-case scenarios you would look at a lifetime of over 7 years

I've been thinking about this for a while (you may notice I haven't tagged it yet).  And I've come to a similar conclusion to @MaxRink
Basically, although it is technically possible for us to choose a new folder to store the Chromium cache in.  I don't think it's a good idea as it can lead to side affects a user doesn't know about.
Also, the core reasoning in your request is to increase the life of an SSD which in terms of the Chromium cache is barely a reason at all 👍 .  The Chromium cache is very inactive, especially when just playing music and not loading multiple pages.
Closing this out as wontfix


[New game]: Menja Block breaker

🎮 Game Request
Game logic and basic description
it is block breaker game in which you have to bnreak blocks by swapping
Point down the features
Game points

3d game
good animation
html,css,js will be used
great UI

Select program in which you are contributing
GSSoC24
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

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

/assign


add: service credential to secrets manager in DA

Description
https://github.com/terraform-ibm-modules/terraform-ibm-event-notifications/issues/245
Release required?

[ ] No release
[ ] Patch release (x.x.X)
[X] Minor release (x.X.x)
[ ] Major release (X.x.x)

Release notes content
This enhancement will enable users to create service credentials in an existing secrets manager for an Event Notification instance. Users can choose to use an existing secret group or create a new one for the service credentials.
Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
/run pipeline

Checklist for reviewers

[ ] If relevant, a test for the change is included or updated with this PR.
[ ] If relevant, documentation for the change is included or updated with this PR.

For mergers

Use a conventional commit message to set the release level. Follow the guidelines.
Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
Use the Squash and merge option.

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

available roles

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

:tada: This PR is included in version 1.11.0 :tada:
The release is available on:

GitHub release
v1.11.0

Your semantic-release bot :package::rocket:


Workflow parameters aren't visible in the UI

Summary
As a user of the Argo UI interface, I would like to be able to see the argument parameters used to trigger a Workflow.
Use Cases
I create my workflows based on a WorkflowTemplate. This WorkflowTemplate has some arguments, as a date for example.
spec:
...
  arguments:
    parameters:
      - name: DATE
        value: {{workflow.creationTimestamp.Y}}-{{workflow.creationTimestamp.m}}-{{workflow.creationTimestamp.d}}

Workflows are created :

On a timely basis by CronWorkflow
Manually through the UI by clicking the submit button on the WorkflowTemplate page, and providing the arguments.

When using those 2 ways, I don't see on any place in the UI the arguments that were used to trigger the workflow. For now I have to check the logs, which is not convenient at all.
I would like to have the possibility to see the value of the DATE argument here, as : DATE=2020-10-29, so I know for which date the workflow was run.
I am using version v2.11.6.

Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

This seems like a great idea. Would you like to submit a PR?

Not much time at the moment TBH. But with the lockdown arriving, I may have some time...
What skill would be needed for that?

React and Typescript/Javascript

If no one is working on this, I'd like to take it.

If no one is working on this, I'd like to take it.

This is done and I think we can close it.


high loss in validation when I train

I download the market1501 dataset and reorganize the train and test dataset, but when I train the model, the train accuracy increase but the test accuracy is alwanys very low,
Epoch : 40
[progress:9.9%]time:5.85s Loss:0.19229 Correct:1227/1280 Acc:95.859%
[progress:19.7%]time:12.49s Loss:0.19317 Correct:2455/2560 Acc:95.898%
[progress:29.6%]time:6.21s Loss:0.16215 Correct:3698/3840 Acc:96.302%
[progress:39.4%]time:6.23s Loss:0.18000 Correct:4937/5120 Acc:96.426%
[progress:49.3%]time:6.22s Loss:0.18456 Correct:6169/6400 Acc:96.391%
[progress:59.1%]time:6.27s Loss:0.18482 Correct:7395/7680 Acc:96.289%
[progress:69.0%]time:6.28s Loss:0.19110 Correct:8616/8960 Acc:96.161%
[progress:78.8%]time:6.00s Loss:0.17664 Correct:9854/10240 Acc:96.230%
[progress:88.7%]time:6.27s Loss:0.16078 Correct:11090/11520 Acc:96.267%
[progress:98.5%]time:6.28s Loss:0.17974 Correct:12330/12800 Acc:96.328%
Testing ...
[progress:100.0%]time:41.70s Loss:13.60742 Correct:24/15913 Acc:0.151%
Learning rate adjusted to 0.0010000000000000002
anyone can sovle this?

im having the same problem im trying to train it on my own dataset of cars .. any solu!

@montaboom sorry , i haven't solve it

你好，请问训练时除了改输入数据集路径还要改啥吗？我也下了1501的数据集，改了输入路径，但是程序报错：RuntimeError: Found 0 files in subfolders of: /Users/sunyuhua/Desktop/Market1501/bounding_box_train
Supported extensions are: .jpg,.jpeg,.png,.ppm,.bmp,.pgm,.tif,.tiff,.webp
请大神赐教

@DerekSunYH
you should divide the Market1501 to different folders such as 0000,0001,....

all pictures are in file folder "bounding_box_train"。What should I divide them based on？

@yustaub is there any other repo that you know where i can train the tracker to track cars ..?

@montaboom sorry , i didn't know ,did you solve this problem?

@yustaub  Did you solve this problem ?  I meet this same problem

When I download the MARS dataset, I saw that train and test dataset have different classes. Solution--> The train and test dataset must have the same classes.

@joaquinCaceres  yes you are right for market 1501 dataset we need to split train dataset into train and validation. not to use test set as validation.


Goliath rebalance

About the PR

Adjusted Goliath death threshold from 300 to 250.  The Goliath now has less health
Adjusted Goliath move speed from 2.50 to 2.00.  The Goliath is now slightly slower
Adjusted Slash damage from 15 to 10.  The Goliath now does 10 Slash and 10 Pierce per melee hit.

Why / Balance

The goliath provides a new and different combat challenge for salvage players, however given the quantity of them found within vgroids, they are slightly overtuned.  Their very fast ranged AoE stun has few counterplay options in cramped areas and presents a threat that encourages players to avoid them, which is good.  These adjustments to health, movement speed, and damage will lower the skill floor slightly so that salvage players will be slightly less punished when encountering these mobs, while preserving their status as a dangerous threat that should ideally be avoided unless the player is sufficiently equipped.
Requirements

[ X] I have read and I am following the Pull Request Guidelines. I understand that not doing so may get my pr closed at maintainer’s discretion
[X ]this PR does not require an ingame showcase

Breaking changes

Changelog

I think the salvage rework should be fully implemented before any balancing is really done.

i think this is reasonable but i will wait for emos input

I think the salvage rework should be fully implemented before any balancing is really done.

I don't know the ETA on the full rework but I'm proposing these changes to make salv a little more efficient in the meantime.  I just finished a shift with 3 salvs with enforcers trying to kite a goliath and we all barely lived.  The code is very easy to adjust so I'm not suggesting that these changes be made permanently.  A separate approach would be to make goliaths more rare given their strength but I think that's handled by asteroid generation which I don't understand too well.

I mean goliaths will implicitly be more rare once the other salv mobs get merged like hivelords or basilisks or whatever

i think the biggest problem with goliaths is that their ai kinda behaves funky. They will kite you for no real reason, including after stunning you rather than actually attacking you with their massive damage

bump?


RFC: WIP SC14481 support, ghidra SFR script, various other stuff that might or might not make sense

Initially, I just wanted to add support for SC14481, which ended up snowballing into misc stuff here and there, mainly to make it easier to work with this.
I'm happy about any feedback regarding those changes.
On top of this, I would really like to take apart the ~1k LOC test.c before doing anything else, but figured I should check with you before actually doing all that and dumping it on your doormat without asking :)
Regarding SC14481:

@jugendhacker and I got the stub to boot on our A415s after disabling QSPI, which does not exist on the 81 chip.
Instead of SPI, the firmware seems to be (mostly? completely?) stored in chip internal ROM. We managed to dump it (with the arbitrary memory read I added), but it lacks a lot of data that should be there (localization, UI strings in general).

I'm not super happy with the read command (it's very similar to the flash dump command), so I'll probably revise all that. Problem is of course that I don't have a C430 or similar to test if I broke anything.
Also at camp, we started analyzing both the boot rom and the dumped (part of the) firmware to figure out where the rest of the data might be hiding. We did not get very far then.
By now, I've had time to make a ghidra script to automatically set up at least SFRs for 14481. It helps immensely to get off the ground with a fresh dump, so I've included it here as well.

Also thanks again to @Manawyrm for the docs, they helped a lot so far (especially the register definitions) :)

#13 is probably related


Fix commands that do not pass the specified tests.

Updated
#88 Updated callbacks command to be its own group

#89 Updated cqg command to be its own group

#90 Updated help, code commands to be its own group

#94 Updated all commands to pass the tests

#95 Updated time command to be its own group

@twalton83 I've updated to fix the some of the issues.
I wasn't so sure about the git workflow, for example when to make commits or etc, so I just made a commit every time I updated the each command.
Please let me know if there's some I could have improved!

@twalton83 I've updated to fix the some of the issues.
I wasn't so sure about the git workflow, for example when to make commits or etc, so I just made a commit every time I updated the each command.
Please let me know if there's some I could have improved!

#93  Updated shrug command to be its own group

#93  Updated shrug command to be its own group

I should have been more clear that these should have been separate PRs, my bad! Just make a separate PR moving forward if it’s for a separate issue.

I should have been more clear that these should have been separate PRs, my bad! Just make a separate PR moving forward if it’s for a separate issue.

Oops, my bad! Should I close this pull request and make each one for each issue?

Oops, my bad! Should I close this pull request and make each one for each issue?

No worries, just a heads up moving forward!

No worries, just a heads up moving forward!

Okay, I will make sure of it next time :) Thanks for the heads up!

Thanks again for doing all of these!