Fix PATCH operations in Network

The only async PATCHes in NRP are VirtualNetworkGateway and virtualNetworkGatewayConnection. Removed x-ms-long-running-operation from the others. Also, fixed incorrect PATCH definitions.
Contribution checklist:

[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[x] The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

[x] Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[x] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

Automation for azure-sdk-for-python

Can one of the admins verify this patch?

Automation for azure-sdk-for-go

@KrisBash please take a look


Switch to using mozilla/recommended configuration for extensions/firefox.

This switches to using the mozilla/recommended configuration for extensions/firefox. The configuration is supplied via eslint-plugin-mozilla, already included via npm in this repository.
The benefits are that this is closer to the Firefox ESLint configuration (which is better when exporting to mozilla-central), and as eslint-plugin-mozilla is updated, you'll get any new rules more-or-less automatically.
I've de-duplicated the configuration file, the only thing I didn't remove was the parser ecmaVersion - currently it is set to 6, for mozilla-central it is currently 8. I wasn't sure if this could/should be changed or not.

I've de-duplicated the configuration file, the only thing I didn't remove was the parser ecmaVersion - currently it is set to 6, for mozilla-central it is currently 8. I wasn't sure if this could/should be changed or not.

As mentioned in https://github.com/mozilla/pdf.js#firefox-and-seamonkey, we have (historically) tried to keep the Firefox addon compatible with the current ESR release (i.e. 52 as of this writing).
So provided that bumping the ecmaVersion doesn't enable support for features not in Firefox ESR, then I personally don't see an issue with it.

I'm also fine with this. By the way, did you remove getBoolPref and log because they are unused?

I took a look back, and it looks like we didn't start using ecmaVersion generally until sometime after 52. For now, I've updated the commit to add a reference to update the ecmaVersion when support for 52 is dropped.
I've also turned off experimentalObjectRestSpread as that was only implemented in FF 55.
getBoolPref and log were indeed unused in that file. I think there's versions of the same functions in other files if I remember correctly.


PR1 更新README.md 推理部分方法1+2 And RP2 update model postprocess module in tools/inference.py

RP1: 更新README.md 推理部分方法1+2 code demo and verify the code is correct.

this update is relate to issue https://github.com/gitabtion/BertBasedCorrectionModels/issues/43

RP2 update model postprocess module in tools/inference.py and this update is relate to issue: [https://github.com/gitabtion/BertBasedCorrectionModels/issues/42]

I offline build and test the code can run successfully. Any further problems, please let me know, I will fix it, thanks for your merge

new pull request https://github.com/gitabtion/BertBasedCorrectionModels/pulls
thanks
BestRegards
Yazhou
在 2023-05-12 19:21:36，"Heng Cai" @.***> 写道：
Merged #44 into master.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>


Collect Atlassian security bugs

See https://jira.atlassian.com/browse/TRANS-2623?jql=labels %3D security

See also https://confluence.atlassian.com/security/multiple-products-security-advisory-log4j-vulnerable-to-remote-code-execution-cve-2021-44228-1103069934.html


Code Review for: Feature display reservations popup

Hello Team 👋,
Could anyone help me with the code review for this part of the reservation's popup:
According to the requirements, I have to:

✅ Create a reservations popup only with the top section (displaying details of the selected item)

✅ When the popup loads, the webapp retrieves data from the selected API and shows details about the selected item.

✅ Also there are some fixes about displaying images, for the navbar logo.

Thanks for your support. 👌
Cheers,
Luis

Te comiste el conflicto de la rama joven @cilfonegabriel
Status: Approved :green_circle: :1st_place_medal: :100:


OLS-90: Define a configuration CRD to specify OLS configuration

Description
Added CRD for further implementation of the operator
This CRD corresponds to the application configuration
The operator source code will be added later.
Type of change

[ ] Refactor
[x] New feature
[ ] Bug fix
[ ] CVE fix
[ ] Optimization
[ ] Documentation Update
[ ] Configuration Update
[ ] Bump-up dependent library

Related Tickets & Documents

Closes https://issues.redhat.com/browse/OLS-90

Checklist before requesting a review

[x] I have performed a self-review of my code.
[x] PR has passed all pre-merge test jobs.
[ ] If it is a core feature, I have added thorough tests.

Testing

Please provide detailed steps to perform tests related to this code change.
How were the fix/results from this change verified? Please provide relevant screenshots or results.

/approve
no further comments from me at the moment, though i think we'll want to introduce more static validation rules in the schema over time.
still looking for @syedriko to give it a look to ensure he feels it's sufficiently aligned the w/ the config.yaml that it will need to be translated into

/lgtm
/approve
good enough as a starting point to work from


add HZC D688-ZG quirk

Proposed change

Add quirk for HZC Dimmer-Switch-ZB3.0 Rotary Dimmer
Additional information

Fixes #2987
Checklist

[X] The changes are tested and work correctly
[X] pre-commit checks pass / the code has been formatted using Black
[ ] Tests have been added to verify that the new code works

Still verifying functionality

I have these switches with two different firmwares where firmware 0x00000001 behaves OK even without the quirk, the ones with 0x00000002 will turn on and off repeatedly and through error messages without the quirk. With quirk both versions operate fine.

@TheJulianJES could you also add the similar dimmer from EcoDim to this quirk? See #2865 for the info. This I think would fix that longstanding issue also! :)


After hiding/minimizing Win app window it reappears as black

If you hide or minimize the app window, it appears completely black if you open it up again.
Reported by windows_native_app/7.3.27 and 7.3.38.
Reported by #206597, #207427 and #206960 - report back once the issue is resolved.

So far there does not seem to be any indication of what causes this.

One comment from the user:
The only way to get the small black screen to go away and be replace with the normal timer screen is to go to Windows Task Manager and shut down the Toggl app. Then it will pop-up properly.

Confirm on 7.3.87 dev. win10.
How to reproduce:

click close icon so it goes to tray
run the app again via desktop link or link in Task Manager
we got it! the app is black
if you now click to icon in tray the app is rendered correctly

@egoroof: Thanks for the steps! I can reproduce it, so we should hopefully be able to fix this soon.


[Client] add a ping sound when a peer joins & leaves

Sound will make this fun

Also, it might be cool to 'gray-out' a peer when they leave in the peers list

Lol let me get this


[feature request] Add Azure firewall as an option

Could we add Azure firewall as an option? I think that'd be quite useful since most deployments would want to restrict egress from AVD. Thanks.

@mpchen thanks for the feedback, we are investigating.

https://learn.microsoft.com/en-us/azure/firewall/protect-azure-virtual-desktop?tabs=azure

Thanks for the info,
cc: @swathibhat1  let's create an item to track this feature.

I do agree the need for inspecting and filtering egress traffic from AVD, but isn't this function typically a part of platform landing zone and the 'network hub', so it is deployed as part of platform foundation (different subscriptions), rather than AVD landing zone?

@swathibhat1 let's created this item in the features backlog to time the work on it.


Restore iterative implementations of ord=1

This PR ( https://github.com/tensorflow/cleverhans/pull/829 ) turned them iterative attacks that use ord=1 because they aren't known to be strong. To turn them back one:

We should implement correct projection to the norm=1 ball, or come up with some other way to optimize over the norm=1 ball that we know is at least as effective as textbook PGD.
We should check whether it's better to literally do gradient descent or whether it's better to do iterated FGM. If the local linear approximation is valid, FGM will raise the loss more than any other step with the same L1 norm, but it's not clear that that's the right way to think about the problem. For the case of ord=1, it seems weird to use an inner loop step that can change only one pixel at a time.

(Note that we do have an optimal implementation of the single step ord=1 attack)

This PR (https://github.com/tensorflow/cleverhans/pull/1036) implements the correct projection onto the norm=1 ball using Duchi et al.'s O(d*log(d)) algorithm.
It also implements a new multi-step attack that is much more efficient that iterated FGM for the l1-case, simply by relaxing the sparsity of the gradient updates.

Closing as we update the library to v4 and drop support for version < 4.

Closing as we update the library to v4 and drop support for version < 4.


Shoots registered as Seeds do not get Seed conditions updated

How to categorize this issue?

/kind bug
What happened:
Shoots registered as Seeds sometimes do not get Seed conditions updated.
This results in the Seed resource to have a mismatch in conditions with the corresponding Shoot resource leading to Shoots falsely reporting as healthy or non-healthy. The dashboard relies on the conditions in the Shoot and therefore will display healthiness potentially wrongly.
What you expected to happen:
Conditions to be coherent between Seed and Shoot resource for managed Seeds
How to reproduce it (as minimally and precisely as possible):
Unclear - seems like it only sometimes happens and self heals after days.
Anything else we need to know?:
Most likely introduced with https://github.com/gardener/gardener/pull/5013
For the scheduling decision the Seed resource is used which in our case has the bootstrap condition set correctly. Therefore, this bug is not influencing scheduling decisions.

/assign

@BeckerMax and I looked into this problem and we recognized two problems in the shoot condition controller, that can lead to the described behavior under certain circumstances:

filterSeedForShootConditions doesn't evaluate to true for Add events. This is relevant for situations, where the Seed reflector looses the watch connection and has to do a full relist. In this case, the informer emits Add events for all objects in the cache and the controller would need to enqueue them again, because it might have missed relevant Update events. As the predicate doesn't evaluate to true, the condition might change during a timeframe where the watch connection is broken and has to be reestablished, the controller will not update the shoot conditions until the seed conditions change again. Note: if the shoot reflector would be similarly effected, it would also emit Add events, which would enqueue them. Hence, the described situation can only become a real problem if the seed informer breaks but the shoot informer doesn't.
If the seed condition is changed multiple times in (quick) succession, it might happen, that the shoot cache doesn't contain the status update from the first reconciliation run in the next run and hence calculate a wrong diff on the client-side (based on a stale shoot object) and hence only copy the last{Update,Transition}Time fields in the condition, leaving the status, reason and message untouched. This happens, if updateShootConditions is called with a stale shoot param, here: https://github.com/gardener/gardener/blob/65655ff2ebdb00f8c678b15c9f018ec2a19a137c/pkg/controllermanager/controller/shoot/shoot_conditions_control.go#L137-L141
The following snippet demonstrates the wrongly calculated diff based on a stale shoot object:

func main() {
	condition := gardencorev1beta1.Condition{
		Type:               gardencorev1beta1.SeedBootstrapped,
		Status:             gardencorev1beta1.ConditionTrue,
		Reason:             "BootstrappingSucceeded",
		LastUpdateTime:     metav1.NewTime(time.Date(2022, 1, 1, 0, 0, 0, 0, time.Local)),
		LastTransitionTime: metav1.NewTime(time.Date(2022, 1, 1, 0, 0, 0, 0, time.Local)),
	}
shoot := &gardencorev1beta1.Shoot{
	Status: gardencorev1beta1.ShootStatus{
		Conditions: []gardencorev1beta1.Condition{*condition.DeepCopy()},
	},
}

condition.LastUpdateTime = metav1.Now()
condition.LastTransitionTime = metav1.Now()
conditions := []gardencorev1beta1.Condition{condition}

patch := client.StrategicMergeFrom(shoot.DeepCopy())
shoot.Status.Conditions = conditions
jsonBytes, _ := patch.Data(shoot)
fmt.Println(string(jsonBytes))

// result does only contain LastUpdateTime and TransitionTime, missing status and reason: {"status":{"$setElementOrder/conditions":[{"type":"Bootstrapped"}],"conditions":[{"lastTransitionTime":"2022-01-20T10:20:59Z","lastUpdateTime":"2022-01-20T10:20:59Z","type":"Bootstrapped"}]}}
}

This is likely the problem as we saw cases where the lastUpdateTime and lastTransitionTime matched between Shoot and Seed conditions but the Status and Reason differed. We were able to correlate the timing with an overload situation on gardener-apiserver (high request rate, severe CPU throttling). This could explain, that the controller-manager's watch connection for shoots was either broken or lagging behind severely to cause the second problem due to a stale cache read. In addition, we saw that the Seed condition flipped in a time range of about 1-2 minutes during the overload situation of the apiserver.

Thanks for the detailed description @timebertt.

The problem should be resolvable by a restart of gardener-controller-manager.

Is there any further mitigation planned? How about additional periodic re-syncs (see comment)?

For problem number 2. we discussed switching the update strategy from Patch with strategicMergePatch to Update when updating the shoot conditions. This ensures that the shoot object in the cache is up-to-date otherwise it will be retried.
I will open a respective PR.

I dug a bit deeper into the cache resync topic, so here is some additional information for documentation purposes:

cache resyncs don't involve an API call (they only process all object's in the store on the client-side and Sync events to the cache's internal queue, see reflector.go and delta_fifo.go)
these Sync events emit Update events to the event handlers registered on the informers, see shared_informer.go
such resync Update events have the same resourceVersion on newObj and oldObj
kubernetes controllers sometimes filter out such resync events for "owned objects" (e.g. ReplicaSets in the Deployment controller, see deployment_controller.go. Interestingly, they enqueue pretty much all updates to the "controlled objects", see deployment_controller.go. However, their controllers are much more lightweight than ours
kube-controller-manager has no manual periodic sync periods like some of our controllers and instead rely on the cache's resync events. kube-controller-manager's default cache resync periodic is 12h, see defaults.go
the default cache resync period in our controller-runtime caches is 6h, see runtime_client.go


Fill out a minimal description for base image offers in Partner Center

The five base image offers in partner center shown in the image would benefit by having some minimal appropriate level of description.

Workflow

Ed and Reza come up with proposed text for base offers.
Jacob applies it in partner center to the five base image offers.


Add BlueSky

Insert URLs to the project here: https://github.com/EIAgov/BlueSky

[x] The projects is active, documented, open source licensed, shows usage from external parties and is directly targeting environmental sustainability. Find more details in the Contribution Guide.

All issues labeled as Good First Issue of the project listed on OpenSustain.tech will be visible on ClimateTriage.com. This is a great way to welcome new community members to your project.
All new projects listed will be posted on our Mastodon channel.
Note: The project does not show usage because it is brand new, but because of the social/political relevance of the IEA open sourcing this, I think a usage indicator is not needed.

@BrianCultice


Unable to locate executable file: npm

I am trying to set up this action for the first time and am getting the following error when it tries to start my application:
Error: Unable to locate executable file: npm. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.

I can run npm commands in all of my other build steps so I'm not sure what's happening.
- name: Run Cypress Tests
  uses: cypress-io/github-action@v5
  with:
    install: false
    working-directory: ./packages/cypress
    command: npm run cypress:critical
    start: npm start -- --scope packages/backend
    wait-on: 'http://localhost:4000'

@reediculous456
You might find it helpful to refer to the README: Debugging section to get more detailed logs to look at, which could help explain what happened when your error message was output.

@reediculous456
Another option is to fork this repo and run a suitable example workflow to compare it with your workflow. Each of the examples can now be individually triggered since they are set up with workflow_dispatch.
.github/workflows/example-custom-command.yml for instance includes the following yaml instructions, similar to yours:
  start:
    # example where instead of forming the default "cypress run ..."
    # the user can specify their own command
    runs-on: ubuntu-22.04
    steps:
      - name: Checkout 🛎
        uses: actions/checkout@v3

      - name: Custom tests 🧪
        uses: ./
        with:
          command: npm run custom-test
          working-directory: examples/custom-command

uses: ./ is equivalent to uses: cypress-io/github-action@master so that the examples always run with the latest code, even if it has not yet been released.

I think I have this figured out now. I have a weird setup because I am using Lerna and my file tree looks like this:
packages
    ├── client
    ├── server
    └── cypress

so I needed to use this configuration:
- name: Run Cypress Tests
    uses: cypress-io/github-action@v5
    with:
      install: false
      project: ./packages/cypress
      command: npm run cypress:critical
      start: npm run start:prod -- --scope server
      wait-on: 'http://localhost:4000, http://nginx'

@reediculous456

I think I have this figured out now.

Thanks for sharing about your use of the project: parameter!


[WIP] sorted features based on type

I assigned the feature types numbers to use for sorting, where MultiPoint and Point are last. From my understanding, the rest of the features' order does not matter - is that correct?
Also, is this order right? i.e. if Points are last than they will overlap everything else?
Lastly, was going to think on this a bit more to see if there is a way to do it without sorting and then looping, since it is adding computing time. I'm going to play around with sorting inside of the loop.
cc/ @bsudekum

@allierowan can you add a test?
order in:

line
point

order out:

point
line

@bsudekum added a test - what do you mean by order out and order in?
Thanks!

Take a look at these two feature collections:

linstring first:http://geojson.io/#id=gist:anonymous/4895b6d50dc1ab66396a7c5d69520f3b&map=9/40.3549/-90.3625
point first: http://geojson.io/#id=gist:anonymous/5263370d25e5fdd99d98bd4ed5934d7d&map=9/40.3549/-90.3625

If a line is first in the feature collection, then after sorting it should come out second.

Okay I thought that's what you meant but just wanted to be sure 👍

Another test to take a look at: ['point', 'point', 'line', 'point', 'line', 'point'] -> ['point', 'point', 'point', 'point', 'line', 'line']

@bsudekum yep good call. Right now I'm just trying to fix these tests that were relying on order - does it matter if the sources and layers are in different orders?
  var style = {
        version: 8,
        sources: makeSource(geojson, sourceId),
        layers: addLayers(geojson, sourceId, []),
        glyphs: 'mapbox://fonts/mapbox/{fontstack}/{range}.pbf'
    };

@allierowan no, it should not matter. They are linked by the sourceId.

@bsudekum based on my test, it should be ['line', 'line', 'point', 'point', 'point', 'point']?


trigger drag from a button and leave elements where they are

Hey. I want to use this lib, but I need the drag to only start when I'm clicking an specific button. Also, it need's to let the elements where they are. Makes no sense to push the elements to the right or to the left

have a look at ng-cancel-drag

I don't want to cancel the drag. I want it not to go right or left

You'll need to modify the moveElement function like this :
var moveElement = function (x, y) {
x=0; // override
                        element.css({
                            transform: 'matrix3d(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, '+x+', '+y+', 0, 1)','z-index': 99999,
                            '-webkit-transform': 'matrix3d(1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, '+x+', '+y+', 0, 1)'
                            //,margin: '0'  don't monkey with the margin,
                        });
                    }

Thanks!


feat(@angular/cli): add AOT parameter missingTranslation

This adds the new parameter missingTranslation for AoT that was added in angular/angular/pull/15987 and that lets you define the MissingTranslationStrategy.

The PR angular/angular/pull/15987 has been merged, this one can be merged as well now once reviewed.

I added a check for the version, not sure how to add a test for that though since it's only a warning (not a fail).

@ocombe sorry, I should have been more specific: the warning as you added looks good, the test is to see if this functionality works (e.g. when you pass the flag, it does what you expect it to do).

Tests added, should be good now!

Thanks a bunch for keeping this up to date 👍

@hansl can we merge this PR?

@ocombe can you please rebase... there are conflicts.

Rebased onto master :-)


Org-mode html export adds newlines to babel source blocks

What did you expect to happen?
Exporting source blocks with org-mode and babel to HTML should just work, with formatting of source code as shown in org file
What actually happened?
The exported source blocks have newlines before every change of text colour (i.e. before every span).
The exported html code gets transformed, presumably by the auto-formatted, from:

some_function("string")

to

some_function(
"string")

This breaks formatting, causing a line break before every change of colour in the source output.
This seems to be due to a known issue in html-tidy:
https://github.com/htacg/tidy-html5/tree/release/5.6
Are there actions that need to be taken in doom? A check in doom doctor? Or disable auto-formatting during html output?
It isn't clear to me what the best choice might be.

It seems format-all is overzealously reformatting those HTML buffers. See if any of the following solve your issue (try them separately):
(defadvice! inhibit-formatting-while-exporting (orig-fn)
  :before-while #'+format-probe-a
  (not (bound-and-true-p org-export-current-backend)))

;; or

(defadvice! inhibit-formatting-while-exporting (orig-fn &rest args)
  :before-while #'+format-buffer-a
  (not (bound-and-true-p org-export-current-backend)))

As of 4c61f22 the auto formatter will no longer kick in in temporary or special buffers, only file buffers. Let me know if that doesn't resolve your issue and I'll reopen it. Thanks for bringing it to my attention!

Sorry to be the bearer of bad news. I think this might work for exporting to a html buffer, but not exporting to a html file. After some digging with edebug, I think I've got an idea of what is going wrong.
When exporting to file, the org-export-to-file function is used, which contains the lines:
(with-temp-buffer
    (insert output)
    (let ((coding-system-for-write ',encoding))
        (write-file ,file)))

The files is being saved with write-file, then (from the traceback) the +format-probe-a function. But inside that function, current buffer is the name of the file, and not a temp or special buffer.
Traceback for call to +format-probe-a is:
(at this point, (current-buffer) is "analysis-of-regions.html")
...
format-all--probe()
format-all-buffer--from-hook()
run-hooks(before-save-hook)
basic-save-buffer(nil)
save-buffer()
write-file("analysis-of-regions.html")
(let ((coding-system-for-write encoding)) (write-file file))
(progn (insert output) (let ((coding-system-for-write encoding)) (write-file file)))
(unwind-protect (progn (insert output) (let ((coding-system-for-write encoding)) (write-file file))) (and (buffer-name temp-buffer) (kill-buffer temp-buffer)))
(save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn (insert output) (let ((coding-system-for-write encoding)) (write-file file))) (and (buffer-name temp-buffer) (kill-buffer temp-buffer))))
(let ((temp-buffer (generate-new-buffer " temp"))) (save-current-buffer (set-buffer temp-buffer)
...
org-export-to-file(html "analysis-of-regions.html" nil nil nil nil nil)

The files is being saved with write-file, and in the save hook the +format-probe-a is being called function. But inside that function, current buffer is set to the name of the .html, and tests for a temp or special buffer return nil.

This might be considered a bug with Emacs or org. Should write-file invoke before-save-hook and after-save-hook? It uses save-buffer under the hood, so it does, but write-region doesn't. Why should write-file?
Otherwise, why is org-export-to-file using write-file, which could trigger save hooks? Why not use write-region instead?
In any case, I've inhibited save hooks in org-export-to-file as of d5d0fb9, which should resolve this issue for now.

I'll keep this open until it is addressed upstream.


New release 1.1.0 does not include binaries

Hi, I was trying to use the count-vowel example with the new 1.1.0 release, but I could not get it to work, the process seems to just die.
On closer inspection, the 1.1.0 version does not include any binaries. The 1.0.1 version is about 38 Mb, while the 1.1.0 is just 28Kb.
So I guess something went wrong in the build?

I don’t think we ever included them. That was an open issue. Do you mind checking @evacchi

This one does: https://mvnrepository.com/artifact/org.extism.sdk/extism/1.0.1

I meant native libraries when I said binaries. If I transplant the native libraries from the latest release (1.8.0) into the 1.1.0 it seems to work alright


Randomly stops working in games

I feel like this has probably been reported before but I’ve updated DS4 Windows, I’ve reinstalled it, I’ve reinstalled the Windows 10 controller drivers and yet it will randomly stop working in games like Ghostbusters, Mafia, basically any game that I don’t own on Steam and have to use DS4 for.
All the logs say are:
Using shared mode
Found Controller:90:89:5f:89:0f:D4 (BT)
Controller 1 using profile “normal remote”

#620
you are probably trying to use the obsolete version if you are downloading from this Jays2Kings/DS4Windows site. Read the linked post and follow the link to up-to-date version of DS4Windows app.
https://github.com/Ryochan7/DS4Windows/wiki/Troubleshooting#steam-doesnt-see-the-virtual-output-controller-if-a-profile-uses-the-dualshock4-output-type-steam-sees-the-ds4-controller-only-if-ds4windows-uses-xbox360-output-controller-type

Ya I found that out a month ago, I probably should’ve deleted this. But
thanks for saying that!
On Mon, Nov 30, 2020 at 07:35 mika-n<EMAIL_ADDRESS>wrote:

#620 https://github.com/Jays2Kings/DS4Windows/issues/620
you are probably trying to use the obsolete version if you are downloading
from this Jays2Kings/DS4Windows site. Read the linked post and follow the
link to up-to-date version of DS4Windows app.
https://github.com/Ryochan7/DS4Windows/wiki/Troubleshooting#steam-doesnt-see-the-virtual-output-controller-if-a-profile-uses-the-dualshock4-output-type-steam-sees-the-ds4-controller-only-if-ds4windows-uses-xbox360-output-controller-type
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Jays2Kings/DS4Windows/issues/627#issuecomment-735759975,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQHD5SCN4NN7RUBER6TFX4TSSOGPTANCNFSM4TGCAGVA
.


Minor fixes

Signed-off-by: Ken Evensen<EMAIL_ADDRESS>
Added note to README.md about base64 in Darwin environments
Added --set-string serverConfigContents to README.md for install and upgrade commands
Added patch verb to tiller RBAC
Bumped the micro version on the chart.

/gcbrun

/gcbrun

/gcbrun


TPM Detect tests don't support TPM 1.2

The problem you're addressing (if any)
TPD tests use tpm2-tools which obviously only work with TPM 2.0. Performing the tests on Optiplex 7010 fails because it has TPM 1.2.
Describe the solution you'd like
Provide an alternative way of detecting TPM if using tpm2-tools won't work.
Where is the value to a user, and who might that user be?
Otherwise the tests can't be performed on devices with older TPMs
Describe alternatives you've considered
instead of tpm2-tools maybe one of the following could be used?
dmesg | grep tpm
journalctl -g tpm
ls /sys/class/tpm
cat /sys/class/tpm/tpm*/tpm_version_major
Additional context
No response

instead of tpm2-tools maybe one of the following could be used?

yes that would work if it's sufficient for tests
there's also tpm-tools from the TrouserS project

I think this PR https://github.com/Dasharo/open-source-firmware-validation/pull/487/files included a keyword that could be used in those tests.


[ECard Settings] Update which cards are displayed / grouped together under Assigned Cards

There's a few bugs from displaying cards on the cards page / assigned cards section.
I will clean up this flow to display the proper cards on each page and ensure they are properly linked to the details page
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01a9575dc233d69bda
Upwork Job ID:<PHONE_NUMBER>688580608
Last Price Increase: 2023-10-30

https://expensify.slack.com/archives/C03U7DCU4/p1698226289306649
Card pages are all linking to the same cards

not overdue

closing as dupe


Cow: Watch vietkingtravel.com

Cow requests the watch of the watch_keyword vietkingtravel\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

vietkingtravel\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by VLAZ in Charcoal HQ


check https://github.com/minio/mc also works as cli client

https://github.com/minio/mc
Its lighter than the Amazon one.

https://github.com/jhunt/s3 also looks good and light

Thanks @gedw99
MinIO Client  is for MinIO object storage only.
jhunt should work for nats-gateway if it is S3 complaint CLI.

minio mc works ok


Kubernetes-anywhere on azure (networking)

I'm facing an issue right now with an azure/kubernetes migration, which is related with the following:
We have a VNET1 (ex: <IP_ADDRESS>/16) and a VNET2 (ex:<IP_ADDRESS>/16), within each of the VNETs we have a gateway and we connect both VNETs using these gateways and VPN connections.
VNET1 has an elasticsearch cluster, hosted on subnet <IP_ADDRESS>/24 and VNET2 has a kubernetes cluster hosted on <IP_ADDRESS>/24 (which is provisioned by kubernetes-anywhere).
VNET1 has 3 client boxes for elastic (ex: <IP_ADDRESS>, <IP_ADDRESS> and <IP_ADDRESS>), and VNET2 has 2 kuberenetes nodes (ex: <IP_ADDRESS> and <IP_ADDRESS>) as well as a master.
Inside the VNET2 kuberenetes nodes run kubernetes pods (which have a containerized api, that needs a connection to the elasticsearch cluster).
Our kubenetes nodes (ex: VNET2 - <IP_ADDRESS> and <IP_ADDRESS>), can connect to the elasticsearch nodes (ex: VNET1 - <IP_ADDRESS>, <IP_ADDRESS> and <IP_ADDRESS>).
However the pods/containers which run on these nodes, and are assigned to their own subnets (ex: <IP_ADDRESS>/24, <IP_ADDRESS>/24), cannot connect to the elasticsearch nodes/VMs or to VM outside of the nodes subnet for that matter. Independent of which VNET this VM might sit on.
Is there something misconfigured in the networking model? Should I be using an overlay network? If I deploy my pods with shared host network, I get connection to elastic, but I can only share one pod per host, otherwise they conflict.
Any help is greatly appreciated.

Hi Bruno. I think that Tim was right on the mailing list. Can you try adjusting your CIDRs or adjusting the non-masquerade-flag on the kubelets?

I'm also trying to get an answer from internal sources to determine if Tim's assumption is correct. Based on the fact that it works from the host network, I'm inclined to agree with him.

Hi Cole,
a bit of an update on this one. If I create a completely new VM/network interface on a diferent subnet in the k8s cluster VNET, I am now able to have the pods ping it, as long as I add that subnet on the route tables generated on azure.
I'm still not able to ping a VM that is on the other VNET (connected by gateway vpn connections).
So the node can ping these VMs, but the container still cannot.
I tried adding the non-masquerade-flag on the kubelet service, set to <IP_ADDRESS>/8 and restart the service, but still no luck.

(Cross-linking the mailing list post since the discussion is split between here and there: https://groups.google.com/forum/#!msg/kubernetes-dev/Gp2QBEcuTwI/hl7RKdn2GgAJ)

Thanks Cole,
I would love if someone could help me with this network configuration, but I realise that is a bit of a hard request, as it involves having two VNETs and gateway vpn connections between them in order to be able to replicate.

Hello folks,
IP addresses assigned to pods are not visible in the network. Hence to route to it, you need explicit UDRs (User defined route tables) that point to the hosting node as the next hop IP address. Such an UDR mechanism would nto work for cross referring across VNets that are connected via S2S gateway. You should be using VNet Peering (https://azure.microsoft.com/en-us/documentation/articles/virtual-network-peering-overview/) which allows UDRs to work across VNets, meaning the nexthop IP address can be in a peered VNet.


Body Tracking API documentations need offline download

Current Body Tracking API documentation in Doxygen has no elligant solution for downloading the entire API set as a PDF (or other) for offline saving.

Won't fix

For those needing archive for long-term support, I was able to get a scrape of the most important body tracking APIs using the following. It is not pretty. Yet, start browser navigation at modules.html and the right pane content and links seem to work. 🤦♀
wget --recursive --convert-links --page-requisites --restrict-file-names=windows --timestamping --level=inf --no-remove-listing --domains microsoft.github.io --no-parent --adjust-extension --tries=5 --wait=1 --random-wait https://microsoft.github.io/Azure-Kinect-Body-Tracking/release/1.x.x/modules.html


Solves keyword with issue number 604

This pull request is in regards to Issue #604.

Closes #604

Hi, thanks for contributing to Strawberry 🍓!
We noticed that this PR is missing a RELEASE.md file. We use that to automatically do releases here on GitHub and, most importantly, to PyPI!
So as soon as this PR is merged, a release will be made 🚀.
Here's an example of RELEASE.md:
Release type: patch

Description of the changes, ideally with some examples, if adding a new feature.

Release type can be one of patch, minor or major. We use semver,so make sure to pick the appropriate type. If in doubt feel free to ask :)

Don't worry about the release file as this is a docs only change

Hey, heads up. GitHub doesn't recognize the email you made the commit with (i.e. it's not linked to your GitHub account).
I'd recommend looking at the docs here and here.

Thx, should be fixed now.

Can you please add fixes - solves keyword with issue number into PR details, so it can attach it with the issue.

Not a big deal though, I can merge anyway, but I think it'd be nice if the commit is properly attributed to you 😊 let me know!

@patrick91, I've gone ahead and run the command. I hope that fixes it but I'm unsure how to check. Please let me know.

@Paolo-Cosentino I'll try to help you out here :slightly_smiling_face:

If you look at this screenshot, you can see that the commit you made didn't have your profile picture and it's not a link to a real account. This indicated that you either made your commit in Git with the wrong configuration, or you haven't told GitHub about the configuration you want to use. Because you said you were knew to this I figured you were probably unaware :slightly_smiling_face:
You've made two commits (and a merge, but that's not relevant here) now, both with identical changes. If you look at the "patch" for the PR (you can view it by adding .patch to the end of the URL -> here), you'll see two identical commits with just the email address for the author (you) changed. This tells me that you've fixed the problem locally on your computer!
@patrick91 had you "amend" the commit, which is the easier option, and why there are two commits. It just tacks on a second commit that "fixes" the first one. Another option would have been to completely rewrite the commit and replace the commit, but this is a bit more prone to error as this overwrites the history of the Git tree. As we squash and merge our pull requests, the end result should end up looking the same, so there's no issue with the route you've taken.
What happened here is that Git lets you push commits from other people (one of the features of being a decentralized version control system). Every commit stores the information about who created it. GitHub didn't have an association of that commit's [email address + name] with an account and just used a placeholder "unknown" user in your place. Now that you changed your local Git configuration to match what GitHub expects, your commits will be properly attributed to your account.
Hopefully this makes sense :+1:


grpc: 1.62.1 -> 1.67.0

Updates grpc and all corresponding python packages to 1.67.0.
Fixes current incompatibility between packages due to differing versions. #349050
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

could/should this include the additional changes to python312Packages.grpcio proposed in #349727 ?

could/should this include the additional changes to python312Packages.grpcio proposed in #349727 ?

I was not aware of additional changes other than updating the version.
I force-pushed the other changes.
Thanks for noticing!


[firebase_messaging] documentation not according to documentation in firebase causing build failure

Describe the bug
firebase_messaging's  Documentation not according to documentation in firebase causing build failure
To Reproduce
Steps to reproduce the behavior:

Following the documentation in https://pub.dev/packages/firebase_messaging, you will enter this line:  'com.google.gms:google-services:4.3.0' in [project]/android/build.gradle file
Run the project
Have the build fail with:
Execution failed for task :app:transformNativeLibsWithStripDebugSymbolForDevDebug
tried to access method com.google.common.io.Files.fileTreeTraverser()Lcom/google/common/collect/TreeTraverser; from class com.android.utils.FileUtils which is totally unreadable

Expected behavior
following the documentation the build should run smoothly
Additional context
in firebase's flutter documentation, it clearly states that Flutter is currently compatible with version 3.2.1 of the Google Services plugin., so the documentation in firebase_messaging ought to be changed to reflect this limitation instead of showing version 4.3.0 as if it were working
Thank you,
Regards,
Duarte

@d-silveira Thank you, it's a known bug, I'm going to close the issue to avoid duplication. Please follow https://github.com/FirebaseExtended/flutterfire/issues/57 and https://github.com/FirebaseExtended/flutterfire/issues/243.


Websocket await hangs indefinitely despite reached timeout

The following code hangs indefinitely, if only less than two messages have been received. In other woards, await(finiteDuration) has no effect.
exec(
      ws("...")
        .sendText("...")
        .await(1.seconds)(
          ws.checkTextMessage("checkFrame").silent,
          ws.checkTextMessage("checkFrame").silent
        )

If the two checks are packaged in separate awaits, timeouts work correctly:
exec(
      ws("...")
        .sendText("...")
        .await(1.seconds)(ws.checkTextMessage("checkFrame").silent)
        .await(1.seconds)(ws.checkTextMessage("checkFrame").silent)
       )

Duplicate of #4434


Fix bugs

Replace hashmap with sync.Map everywhere in maestro
Bug fixes for the following tickets
https://jira.arm.com/browse/PELEDGE19-1386?filter=-1
https://jira.arm.com/browse/PELEDGE19-1394?filter=-1
https://jira.arm.com/browse/PELEDGE19-1375?filter=-1

Waiting for SQA team to verify the bug fixes.
DO NOT MERGE

@mray190 Do you think this is because of my changes?
18 passing (6m)
1 failing

Maestro API
DHCP
should retrieve the active networking maestro config:
Uncaught SyntaxError: Unexpected token c in JSON at position 0
at JSON.parse ()
at Context. (test.js:344:42)
at Object.shell.exec.bind.ctx (commands.js:76:22)
at /home/micray01/jenkins/workspace/maestro/tests/node_modules/shelljs/src/exec.js:127:9
at ChildProcess.exithandler (child_process.js:301:5)
at maybeClose (internal/child_process.js:970:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:259:5)

rebuild

@psppalash I am rebuilding right now to check if it fails twice.
Our CI has been stable for about 2 weeks now. So the likelihood that it caught an actual bug is pretty high.
Additionally, looking through your code, the network manager is touched. The feature test that failed was related to the network manager. It it fails again, the code that is probably causing the failure is located within the network manager

Thanks @mray190 . Looks like it failed again. I will have a look and see what could be going wrong.

To replicate the failure, run this command (while maestro is running):
sudo curl -XGET --unix-socket /tmp/maestroapi.sock http:/net/interfaces

To replicate the failure, run this command (while maestro is running):
sudo curl -XGET --unix-socket /tmp/maestroapi.sock http:/net/interfaces

@mray190 I could not replicate the failure using the above mentioned command.
Additionally, I tried the same command with master branch and my branch, I get the same output (that is the same json object).

Rebased on dev and merged within PR #81


yarn test hangs indefinitely

Is this a bug report?
Yes

Can you also reproduce the problem with npm 4.x?

Yes
Which terms did you search for in User Guide?

Testing, test, jest
Environment

node -v: 8.5.0 (but also test on 7.5.0 and 6.5.0)
npm -v: Now 4.6.1
yarn --version (if you use Yarn): 1.0.2
npm ls react-scripts (if you haven’t ejected): 1.0.13

Then, specify:

Operating system: macOS Sierra

Steps to Reproduce

(Write your steps here:)

Create new react app
npm run test or yarn test
it hangs indefinitely:

Expected Behavior

Show that my tests pass.
Actual Behavior

It hangs.
I actually have the same if I just follow this guide for setting up jest... I don't understand, I don't get any feedback from jest what goes wrong.
https://facebook.github.io/jest/docs/en/getting-started.html

yarn list jest gives<EMAIL_ADDRESS>

I think this is an issue in your environment and not related to create-react-app. There is a similar issue has been reported in watchman repo which used inside jest. So this answer might help you.

Thanks, brew upgrade watchman fixed this for me

For others struggling with this: brew reinstall watchman fixed it for me


Problems with ulp() method for exact numbers

For exact numbers the ulp() method returns 0. This is a problem in combination with the new calculus field interface in the hipparchus library.
@mtommila  can you please comment this issue:

https://github.com/Hipparchus-Math/hipparchus/issues/139

What would you expect that ulp() returns for exact numbers such as integers or rational numbers?

@mtommila thank you for your answer in:

https://github.com/Hipparchus-Math/hipparchus/issues/139


guestFullName exceeds 128 characters causing vCenter Server disconnects in Cloud Director

Description
We observed that after upgrading a node to flatcar 3850.1.0 we're hitting this issue. The value that vmware-tools is pulling somehow from the node is like this:
Linux 6.6.16-flatcar Flatcar Container Linux by Kinvolk 3850.1.0 (Oklo) Flatcar Container Linux by Kinvolk 3850.1.0 2024-02-12-1854
which exceeds 128 characters. Previous releases did not include the date stamp at the end.
I understand this is not so much an issue of Flatcar but lies with VMware, however it might affect other Flatcar users.

Hi, is this something that can be addressed/fixed to the old behaviour before the next release? At this point I'm not sure where this value is pulled from but this has recently changed in the flatcar code I suspect.

There was no change in Flatcar to explain it, so we don't know what to do about it. The best guess is that an update to open-vm-tools changed how this field is synthesized.

flatcar version
open-vm-tools version

3815
12.3.5

3760
12.3.0

3602
12.2.0

3510
12.1.5

Which version worked?


Power Requirement for Entering/Exiting

Not sure whether i want this yet or not.

Power requirement is not needed. I think it would get annoying trying to get into the machines while setting them up.

I will probably use another block to power it, similiar to the QED.

 Can you power it from the inside? Another block to place next to each machine? Rable Rable Rable Just kidding.

Just some thoughts on this topic;

enter/exit should not need energy when using PSD
costs to transfer
costs for options & upgrades

enter/exit without PSD
light levels
mob spawns
individual biomes
chunk loading
quantum entanglement without needing nether star
spawn protection

config options for it all

@pip69 i agree with all of this.
additionally:

needs a way so CMs can not get powered from the inside, which means custom power system, probably qed like
creative upgrades need to exist as well, mostly for modpack makers

Technically the PSD is what should use power if any. Not the CM. As i understand the CM is just a open spaced block that you shrink yourself and items into.

This is implemented using Miniaturization Fluid.


Upgrading packages tag for alpha packages

/cherrypick release-0.11
Updating Alpha patch 0.5 for packages for testing

/cherrypick release-0.11

/lgtm

/lgtm

/approve


Optimize notifier to send emails in parallel

Currently, the notifier sends emails sequentially. There is a lot of wasted time in the function waiting for network (probably 99%!). This increases the cost of the function and won't scale at all if we have thousands of subscribers as it will be very expensive and may go beyond the max allowed timeout (if any).
We should send the emails asynchronously. The caveat here is that we are still bound by the maximum sending rate from SES (currently 14 requests per second), so we can only optimize the speed up to a certain limit.
It would be nice if the function would read the sending rate using SES API in the beginning then control the number of threads/coroutines making sure it is not sending too fast.

The current limit of 14 sends per second and the sequential speed makes this worthless to do. We can reopen later if we have thousands of subscribers and a faster rate.


Refactor and implementation of the camera API 1, it fixes #8736

As detailed in #8736, the legacy devices should work with the Camera API 1, the detector demo would need even more refactor in order to work

Can one of the admins verify this patch?

I signed it!

For the CLA issue, @BrianOn99 are you okay with your commit being included in this PR?
@osdamv could you resolve the conflict? Thanks!

Sure.

I think my PR could be closed as @osdamv 's approach looks better (less code duplication).  Thanks for the improvement!

Confirmed to be working except the detector demo.  However the debugging info is not visible in the classify demo.  Or is it removed from the master branch recently?

@yifeif I just fixed the conflicts

Thanks @osdamv and @BrianOn99.
@andrewharp could you take a look? Thanks!

Jenkins, test this please.

Jenkins, test this please.

@osdamv to be clear, this is ready to be reviewed?

Yeah, I hope there is no more sanity issues

Hi, I was too busy the last to weeks(I was studying for a Facebook interview!!) in order to make the requested changes. Hopefully this commit pass the review :).

Hope it went well! Looking forward to the update.
On Jul 14, 2017 12:03 PM, "osdamv"<EMAIL_ADDRESS>wrote:
Hi, I was too busy the last to weeks(I was studying for a Facebook
interview!!) in order to make the requested changes. Hopefully this commit
pass the review :).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/pull/10771#issuecomment-315441091,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AT_SbRofqHlznMLzZL5Y5PRxO2G-uCqhks5sN7tygaJpZM4N8vJo
.

@tensorflow-jenkins Test this, please.

Jenkins, test this please

@osdamv Thank you for the contribution!

@andrewharp  Your welcome!! Any thing else I can do please let me know


Run coverageReport failed when not set managedDevices

On release 1.7.0, following check will cause test failed when not set testOptions.managedDevices in project's build.gradle. allDevices*AndroidTest and connected*AndroidTest will not be generated when not set this option.
RootCoveragePlugin.kt
} else {
    // If this plugin should not run instrumented tests on it's own, at least make sure it runs after those tasks (if they are
    // selected to run as well).
    mustRunAfter("$path:allDevices${name}AndroidTest")
    mustRunAfter("$path:connected${name}AndroidTest")
}

Maybe we should remove this check or do this check when related tasks exist?

Can you be a bit more specific in the error description?
What exactly is going wrong, do you have an exception, stack trace? Missing coverage?
Please share your configuration and how your are attempting to run tests and collect coverage.

I will get following error message when run module:coverageReport :
Could not determine the dependencies of task ':module:coverageReport'.
> Task with path ':module:allDevicesDebugAndroidTest' not found in project ':module'.

allDevicesDebugAndroidTest will be available when I set following setting in module's build.gradle
android {
    ...
    testOptions {
        managedDevices {
            devices {
                pixel2api30(com.android.build.api.dsl.ManagedVirtualDevice) {
                    device = "Pixel 2"
                }
            }
        }
    }
}

When I fork plugin and remove mustRunAfter check, it works normally.
Here the setting in my root build.gradle:
rootCoverage {
    // Overrides the default build variant for specific modules.
    buildVariantOverrides ":module" : "debug"

    // Since 1.4: Sets jacoco.includeNoLocationClasses, so you don't have to. Helpful when using Robolectric
    // which usually requires this attribute to be true
    includeNoLocationClasses true

    executeAndroidTests false
}

Turns out that the "$path:allDevices${name}AndroidTest" task only exists if a Gradle Managed Device has been configured.
So to fix this I should check for the existence of this task in the graph before telling the coverage task to always run after that task (task order is important for things such as code coverage, you cannot calculate coverage before tests have executed).
Just removing the mustRunAfter statements is thus dangerous as it can cause coverage to go missing if the tasks are not ordered correctly, hence that is not a solution.
TLDR: Working on it.

Thank you for promptly fixing this issue. :)

A new 1.8.0-SNAPSHOT build is available where this is fixed (also fixed on release 1.7 with hotfix 1.7.1)


Move form config into a package

Addresses issue onaio/reveal-frontend#900
performs the following tasks:

Upload config form
Edit config form
Download uploaded config forms
Publish manifest files

Screenshots here

@ciremusyoka can we take care of the 2.1% drop in coverage?

@ciremusyoka can we take care of the 2.1% drop in coverage?

Still trying to cover the tiny details remaining. It's somehow hard to get 100% for all the files


sct_download_data safety checks

Some cleanups I found during #2668, but pulled out separately.
This depends on #2700.

some of the changes seem out of scope (e.g. moco)-- is that on purpose?

I've rebased onto #2700 instead of leaving this towering on my currently open stack of PRs (#2642, #2666 , #2667 , #2668). It's good to go now and can be merged before them.


Show curl command to send a notification in the push-simple recipe

I received the following when attempting to curl:
https://gist.github.com/darkwing/3aaa444b4015cc534061
Does that relate to the following which is seen when starting the server: "If you want Chrome to work, you need to set the GCM_API_KEY environment variable to your GCM API key." ?

Yes, it only works with services that implement the Web Push standard (GCM doesn't), I've mentioned it in the documentation.

R+


Don't recheck files for 'build' if they have already passed 'check'

It would be really great to have a simmilar behavior to how cargo build works:
If cargo check has passed and no files have been changed since then — don't recheck them and compile directly.
I'm not sure if it's possible at all and at what cost it would be, since checking code is probably an intermidiate action. Also, cargo-check is an external subcommand.
But what brought this to my mind: if it was possible, it could really speed up compilation times when working in IDEs, since cargo check is run very often to lint files. And after a satisfying check to have an ability to build project quick would be really great.

:+1:

:+1:
Are there plans for cargo check to be built into cargo?
I'm using cargo check in combination with cargo watch: https://github.com/passcod/cargo-watch
which is useful when I'm subconsciously saving rust files, and then do a compilation step (i.e. cargo build) when output of cargo check looks fine.

+1

If cargo check has passed and no files have been changed since then — don't recheck them and compile directly.

Unfortunately, type checking (the slowest checking pass in most cases AFAIK) produces information needed by later passes in the compiler (mainly, translation).
Sounds like what you want is incremental compilation, which is currently being worked on. See rust-lang/rfcs#1298.


incorrect wording of "Parallel Jobs" setting

Brief Issue Summary
In the setting of Parallel Jobs, it says:

Cmake: Parallel Jobs
The number of parallel build jobs. Use zero to automatically detect the number of CPUs. Setting this to 1 will disable build parallelism.

When I test in Windows 11/ msbuild (vs2022 is also installed),

When I set the value to 0, the cmake cmd is:

 ...\bin\cmake.EXE --build d:/github/asdf_Test/asdf/build --config Debug --target ALL_BUILD -j 18 --

it seems to be correct but due to a cmake msbuild issue (https://discourse.cmake.org/t/parallel-does-not-really-enable-parallel-compiles-with-msbuild/964), the "-j 18" does not work with msbuild.

When I set the value to 1, the cmake cmd is: (without -j 18)

 ...\bin\cmake.EXE --build d:/github/asdf_Test/asdf/build --config Debug --target ALL_BUILD --

On Win11 and msbuild, this cmd actually works and msbuild build the project in parallel!
Summary of the wording of the setting:

"Use zero to automatically detect the number of CPUs"

is correct although cmake can't build in parallel (it's another issue);

"Setting this to 1 will disable build parallelism."

may not be correct. Even from literal meaning, setting value of "1" (Value of True to c++ programmers) will disable the setting of "Parallel Jobs"? Very confusing and not the truth on win11/msbuild.
CMake Tools Diagnostics
No response
Debug Log
No response
Additional Information
related but not same issue: https://github.com/microsoft/vscode-cmake-tools/issues/1958

Thanks for the feedback. Do you think this wording is accurate? We'll make the change if everything looks good.

The number of parallel build jobs. Use zero to automatically detect the number of CPUs. Setting this to 1 will omit the parallelism flag (-j) from the underlying build command, which has a generator-dependent effect on build parallelism.

OK to me.


refactor: remove js_image_layer bazel5 legacy symlink detection

Type of change

Refactor (a code change that neither fixes a bug or adds a new feature)

Test plan

Covered by existing test cases

you need to update rule impl as well

Good point, thanks! (and updated...)


libglog_la-utilities Error

src/utilities.cc:268:29: error: 'GetCurrentThreadId' was not declared in this scope
return GetCurrentThreadId();
^
src/utilities.cc:273:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
Makefile:1191: recipe for target 'src/libglog_la-utilities.lo' failed
make: *** [src/libglog_la-utilities.lo] Error 1
I am installing glog on cygwin configuration. Not sure what went wrong.
Thanks,

utilities.cc:267 checks for OS_CYGWIN being defined. If so, it attempts to call GetCurrentThreadId() which is not found.
Similarly, googletest.h:524 and :557 performs the same test.
All three tests are unnecessary on cygwin, I believe, and commenting them allows building.

it would be nice to patch this so it compiles out of the box
Index: src/utilities.cc
===================================================================
--- src/utilities.cc    (revision 143)
+++ src/utilities.cc    (working copy)
@@ -264,7 +264,7 @@
   // If gettid() could not be used, we use one of the following.
 #if defined OS_LINUX
   return getpid();  // Linux:  getpid returns thread ID when gettid is absent
-#elif defined OS_WINDOWS || defined OS_CYGWIN
+#elif defined OS_WINDOWS && !defined OS_CYGWIN
   return GetCurrentThreadId();
 #else
   // If none of the techniques above worked, we use pthread_self().

but that doesn't cover install and the tests...

That leaves a number of compile errors to fix.

Please test a97d6b0e1ce34e4e1956c63de8ddd325ff164512 and report back if there are problems.


[Feature Request]Fake-SRT Protocol

Fake-SRT Protocol Or SRT,SRT is better than quic when high packet loss network

I need this too


Animate Add Button

On clicking the Add Todo Button. Please make it animate slowly rather than the fast transition seen.

Okay boss


Fixed the issue of skip-to-content button overlapping the header links

Fixes #879
Changes:
The skip-to-main-content button was initially present at the top left corner of the page, and hence it overlapped the header links. I have changed the 'top' property for the button and pushed it downwards, and now the links are easily accessible.
Screenshots of the change:

Thanks!

@limzykenneth  Should I add my name to all-contributors doc?

Just added.


Sort Key for GSI out of sync with Cloudformation Template

Before opening, please confirm:

[X] I have searched for duplicate or closed issues and discussions.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

JavaScript Framework
React
Amplify APIs
GraphQL API
Amplify Version
v5
Amplify Categories
No response
Backend
Amplify CLI
Environment information

# Put output below this line
  System:
    OS: macOS 13.2.1
    CPU: (8) arm64 Apple M1
    Memory: 56.33 MB / 8.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 20.7.0 - ~/.nvm/versions/node/v20.7.0/bin/node
    npm: 10.1.0 - ~/.nvm/versions/node/v20.7.0/bin/npm
  Browsers:
    Chrome: 126.0.6478.127
    Safari: 16.3
  npmPackages:
    @aws-amplify/core: ^5.8.2 => 5.8.12
    @aws-amplify/core/internals/aws-client-utils:  undefined ()
    @aws-amplify/core/internals/aws-client-utils/composers:  undefined ()
    @aws-amplify/core/internals/aws-clients/pinpoint:  undefined ()
    @aws-amplify/ui-react: ^5.1.1 => 5.3.3
    @aws-amplify/ui-react-internal:  undefined ()
    @aws-amplify/ui-react-storage: ^2.1.4 => 2.3.3
    @aws-sdk/client-cognito-identity-provider: ^3.515.0 => 3.569.0
    @aws-sdk/client-ses: ^3.515.0 => 3.569.0
    @aws-sdk/lib-dynamodb: ^3.515.0 => 3.569.0
    @aws-sdk/util-utf8-browser: ^3.259.0 => 3.259.0 (3.6.1, 3.186.0)
    @babel/cli: ^7.22.10 => 7.24.5
    @babel/core: ^7.22.10 => 7.24.5
    @babel/plugin-proposal-private-property-in-object: ^7.21.11 => 7.21.11 (7.21.0-placeholder-for-preset-env.2)
    @babel/preset-env: ^7.22.10 => 7.24.5
    @babel/preset-typescript: ^7.24.1 => 7.24.1
    @cyntler/react-doc-viewer: ^1.14.0 => 1.14.1
    @cypress/angular:  0.0.0-development
    @cypress/mount-utils:  0.0.0-development
    @cypress/react:  0.0.0-development
    @cypress/react18:  0.0.0-development
    @cypress/svelte:  0.0.0-development
    @cypress/vue:  0.0.0-development
    @cypress/vue2:  0.0.0-development
    @emotion/react: ^11.10.6 => 11.11.4
    @emotion/styled: ^11.10.6 => 11.11.5
    @mui/lab: ^5.0.0-alpha.124 => 5.0.0-alpha.170
    @mui/material: ^5.11.15 => 5.15.16
    @newrelic/browser-agent: ^1.260.0 => 1.260.0
    @testing-library/jest-dom: ^5.16.5 => 5.17.0
    @testing-library/react: ^13.4.0 => 13.4.0
    @testing-library/user-event: ^13.5.0 => 13.5.0
    @types/jest: ^27.5.2 => 27.5.2
    @types/node: ^17.0.45 => 17.0.45 (18.19.32)
    @types/react: ^18.2.46 => 18.3.1
    @types/react-dom: ^18.2.18 => 18.3.0
    @types/react-router-dom: ^5.3.3 => 5.3.3
    amazon-quicksight-embedding-sdk: ^2.6.0 => 2.7.0
    aws-amplify: ^5.3.12 => 5.3.18
    aws-sdk: ^2.1473.0 => 2.1615.0
    aws-sdk-client-mock: ^3.0.1 => 3.1.0
    axios: ^1.6.7 => 1.6.8
    buffer: ^6.0.3 => 6.0.3 (4.9.2, 5.7.1)
    chart.js: ^4.4.3 => 4.4.3
    chart.js-auto:  undefined ()
    chart.js-helpers:  undefined ()
    chartjs-plugin-datalabels: ^2.2.0 => 2.2.0
    cypress: ^13.6.0 => 13.8.1
    eslint-plugin-cypress: ^3.3.0 => 3.3.0
    graphql: ^16.8.1 => 16.8.1 (15.8.0)
    html2canvas: ^1.4.1 => 1.4.1
    idb: ^8.0.0 => 8.0.0 (5.0.6, 7.1.1)
    jest: ^29.0.0 => 29.7.0 (27.5.1)
    jspdf: ^2.5.1 => 2.5.1
    jszip: ^3.10.1 => 3.10.1
    mammoth: ^1.6.0 => 1.7.2
    path-browserify: ^1.0.1 => 1.0.1
    prettier: ^3.2.5 => 3.2.5
    process: ^0.11.10 => 0.11.10
    qrcode.react: ^3.1.0 => 3.1.0
    react: ^18.2.0 => 18.3.1 (18.2.0)
    react-app-rewired: ^2.2.1 => 2.2.1
    react-beautiful-dnd: ^13.1.1 => 13.1.1
    react-chartjs-2: ^5.2.0 => 5.2.0
    react-csv: ^2.2.2 => 2.2.2
    react-dom: ^18.2.0 => 18.3.1
    react-router-dom: ^6.24.0 => 6.24.0
    react-scripts: ^5.0.1 => 5.0.1
    react-select: ^5.8.0 => 5.8.0
    react-signature-canvas: ^1.0.6 => 1.0.6
    sass: ^1.71.1 => 1.77.0
    source-map-loader: ^4.0.1 => 4.0.2 (3.0.2)
    swr: ^2.0.4 => 2.2.5
    ts-jest: ^29.1.1 => 29.1.2
    ts-loader: ^9.5.1 => 9.5.1
    tsconfig-paths-webpack-plugin: ^4.1.0 => 4.1.0
    typescript: ^4.9.5 => 4.9.5
    web-vitals: ^2.1.4 => 2.1.4 (3.5.2)
    workbox-background-sync: ^6.6.0 => 6.6.0 (6.6.1)
    workbox-broadcast-update: ^6.6.0 => 6.6.0
    workbox-cacheable-response: ^6.6.0 => 6.6.0
    workbox-core: ^6.6.0 => 6.6.0 (6.6.1)
    workbox-expiration: ^6.6.0 => 6.6.0
    workbox-google-analytics: ^6.6.1 => 6.6.1 (6.6.0)
    workbox-navigation-preload: ^6.6.0 => 6.6.0
    workbox-precaching: ^6.6.0 => 6.6.0
    workbox-range-requests: ^6.6.0 => 6.6.0
    workbox-routing: ^6.6.0 => 6.6.0 (6.6.1)
    workbox-strategies: ^6.6.0 => 6.6.0 (6.6.1)
    workbox-streams: ^6.6.0 => 6.6.0
    xlsx: ^0.18.5 => 0.18.5
  npmGlobalPackages:
    @aws-amplify/cli: 12.11.1
    @newrelic/publish-sourcemap: 5.1.0
    aws-cdk: 2.127.0
    corepack: 0.19.0
    newrelic: 11.19.0
    npm: 10.1.0
    serve: 14.2.3
    snyk: 1.1241.0
    typescript: 5.2.2

Describe the bug
A schema.graphql change was made where the sortKeyFields of two @indexs were updated:
Before:
type ValidSupplierFormTypes @model {
    ...
    formTypeId: ID! @index(name: "byFormType", sortKeyFields: ["supplierId"])
}

type ValidSupplierTypes @model {
    ...
    supplierTypeId: ID! @index(name: "bySupplierType", sortKeyFields: ["supplierId"])
}

After:
type ValidSupplierFormTypes @model {
    ...
    formTypeId: ID! @index(name: "byFormType", sortKeyFields: ["supplierSiteId"])
}

type ValidSupplierTypes @model {
    ...
    supplierTypeId: ID! @index(name: "bySupplierType", sortKeyFields: ["supplierSiteId"])
}

I understand that this is not best practice, as an index with a new name should be created to support the new sort key field. However, during deployment, it appears that the underlying GSIs for the DynamoDB tables were updated to have the new sort key field. The update to the nested api stack failed, presumably because the app sync resolvers did not like the change. However, upon rollback the updated indices were NOT successfully updated, and the respective CloudFormation templates still have the supplierSiteId as the range key.
If I do an amplify pull on the environment, the schema contains the original @index configurations.
I attempted to resolve this manually by deleting the indices and creating them with the old sort key fields. However, all that did was create drift in the CloudFormation stack.
I need a mechanism synchronize what exists in the cloudformation template with what Amplify has stored for these two indices.
Expected behavior
I would expect initial push to fail as Amplify should not support only changing the sortKeyFields on indices.
Reproduction steps

Add a @model to the schema.graphql file with an index with a sortKeyField
Push the changes
Update the sortKeyField to a new field
Push again (should fail due to AppSync resolver updates failing)
Observe DynamoDB table with updated indices but Amplify environment still stating old index configurations

Code Snippet
// Put your code below this line.

Log output

// Put your logs below this line

aws-exports.js
No response
Manual configuration
No response
Additional configuration
No response
Mobile Device
No response
Mobile Operating System
No response
Mobile Browser
No response
Mobile Browser Version
No response
Additional information and screenshots
No response

Hi @matt-at-allera,
Can you confirm you're using version 12.11.1 of the Amplify CLI you're using? (i.e., What is the output of amplify version?)

I would expect initial push to fail as Amplify should not support only changing the sortKeyFields on indices.

Amplify does support updates to GSIs: if a GSI has changed, the deployment deletes the index and recreates it. In addition, customers can batch more than one GSI update in a single schema push. That said, you're right that our recommendation for large schemas, or for tables with significant amounts of data, is to do it incrementally by deleting the index, pushing, then re-adding a new index with the updated sort key fields. The reason for this is that the time required to perform multiple GSI updates can exceed the Amplify CLI timeout or the expiration of the local credentials. In that case, we recommend doing an amplify push --iterative-rollback to roll back to the last known good state.
In a test I ran locally with a small schema and very short-lived credentials:

I initiated the amplify push to update the GSI
The push timed out
The DDB table showed to have deleted the GSI
There was no stack drift
Amplify status still showed an update operation for the API
I was then able to perform an amplify push --iterative-rollback to restore the previous GSI

Based on your report...

I attempted to resolve this manually by deleting the indices and creating them with the old sort key fields. However, all that did was create drift in the CloudFormation stack.

...it sounds like an iterative rollback isn't an option?
I'm curious to know what CloudFormation actually thinks about the state of the current resources. Can you provide the results of a stack drift detection on the model stack that actually owns the DynamoDB table and GSI? To find that:

Go to CloudFormation
Find the root Amplify stack, which should have a description like "Root Stack for AWS Amplify CLI"
In the Resources tab of the Root Stack, click the Physical ID link for the API stack. It will have a Type of AWS::CloudFormation::Stack, and a Logical ID that begins with api
In the Resources tab of the API Stack, click the Physical ID link for the ValidSupplierFormTypes nested stack. It will have a Type of AWS::CloudFormation::Stack, and a Logical ID of ValidSupplierFormTypes
In the ValidSupplierFormTypes nested stack, click Stack actions then Detect drift
In the ValidSupplierFormTypes nested stack, click Stack actions then View drift results. Refresh until the page shows results for the table (that is, the resource with the Type of AWS::DynamoDB::Table)

Hi @palpatim thanks for the response.
Yes, I am running 12.11.1:
$ amplify version
12.11.1

...it sounds like an iterative rollback isn't an option?

I've tried the iterative rollback, and it fails with the same error noted in my support ticket:

Resource handler returned message: "Cannot update GSI's properties other than Provisioned Throughput and Contributor Insights Specification. You can create a new GSI with a different name."

I have performed the drift detection several times. It currently states that there is no drift for either table which is what led me to the assumption that Amplify is de-synced from the CloudFormation template. Results are attached. It had said there was drift when I manually reverted the table indices back to the last successful Amplify push (supplierId as sort key instead of supplierSiteId).

Should we commence with communicating here and not in the AWS support ticket?

Thank you for sharing the drift detection results. Also, I apologize for the forked communication -- I default to GitHub but am happy to communicate either here or via the support ticket! I'll post some questions here and duplicate them in the ticket, so please feel free to respond in whichever channel you prefer.
Since I haven't been able to reproduce this locally, I want to summarize the current state:

DynamoDB - NEW index names (as reported by inspecting the table in the console)
CloudFormation - NEW index names (as evidenced by CloudFormation showing no stack drift on the DDB tables)
Amplify Local project - OLD index names (as reported in backend/api/.../schema.graphql)

I'm assuming amplify pull doesn't complain about overwriting any local changes, which implies that your local workspace is in sync with the deployment state. To verify this, can you report what amplify pull ; amplify status shows? Assuming amplify status shows no changes, that means Amplify state is internally consistent.
Next step would be to do as you mentioned above: make Amplify reflect the current state of CloudFormation. We'll do that by editing the deployment state of the S3 bucket, which is a bit tedious, but relatively straightforward to do. I'll prepare some instructions for making those edits.

@palpatim of course and no worries, I'll keep responding here.

Since I haven't been able to reproduce this locally, I want to summarize the current state:
DynamoDB - NEW index names (as reported by inspecting the table in the console)
CloudFormation - NEW index names (as evidenced by CloudFormation showing no stack drift on the DDB tables)
Amplify Local project - OLD index names (as reported in backend/api/.../schema.graphql)

Your summary of the current state appears to be correct. I did not take perfect notes as to what caused us to get into this state, unfortunately. Knock on wood it doesn't happen again, but if it does, I'll be more methodical in tracking the steps that resulted in this de-synced state.

I'm assuming amplify pull doesn't complain about overwriting any local changes, which implies that your local workspace is in sync with the deployment state. To verify this, can you report what amplify pull ; amplify status shows? Assuming amplify status shows no changes, that means Amplify state is internally consistent.

That's correct. amplify pull; amplify status reports No Change for each category & resource.

Next step would be to do as you mentioned above: make Amplify reflect the current state of CloudFormation. We'll do that by editing the deployment state of the S3 bucket, which is a bit tedious, but relatively straightforward to do. I'll prepare some instructions for making those edits.

Perfect, I am unfamiliar with that process but had conjectured that would be necessary for resolution. I'll await your instructions!

@palpatim if you could send those instructions today, if possible, that would be very much appreciated. We've been blocked on making production pushes for 3 weeks now, and the pressure is mounting. I'm sure you understand the situation we're in. Having this resolved over the weekend is our priority.
Please let me know if there is anything I can do to speed this up or provide additional, necessary information

@matt-at-allera
Sorry for the delay on this -- I am putting together instructions by using a local environment that attempts to recreate your starting conditions (DDB & CFN reflecting the new index name; Amplify state reflecting the old index name), but I'm finding that as long as I've created the index names properly in DDB/CFN, then I am able to update the name in my Amplify schema and let amplify push do the work.
The error message, Cannot update GSI's properties other than Provisioned Throughput and Contributor Insights Specification. You can create a new GSI with a different name. indicates that there are other GSI attributes being updated --that is, the proposed change from Amplify does not match the current state in DDB.
Let's try comparing the CFN and Amplify stack definitions to see where the discrepancy is:

Go to CloudFormation
Find the root Amplify stack, which should have a description like "Root Stack for AWS Amplify CLI"
In the Resources tab of the Root Stack, click the Physical ID link for the API stack. It will have a Type of AWS::CloudFormation::Stack, and a Logical ID that begins with api
In the Resources tab of the API Stack, click the Physical ID link for the ValidSupplierFormTypes nested stack. It will have a Type of AWS::CloudFormation::Stack, and a Logical ID of ValidSupplierFormTypes
In the ValidSupplierFormTypes nested stack, click Template then Copy
Paste the template JSON into a file, let's call it ValidSupplierFormTypes-cfn.json

Next, let's get Amplify's view of the stack:

In your local workspace, find the file amplify/backend/api/<api name>/build/stacks/ValidSupplierFormTypes.json

What I'm expecting to find is only differences related to the GSI's sortKeyField:

The Resources.ValidSupplierFormTypesTable.Properties.AttributeDefinitions array should have only attributes that are part of the model's key schema or GSIs. Both the CFN and Amplify templates should show these fields, although the order may be different:

id
supplierId
formTypeId
supplierSiteId
tenant
(Explanation: the fields listed above are present in keys and GSIs in both versions of the table, so we'd expect to see them called out in the AttributeDefinitions)

The Resources.ValidSupplierFormTypesTable.GlobalSecondaryIndexes array should show only a difference in the byFormType GSI:

The CFN version's KeySchema array should have a HASH key of formTypeId, and a RANGE key of supplierSiteId
The Amplify version's KeySchema array should have a HASH key of formTypeId, and a RANGE key of supplierId

My speculation is that there are other differences in either the AttributeDefinitions or GlobalSecondaryIndexes that are conflicting.
Once we narrow down the difference in the ValidSupplierFormTypes table, we'll do the same for ValidSupplierTypes

@palpatim
Thanks for responding and understanding the urgency. This approach makes sense to me.
ValidSupplierFormTypes.json
Amplify's view of the stack is on the left, and the actual CFN template is on the right:

This could be the main issue - that current Amplify environment does not even have an understanding of what supplierSiteId is.

As expected, the bySupplierSite index is missing from the Amplify side as well as the RANGE key being supplierId.

Let's do the same for ValidSupplierTypes.json:

The results appear to match what we see for the other table.

Does this mean the best path forward is to:

amplify pull the environment to be in sync with Amplify's state.
Add only the supplierSiteId as a field to both the ValidSupplierFormTypes and ValidSupplierTypes model.
amplify push the change
observe added supplierSiteId field
observe removed bySupplierSite index and RANGE key of byFormType / bySupplierType switched from supplierSiteId -> supplierId in both DDB and CFN
push again with latest changes in master Git branch ?

Let me know if you would take a different approach.

Sorry, it appears the version of the schema uploaded to the support ticket is different from the one you're working from--the schema version I am working from doesn't even have a formTypeId field on the ValidSupplierTypes model. Apologies for the oversight. :(
In any case, the bottom line is: We need to make your local schema.graphql look like the CloudFormation template before we do an amplify push. That ensures that CloudFormation won't try to apply any index changes during the push, even though Amplify will detect a change and attempt to do an incremental GSI update for the changes it detects.
The steps I propose:

amplify pull the environment to be in sync with Amplify's state.
In the ValidSupplierFormTypes model:
a. Add the supplierSiteId as an indexed field, referencing the previously-existing formTypeId in the sortKeyField.
b. Add supplierTypeId to the sortKeyFields of the byFormType index
c. The relevant fields of ValidSupplierFormTypes should look like:supplierSiteId: String @index(name: "bySupplierSite", sortKeyFields: ["formTypeId"])
formTypeId: String @index(name: "byFormType", sortKeyFields: ["supplierSiteId"])

In the ValidSupplierTypes model:
a. Add the supplierSiteId as an indexed field, referencing the previously-existing supplierTypeId in the sortKeyField.
b. Add supplierSiteId to the sortKeyFields of the bySupplierType index
c. The relevant fields of ValidSupplierFormTypes should look like:supplierSiteId: String @index(name: "bySupplierSite", sortKeyFields: ["supplierTypeId"])
supplierTypeId: String @index(name: "bySupplierType", sortKeyFields: ["supplierSiteId"])

At this point, the locally generated CFN template should be the same as the template downloaded from CFN itself. amplify push the local changes. Amplify will create an iterative GSI deployment to add the "new" indexes, but those will not actually result in a changeset in CFN.

After the push succeeds, you should be in sync, and can make changes to indexes. Given the initial problems, I'd recommend making changes incrementally, with a push in between each one.

Additionally, I am still not convinced that the error message Cannot update GSI's properties other than Provisioned Throughput and Contributor Insights Specification. You can create a new GSI with a different name. is occurring due to a property other than the RANGE key switching. Unless I am missing something, that configuration change seems like the likely culprit.

Based on the fact that my schema version is not the same as yours, I agree with this assessment -- it's likely the range key changes that are causing the issue.

I should have noted above -- you can verify the CFN template that Amplify generates before the push by issuing amplify api gql-compile. That command runs the transformers locally, which regenerates files in the build folder. That means you can issue the command and then compare amplify/backend/api/<api name>/build/stacks/ValidSupplierFormTypes.json and amplify/backend/api/<api name>/build/stacks/ValidSupplierTypes.json to the appropriate CFN templates and ensure no diffs before pushing.

@palpatim
I've attempted the proposed solution and am encountering a strange behavior that makes me think we may need to modify something in the s3 deployment bucket?
Upon running the amplify api gql-compile the configuration of ValidSupplierTypes.json appears to match that of the deployed CFN template. However, during the CFN update / UPDATE_ROLLBACK_IN_PROGRESS state, I noticed that the template shown in the CFN console had the index configured as:
{
            "IndexName": "bySupplierType",
            "KeySchema": [
              {
                "AttributeName": "supplierTypeId",
                "KeyType": "HASH"
              },
              {
                "AttributeName": "supplierId",
                "KeyType": "RANGE"
              }
            ],
            "Projection": {
              "ProjectionType": "ALL"
            },
            "ProvisionedThroughput": {
              "Fn::If": [
                "ShouldUsePayPerRequestBilling",
                {
                  "Ref": "AWS::NoValue"
                },
                {
                  "ReadCapacityUnits": {
                    "Ref": "DynamoDBModelTableReadIOPS"
                  },
                  "WriteCapacityUnits": {
                    "Ref": "DynamoDBModelTableWriteIOPS"
                  }
                }
              ]
            }
          },

Notice the RANGE key is supplierId, even though the schema and the built file have it listed as supplierSiteId. These pushes are failing with that same Cannot update GSI's properties ....
Any idea why the deployment isn't using the updated configuration?

Okay I was able to get an amplify push to go through. After updating the schema.graphql to reflect the actual DDB/CFN state, I ended up having to copy ValidSupplierTypes.json and ValidSupplierFormTypes.json from the local build directory  into the #current-cloud-build.zip file in the S3 Deployment Bucket. Once that step was complete, I ran amplify pull, updated the schema.graphql file once more, and performed a final amplify push --force.
In a nutshell, this enabled the state of Amplify to "sync" up with the state of CFN. The question remains as to what caused this de-sync, but at least I know how this process can be solved in the future.
Leaving this ticket open to perform further investigation and to make sure I can make the necessary forward-progress updates.

The rest of the updates to the application succeeded. I've read up that sometimes making schema changes during a local amplify push can cause the #current-cloud-backend in S3 to desync from the local cli. However, it's strange to me that the remote versions of Amplify and CFN/DDB could be out of sync from each other. @palpatim I don't have concrete reproduction steps on this, but I am wondering, from your experience, if you have any clue how that could've happened?

@matt-at-allera I'm glad you were able to complete the updates.
Unfortunately we've not been able to identify repro steps for this either. We have seen intermittent reports of this happening, but have been unable to repro using the affected schemas and various methods to interrupt the deployment (e.g., severing network connections, using expired credentials). In the cases where we do encounter a deployment error, an amplify push --iterative-rollback was enough to bring local and cloud deployment states back into sync.
I haven't tried doing a schema modification alongside a push, but in theory it might cause backend->#current-cloud-backend drift. But that shouldn't cause #current-cloud-backend to get out of sync with CFN. That said, Amplify Gen 1 deployment state is distributed amongst two sources of truth: local and cloud, and a race condition or other non/semi-deterministic bug could be accounting for this. But unfortunately without a reliable repro, we aren't able to make meaningful progress on a root cause analysis.

@palpatim thanks for the help on this one. I'm going to go ahead and close out the issue.

This just happened to me.
I had a failed push where I had added 3 indexs to a table and some other changes that errored out due to a lambda not haveing a needed security group value in the team provider.
Amplify was unable to roll back those changes, but amplify pull returned the schema in the old state without the new index
Looking in Cloudformation it showed the stack as having the added indexes and no drift
but a push would not let me add or remove the indexes or push any other changes


Branch 0.7

request for supporting insert iframe of  one paragraph to the other paragraph, this is very useful to increase the reusement and integration of paragraphs coded by different languages.

Hi, @simulight.
If you want to improve zeppelin about your idea, could you create a JIRA ticket?
And, this branch is fault. could you close this PR, please?

@simulight , Could you close this PR and create a new one ? This PR is mixed with other commits.


[bug]: Health check passes even though LND is not ready

I don't think it is unreasonable for Thunderhub's main http health check to succeed even if LND is not ready. Are you suggesting adding a second health check to poll for LND's readiness? What if you have multiple LND backends configured for thunderhub? We can't have a dynamic set of health checks.

We should probably add a second health check then on LND rather than coopting the existing one for it, I think. I just am nervous about the aggregate complexity of packages checking each other's health checks. I'm pretty sure theres a provision within the OS for packages to specify the importance of a dependency's health checks, which may be more appropriate here. CC @dr-bonez

Yeah you can just have th depend on one of lnd's health checks

Yeah you can just have th depend on one of lnd's health checks

Please link to the docs that describe how this is accomplished, or describe it here so it can be added to the docs.

I believe Aiden is referring to dependencies.yaml, where a list of health checks can be added to the dependency requirement like this.
But, I would also like to see some documentation on this feature. I assume the health check must be passing with exit code 0 in order for the requirement to be satisfied, and that the list consists of health check names?

I'm trying to use this as an opportunity to beef up the dev docs, there have been numerous reports of them being very inadequate.

what is the verdict on this issue? are we making TH depend on LND health checks?


Make record method public on Model

This makes the record method public on Model instead of being
protected. This is consistent with the records having public
model methods and simplifies scenarios when a model's record is
needed. This was originally done to try and discourage using the
record instead of the model. Ultimately, this kind of limiting
usage isn't really needed and doesn't help much.
This updates all locations that were using either send or
instance_eval to get around record being protected. This
simplified some and avoids extra noise.
This also adds a comment to the test helpers explaining usage of
record.class instead of record_class. This is to help avoid
"refactors" that try to switch to using record_class as a
simplification. record_class returns the configured record class
which in this case is not what we want. We want the current
record's class because it is a fake record so its class will not
match the configured record_class.
@kellyredding - Ready for review.

@jcredding cool 👎


Can't run jekyll serve

I can't run internally the build system. It tells me I am missing gems but they are installed, I can even check the version. However, I can do bundle exec jekyll install and it will run. Here is a screenshot

Testing this.

Even more issues at my end. :P
usr/local/lib/ruby/gems/2.3.0/gems/bundler-1.12.5/lib/bundler/resolver.rb:356:in `block in verify_gemfile_dependencies_are_found!': Could not find gem 'sanitize (~> 4.0.1)' in any of the gem sources listed in your Gemfile or available on this machine. (Bundler::GemNotFound)
	from /usr/local/lib/ruby/gems/2.3.0/gems/bundler-1.12.5/lib/bundler/resolver.rb:331:in `each'
	from /usr/local/lib/ruby/gems/2.3.0/gems/bundler-1.12.5/lib/bundler/resolver.rb:331:in `verify_gemfile_dependencies_are_found!'
	from /usr/local/lib/ruby/gems/2.3.0/gems/bundler-1.12.5/lib/bundler/resolver.rb:200:in `start'
	from /usr/local/lib/ruby/gems/2.3.0/gems/bundler-1.12.5/lib/bundler/resolver.rb:184:in `resolve'
	from /usr/local/lib/ruby/gems/2.3.0/gems/bundler-1.12.5/lib/bundler/definition.rb:200:in `resolve'
	from /usr/local/lib/ruby/gems/2.3.0/gems/bundler-1.12.5/lib/bundler/definition.rb:140:in `specs'
	from /usr/local/lib/ruby/gems/2.3.0/gems/bundler-1.12.5/lib/bundler/definition.rb:185:in `specs_for'
	from /usr/local/lib/ruby/gems/2.3.0/gems/bundler-1.12.5/lib/bundler/definition.rb:174:in `requested_specs'
	from /usr/local/lib/ruby/gems/2.3.0/gems/bundler-1.12.5/lib/bundler/environment.rb:19:in `requested_specs'
	from /usr/local/lib/ruby/gems/2.3.0/gems/bundler-1.12.5/lib/bundler/runtime.rb:14:in `setup'
	from /usr/local/lib/ruby/gems/2.3.0/gems/bundler-1.12.5/lib/bundler.rb:95:in `setup'
	from /usr/local/lib/ruby/gems/2.3.0/gems/jekyll-3.1.6/lib/jekyll/plugin_manager.rb:33:in `require_from_bundler'
	from /usr/local/lib/ruby/gems/2.3.0/gems/jekyll-3.1.6/bin/jekyll:9:in `<top (required)>'
	from /usr/local/bin/jekyll:23:in `load'
	from /usr/local/bin/jekyll:23:in `<main>'

Installing relevant gems.

FWIW, it doesn't seem like the problem is exclusive to jemoji. I replaced it with github-pages in _config.yml and it is giving me an identical error claiming github-pages isn't installed. Troubleshooting…

I know.. it's like this since Wednesday. The problem at first was gem jekyll-last-modified-at, and then it was something else, and then jemoji.. I don't know what's going on. For now I am bypassing the issue with the exec serve command.. Since I don't know programming this is me right now.

It may be that that's the correct way forwards: https://stackoverflow.com/questions/35167549/jekyll-dependency-error-when-upgrading-from-2-x-to-3-x
I'm still investigating.

So, the best way to get up and running is to use bundler. TLDR at the bottom...
Ruby packages (gems) are generally shared stored in a central location. But this can lead to conflicts between versions required by different things, so Bundler was invented as a way to keep a nice tidy local set of gems installed for a particular project. If you do jekyll serve it looks in the central install of gems, and the ones that your jekyll setup needs are probably not installed there.
Instead you run bundle exec <command> which takes everything after bundle exec and runs it in the context of the nearest local gem store (usually the current directory). So bundle exec jekyll serve is the best way to get the server running. And bundle install is the best way to make sure everything is installed in the local directory.
TLDR
bundle install
bundle exec jekyll serve

Lesson learnt: "When in doubt, give @blahah a shout."

s/shout/food reward/ 👌

@blahah and why do I also get this:
GitHub Metadata: No GitHub API authentication could be found. Some fields may be missing or have incorrect data.

Doesn't rhyme. No can do. ;)

@sabgaby that's because the github-metadata jekyll plugin is installed, but no Github API key has been provided.
I don't think the plugin is actually being used, so you can remove it from the _config.yml and the message should stop...

@RaoOfPhysics s/shout/stout/ 🍺  ?

s/shout/stoat/

Sorry about clogging your issue, @sabgaby. :P

stoat doesn't rhyme with shout....

Not with that attitude…

:tada: Solution!:

In the terminal cd to the repository
Run gem cleanup
Run gem list, check that "jekyll" is there.
Run sudo bundle clean --force and input your password
Run jekyll serve

This should work!

Can confirm, it works! :D


Produce Linux package cache as a tarball instead of zip

Our docker images don't have unzip installed. If we produce a tarball instead, then we can use tar to extract the package cache.
cc @JunTaoLuo

cref https://github.com/aspnet/aspnet-docker/blob/99cda5101970dff0b0e32845ee8dd8bc4633da9e/2.0/jessie/runtime/Dockerfile#L11-L13

Are you referirng to the runtime store? It's supposed to be a tar.gz as captured at https://github.com/aspnet/Coherence-Signed/issues/428#issuecomment-296279747

Yes, I meant "store".

We already had code to do this in another repo. @JunTaoLuo checkout
https://github.com/aspnet/Coherence-Final/blob/dev/packaging/targets/packagecache.targets#L250-L261
and  https://github.com/aspnet/Coherence-Final/blob/dev/scripts/zip2tgz.sh

Wrong build step. The zip file we use is actually produced in our signing steps, not here.


Allow for running a backup without gzip'ing the result in tar

A community user asked about running a backup without having the resutling tar file Gzip'd: https://community.influxdata.com/t/disable-gzip-for-database-backups/20110
It doesn't look like this is currently possible to do in either 2.x or 1.x, but it might be beneficial for use-cases like these.

I split the 2.x piece of this to influxdata/influx-cli#113

This is solved in 2.x , will not be fixed in 1.x OSS.


[Feature/Bug]

Add dark mode to local storage so it stays on page refresh.
Currently the dark mode toggle goes away after refreshing the page.
To fix this store the state in the local storage and make dark mode default.

I would recommend using local storage, as cookies are better when we need to send information to the server.

Local storage would also work yea.

Please assign this issue to me.

Please assign this issue to me.

Done! Thanks for contributing!