dialog inherits Localizations

/cc @HansMuller @Hixie

This doesn't seem like the right solution. Suppose someone else came up with their own localization mechanism -- how would they plug their localization widget into the showDialog function?

@Hixie perhaps I'm misunderstanding you, but I thought that was exactly what I was fixing. Previously, if you wrapped showDialog in your own Localizations widget, showDialog would ignore you and default to the top-level Localizations object. In the test included in this PR, the custom Localizations.override(locale: const Locale('ru', 'RU')) would previously have no effect on the contents of the dialog and the test would fail. Note that the fix does not provide any new localization objects, but only assigns the BuildContext that the user passed in. We do the same for Theme in showDialog.

I mean if I used a HixieLocalization widget instead of a Localization widget, how would I get showDialog to use my HixieLocalization logic? Where HixieLocalization has nothing to do with the Localization we ship in the Flutter framework.

Ah, I see. It seems the more general problem is that InheritedWidget operates on parents that host your BuildContext rather than those that created your widget. Here's @HansMuller's abandoned attempt to fix it: https://github.com/flutter/flutter/pull/6072.
We could resurrect that effort. However, if we decide to work within the current semantics, I can try to justify why it's reasonable to fix it this way. I think it comes down to who's job it is to set ambient information when widgets are reparented. For showDialog, which is part of material.dart, I think it's reasonable to set material-specific ambient information that's idiomatic to the material.dart library. If you are using material.dart, you would really be swimming against the current if you tried to use a different localization mechanism. We provide a way to extend Localizations with custom delegates, which is compatible with this fix. You shouldn't need to replace the whole thing.
If you have inherited widgets other than Localizations that you want to propagate into the dialog, you can still do it by wrapping the child that you are passing to showDialog, just like this change does with Localizations. That would be subject to the semantics of the ambient information your inherited widget publishes, so showDialog wouldn't do anything about it automatically. This method would work for HixieLocalization too, just without help from showDialog.
If that's not convincing, I'm open to ideas.

One could also argue that the dialog isn't "in" the place from which it was launched, it's at the top level of the app, and therefore should follow the app's own locale.

If you have inherited widgets other than Localizations that you want to propagate into the dialog, you can still do it by wrapping the child that you are passing to showDialog, just like this change does with Localizations. That would be subject to the semantics of the ambient information your inherited widget publishes, so showDialog wouldn't do anything about it automatically. This method would work for HixieLocalization too, just without help from showDialog.

Why is Localizations special? Our usual approach is not treat anything in the framework as special.

I cannot say for sure that this is the correct fix, but also not sure the reasons you provided invalidate it either. Some context for this PR: the actual problem that I'm trying to fix is localization in showTimePicker and showDatePicker. There is no way for a developer to supply Localizations because the developer does not instantiate the picker widgets directly. The library functions do it for you. For the date/time use-case the locale set on the dropdown invoking the picker has to be consistent with the locale in the dialog. However, we currently pop you out to the app-level locale.

One could also argue that the dialog isn't "in" the place from which it was launched, it's at the top level of the app, and therefore should follow the app's own locale.

This is unlikely to be a reasonable default for date/time picker use-case. Also, would this logic not apply to Theme too? See https://github.com/flutter/flutter/blob/b5ea59d5f6ee3f3c11525baca48b6e52889b0579/packages/flutter/lib/src/material/dialog.dart#L466

Why is Localizations special? Our usual approach is not treat anything in the framework as special.

Localizations is not treated special by anything outside material.dart. However, within material.dart it is already special because all our widgets depend on it explicitly. Because showDialog is part of material.dart, for it to be aware of Localizations make it no more special than it already is. Maybe I'm missing something, but this seems no different from, say, PaginatedDataTable treating Localizations as special. Adding a different localization mechanism will have no effect on material widgets. We haven't designed it this way. Instead, a developer who wants to customize Localizations would provide different "delegate" implementations. AFAICT this PR is compatible with that design.

This logic definitely also applies to Theme. I'm not a fan of how we solved that either...
Would it make sense to solve this in the same way we solved Theme? At least then we'd have an established pattern and any solution we found for one would apply to the other...

How about, for now, I add locale and textDirection parameters to the showTimePicker function, like I did in showDatePicker? This would solve the immediate problem of not being able to choose the these parameters other than via the MaterialApp.

Does the shadowThemeOnly approach not work?

Closing this, since this particular approach is not what we want to go with. I'll file an issue instead.


question: about example

Sorry I could not understand the example.
<input type="password" id="password" value="aaa" /> of client side.
this is used for?
Or not matter login information of client side in this example?
i need check username and password inside app.post('/login', function (req, res) { correct?
if user found in db return token to user correct?
after return token to user, save this in localstorange? correct?
if user has token in localstorange so will bypass login text field? and automatically login this user? correct?
I need use passport module like this http://mherman.org/blog/2015/01/31/local-authentication-with-passport-and-express-4/#.VWruwUaWyEJ to check username and password? Or could made more simple way?
i can use publick key generated by PuTTYgen in secret key or publick key ?

Yes for every question.
You can use passport-local but that's not necessary at all.


Update KeyGenerateCommand to only match "APP_KEY="

The KeyGenerateCommand was matching any key that contained "APP_KEY=". Changed str_replace to preg_replace to only match "APP_KEY=".
Addresses #17140
This corrects a previous PR in which the preg_replace was only matching in the case that the "APP_KEY" was blank.

str_replace('/', '\/', preg_quote($this->laravel['config']['app.key'])) can be changed to preg_quote($this->laravel['config']['app.key'], '/')


An error in main_supcon.py

in line 142,  it should be std = eval(opt.std)?

You're right. Noticed the same.

Good catch, fixed!


Back button not changing views

Once in the classes or professors view, clicking the back button changes the url but not the actual page itself. Probably a bug somewhere within all the switch statements in dashboard.tsx and router.tsx.

Ah, the routing is super messed up. This is because I rushed through it and therefore did a particularly poor job setting it up correctly. In an ideal situation, we'd have the Home, Class and Professor views rendered directly from the router instead of passing props through the Dashboard.

Yeah ok that's what I was thinking


fix: programWindow instructions

Hi there!
I believe that this number needs to be changed so it makes more sense for the idea of not being able to move out of bounds.

@junedev can you check? I actually think both may be incorrect XD.

I think I spotted another error so I tacked it on top.

Thank you James! I'll double check but the two changes seem reasonable. It's a bit of a weird duck ;)


DCOS-22310: Update node and npm

Testing

Run the usual commands, see if everything works as before

Trade-offs

I don't have the node and npm version checked in to the package.json because that caused some trouble. I don't see a huge benefit to do it in a backport, so I decided to cut this corner. Feel free to convince me that we need it 😇
While trying to fix the bug caused by the checked in node and npm version I tried to update webpack. It did not fix the bug, but seems to work fine otherwise, so I think it makes sense to keep it.

Dependencies

There is a corresponding plugin branch.

^ reason is that we still have to switch versions otherwise - it might not be as painful as before, but it still adds some overhead 😞

@juliangieseke Seems like the error I got when trying to add node and npm as dependencies can be safely ignored. Therefore I add a commit to add them 👍

🎉

We have to backport our Jenkins setup, am I correct? We had issues building master in dcos with upgraded node version 🤔😕

But CI is green, so we should be good, shouldn't we?

Yes CI is green and this PR should be good to go, but I'm not sure if we're able to release 1.11 without backporting the tarball-based setup, after we upgraded node 🤔

We can merge it and open bumps that will additionally upgrade npm and node.

If we want to test dcos build we could clone the repo, make all changes: node/npm versions + dcos-ui sha and try building it

@DanielMSchmidt is that you could maybe try?

I will first try to do a bump from this branch via CI, afterwards I should be able to make a PR on dcos to see if it works

Its green ✅- phew.


Finetuning research: output length, type of report(?)

Hi,
Love the project! Though I would like to make GPTResearcher to have a longer output and do more in depth research. Also I like to influence the way of outputting. Not sure what the output formats exactly mean, didn't find documentation (difference research/resource/outline report) on them yet(?)
Tried to ask GPTResearcher to give me that answer, but it couldn't give me that yet :-)
Thanks!
Steven

Hey @stevenbaert ! You can change the "report_format" in the config.py file to any format you'd like. It's set to APA by default. Check the doc here for more info: https://docs.tavily.com/docs/gpt-researcher/config

Thanks! But if I use the pypi package install, then where is that config file?

You can add a path to your own JSON file


No way to manually provide pull_request information?

Hi,
In our setup, we use workflow_dispatch to manually kick off our cypress runs. Because of this, the workflow dispatches are run without a pull_request or pull_request-like context. Because of this (I believe), our dashboard does not contain any PR information related to test runs. Is there a way to manually provide PR information to the Cypress github action so that we can associate those runs with their appropriate PRs?

It’s true. We have a workaround that manually digs up the pull request via
api call. I was just hoping there was a way to manually provide that
information.
On Fri, Apr 30, 2021 at 1:52 PM Gleb Bahmutov @.***>
wrote:

Great question, but running on workflow_dispatch ... does not have a pull
request, right? So what would the PR info even be in this case?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/cypress-io/github-action/issues/350#issuecomment-830381898,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKA2EVJ2AHDKVFLMTQ3DRDTLMKB3ANCNFSM42VJ7DWQ
.

I don’t mind working on this, we had this question come up often enough
Sent from my iPhone

On Apr 30, 2021, at 18:27, David Drew @.***> wrote:

It’s true. We have a workaround that manually digs up the pull request via
api call. I was just hoping there was a way to manually provide that
information.
On Fri, Apr 30, 2021 at 1:52 PM Gleb Bahmutov @.***>
wrote:

Great question, but running on workflow_dispatch ... does not have a pull
request, right? So what would the PR info even be in this case?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/cypress-io/github-action/issues/350#issuecomment-830381898,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKA2EVJ2AHDKVFLMTQ3DRDTLMKB3ANCNFSM42VJ7DWQ
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

That would be awesome! Thanks for all the great work!
On Fri, Apr 30, 2021 at 3:31 PM Gleb Bahmutov @.***>
wrote:

I don’t mind working on this, we had this question come up often enough
Sent from my iPhone

On Apr 30, 2021, at 18:27, David Drew @.***> wrote:

It’s true. We have a workaround that manually digs up the pull request
via
api call. I was just hoping there was a way to manually provide that
information.
On Fri, Apr 30, 2021 at 1:52 PM Gleb Bahmutov @.***>
wrote:

Great question, but running on workflow_dispatch ... does not have a
pull
request, right? So what would the PR info even be in this case?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/cypress-io/github-action/issues/350#issuecomment-830381898
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AAKA2EVJ2AHDKVFLMTQ3DRDTLMKB3ANCNFSM42VJ7DWQ

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/cypress-io/github-action/issues/350#issuecomment-830435092,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKA2EVBOQVOZ3Y4JL26DM3TLMVTLANCNFSM42VJ7DWQ
.

We would also really appreciate this feature and I'm curious if there is any update on this.
We are trying to do something similar using repository_dispatch, where we can provide a payload to configure a pull request number.
We have a prototype working where we use repository_dispatch trigger adding a label to a PR and then the label trigger kicks off cypress. However, this intermediate label step is quite slow and it would be nice to trigger cypress directly in a way that passes our required PR checks.

See https://github.com/cypress-io/github-action#automatic-pr-number--url-detection

I’ve since moved to a position where we’re using Jenkins instead of GHA (groan), but thanks for moving this forward and out!


When a batch is expired or invalid expiry date, the product status is always displayed verified if the serial number is either recalled or decommissioned

Description -
If the user scans the product with the batch is expired or 2D matrix has an invalid date, the app shows "Product status" as Verified even in case the serial number is recalled or decommissioned. In the case of the valid or invalid serial number, product status is displayed correctly (Product expired or invalid expiry date ).
Below screenshot for reference -

Tested - Works fine
Product status shows expired

Today's date 6th July 2021


Exclamation set apart by em dashes

Hi,
I came across this sentence:
"Mix it, put it in the oven, and -- voila! -- you have cake."

And the exclamation mark is being treated as a sentence break:
[
   "Mix it, put it in the oven, and -- voila!",
  "-- you have cake."
]

More generally it seems that a sentence should be able to contain an em dash clause that ends with an exclamation or question mark:
"There are many -- oh so very many! -- similar cases."
"Some can be -- if I may say so? -- a bit questionable."

You're the expert and I'm not, but I couldn't resist pondering a bit how to handle this :)  Here's what occurred to me...
A simple-minded rule would be to avoid a break if the subsequent sentence would start with a dash.  But I searched a bit and found that there are counterexamples, such as this line from Moby Dick:

What do you see?—Posted like silent sentinels all around the town, stand thousands upon thousands of mortal men fixed in ocean reveries."

So that would imply that a slightly less simple-minded rule would be to suppress a break due to a question or exclamation mark, if that mark is immediately followed by a dash and if there is a dash somewhere earlier in the sentence.
In any case, thanks as always for the great gem

Hi ronen,
Thanks for adding this issue! I'm not sure how soon I'll be able to work on it as I am a little busy currently. On first glance though, it reminds me of single quotations, so my guess is that we can handle it similar to that (i.e. there are some cases where they appear inside of a sentence, some counter examples where only one appears, etc.).
Anyway, I'm confident there is a solution...just might be some time before I can work on it.

OK, no problem.  I've got my workaround in place (my client code does some pre-and post-processing anyway, so i added a check to for a sentence that starts with a dash etc.).

I think this should handle your examples (https://github.com/diasks2/pragmatic_segmenter/commit/d6419d071d44675b7f9ed9403cb62e1068cf11d1), but let me know if any issues pop up.


Revise GL CI parallelization and dependencies

So if I understand it correctly we should have the following stages and jobs:
stages:
  - verification
  - deploy

lint:
  stage: verification

test:
  stage: verification

deploy-heroku:
  stage: deploy

deploy-gl-pages:
  stage: deploy

This would result in maximum parallelization while making sure deploys only run if verifications are successful.

That's it, all the jobs under the verification stage run in parallel, whereas the deploy runs completely separately.

Resolved by #23.


Build failure

What happened:
build fails with
Created symlink /etc/systemd/system/cloud-init.target.wants/cloud-config.service -> /lib/systemd/system/cloud-config.service.
Created symlink /etc/systemd/system/cloud-init.target.wants/cloud-final.service -> /lib/systemd/system/cloud-final.service.
Created symlink /etc/systemd/system/cloud-init.target.wants/cloud-init-hotplugd.socket -> /lib/systemd/system/cloud-init-hotplugd.socket.
Created symlink /etc/systemd/system/cloud-init.target.wants/cloud-init-local.service -> /lib/systemd/system/cloud-init-local.service.
Created symlink /etc/systemd/system/cloud-init.target.wants/cloud-init.service -> /lib/systemd/system/cloud-init.service.
Processing triggers for libc-bin (2.34-3) ...
Processing triggers for dracut (056-3) ...
Errors were encountered while processing:
 gardenlinux-selinux-module
E: Sub-process /usr/bin/dpkg returned an error code (1)
make: *** [Makefile:73: aws-dev] Error 100

Debug Logs:
Fails on this commit
commit 68c84e15f59118f6581570bf1b8d639b787970a0 (HEAD -> main, origin/main, origin/HEAD)

How to reproduce it:
run make aws-dev on above commit.
Environment:
Fails on the garden linux dev machine <IP_ADDRESS>

Hi @marwinski,
thanks for the report. This occurs since the 19th, when the new [selinux-policy-default](https://packages.debian.org/unstable/selinux-policy-default) package got migrated to Debian testing (ref.: https://tracker.debian.org/news/1354144/accepted-refpolicy-2220220520-2-source-into-unstable/).
For internal tests, the fastest and easiest solution could be by holding back gardenlinux-selinux-module package. Keep in mind, that this may create further AVC messages. Since SELinux isn't running in enforcing mode this won't have any further impact. I'll try to provide a fix for this asap.
Thanks,
gyptazy


Flexible spending of Focus Points (in roll dialog)

From user @RGK13:

Points that can be spent on a power like Anger are flexible so if you plan to have some automation on that we will need to be able to select the power points spent and not a fix value.

This could be addressed by adding an option to spend focus points in the roll dialog.

From @RGK13: Also if it was possible to maybe have a pulldown menu on the battle card where we could select the number of power points for the power used. This could auto deduct from the character sheet and maybe even add the info(number of Focus points spent) to the chat window for all to see.

from @NinjaPirateBob

When confirming a combat roll it would be nice to have just a basic input for focus being spent and extra damage to add in the calculation. The focus cost doesn't have to be automated yet but having that query show on the chat card is an easy way to remember to deduct the correct amount.

Also, there are a lot of powers that add extra damage based on variable focus spent, and inputting how much extra damage should be factored into the calculation would be very useful.


Code Helper Renderer Locks up with Find Command

VSCode Version:

Version: 1.49.0
Commit: e790b931385d72cf5669fcefc51cdf65990efa5d
Date: 2020-09-10T17:39:53.251Z
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: <IP_ADDRESS>-electron.0
OS: Darwin x64 18.7.0

OS Version: macOS Mojave 10.14.6

Steps to Reproduce:

Invoke global search from vscode: Cmd + Shift + F
This alone will trigger the Code Helper to lock up its CPU cycles to 99% and hangs the app for the most part.

Eventually the main thread prompts the user to close wait or reopen their window.

Does this issue occur when all extensions are disabled?: Yes
This seems to be workspace specific issue. When I open another window for another directory the issue is not reproduced.

This has been reported but I have not been able to reproduce it consistently. Disabling the "search on type" setting might help https://github.com/microsoft/vscode/issues/87254


Fix tests when running in Darwin

When running on Darwin, the /private/ is not stripped from the
URL and so the test fails. Change the logic so that this is only
run when running on Linux platforms.

@swift-ci please test and merge


create history file if it doesnt exit

If there is no history file, e-q never creates one and the history is not stored

yay!


Theme token not being parsed when overriding CSS prop (Next.js)

I'm using Stitches with Next.js, and noticed what seems like it might be a bug the other day.
I'm able to do something like this without any problems:
import { styled, config } from "stitches.config";

const Button = styled("button", {
  color: "$purple10"
})

This works as expected.
However, if I then do this:
<Button css={{color: "$red10" }} />

I get something like the following:

So it looks like, for whatever reason, the token isn't being parsed, but this is only an issue when overriding.
Is anyone else experiencing this? I'm getting it in both Next.js 12.2.4 and Next.js 13.1.4.
Any help would be greatly appreciated.

Got same bug in here :(


Permissions

any chance a section on Permissions can be added. Some times company's hire new DevOps employees and would like to provide read only access so the newbie can at least see the details. If there is a read only permission that can be applied for this purposes, it is not mentioned on the page any where. This same issue holds for almost all AKS pages.
thanks,

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

ID: bdb3a253-ff94-1b97-62c9-e21153598452
Version Independent ID: b95ca0b2-e809-a149-dec7-a15ac2146ee1
Content: Create a persistent volume with Azure Files in Azure Kubernetes Service (AKS) - Azure Kubernetes Service
Content Source: articles/aks/azure-csi-files-storage-provision.md
Service: azure-kubernetes-service
GitHub Login: @MGoedtel
Microsoft Alias: magoedte

@mth11
Thanks for your feedback! We will investigate and update as appropriate.

@mth11
Thanks for your feedback! I've assigned this issue to the author who will investigate and update as appropriate.

@MGoedtel
Can you please check and add your comments on this doc update request as applicable.

Hello @mth11, this is a topic that I've been in discussion with the storage team as a general practice that we should deliver in our content. I have a work item created to capture this information and update the CSI driver article(s), but I don't have an ETA at this time. I'll follow up as soon as I have something concrete to share. Thanks!

Thanks for your dedication to our documentation. Unfortunately, the requested updates have not been made since the creation of this issue, and the timeline for resolution may vary based on resourcing. We are closing this issue for now, but feel free to comment here as necessary. #please-close


Musl support

Add support for pulling unwind info from debug link that is available
locally, if debug link can't be found dwarf unwinding will fail. Future work
may have the agent to pull debuginfo from parca server and allow
dwarf unwinding w/o debug link files available locally.
If the debug link file doesn't match the CRC report an error and don't
use it.
Fix finder so that it doesn't return debuglink matches pointing back at
the exe itself, this just leads to spurious crc failures.

@umanwizard  can you review this?   Thanks!

I still don’t have approval rights, but it looks good to me overall, so merge at your discretion!


refactor(api): Differentiate shake off tips for pick up tip and drop tip

overview
This PR separates the shake tip function for pick up and drop tip, as they require different shake behaviors.
pick_up_tip

Shake distance: 0.3 mm
Shake direction: X, then Y

drop_tip

Shake distance: 25% of the well/tip diameter (MAX=2.25 mm, MIN=1.00 mm)
Shake direction: X only

Closes #3903
changelog
APIv1 & APIv2

transform shake_off_tips to shake_off_tips_pick_up and shake_off_tips_drop

APIv2

add current tip diameter setter to pick_up_tip so the tip diameter is saved
add shake off distance logic to shake_off_tips, which was missing previously

review requests
@ChrisYarka @Laura-Danielle Do the shake behaviors above make sense?

From the description this sound correct but can we test it out together before we merge?

This pull appears to have been merged and released as part of 3.1.3. However, the change has an imbalance of push_speed() and pop_speed() in _shake_off_tips_pick_up(), which would seem to be a bug.


Needed classes and IDs for script.js

class='search'
id='marvel-info'

search button for city search should have a class of 'search'
the section of the modal body that we're putting the hero cards in should have an id of 'marvel-info'
the favorites button should have an id of 'fave'
the favorites list element should have a class of 'fave-list'
modal should have an id of 'result-modal'
text input for user to type in city should have an id of 'city-input'

We also need a class for the list of stored favorites the user can pick from. Let's use class = 'fave-hist'


"use of moved value" error after using lifetime fix macro

Compiling this code
use ::fix_hidden_lifetime_bug::fix_hidden_lifetime_bug;

#[fix_hidden_lifetime_bug(showme)]
async fn baz<'a>(a: &'static (), b: &'_ (), url: String) {
    consume(url);
}

fn consume(u: String) {
    println!("{}", u);
}

gives the following error
error[E0382]: use of moved value: `url`
 --> src/main.rs:9:13
  |
8 | async fn baz<'a>(a: &'static (), b: &'_ (), url: String) {
  |                                             --- value moved here
9 |     consume(url);
  |             ^^^ value used here after move
  |
  = note: move occurs because `url` has type `String`, which does not implement the `Copy` trait

Rust 1.53.0
I'm not sure if I'm doing something wrong or its a bug in the lifetime fix itself. The actual code I have works fine until I hit the lifetime bug, trying to fix it with this crate starts giving the value moved error.
Thank you for the crate!

Heh, silly me, with my tets suite I forgot to check against this real-life use case 🤦
If you use the showme feature, you'll see the issue: the instruction to just mention the captured vars actually moves them: the vars need to be borrowed. Fix incoming soon, thanks for reporting it!

Works for me now! Thanks for the quick fix. 👍


Please update to newest Swift Version

I'm having problems with this, I've downloaded it but it's couldn't update to Swift Version 3.2 so on stackoverflow I asked the question and they said to do this:
Go to https://github.com/KosyanMedia/Hotellook-iOS-SDK-Core, in your podfile update this lines
use_frameworks!
pod 'HotellookSDK', :git => 'https://github.com/KosyanMedia/Hotellook-iOS-SDK-Core.git'
pod 'SwiftProtobuf', :git => 'https://github.com/apple/swift-protobuf.git', :tag => '0.9.902'
And update pod via "pod update" command in console.
Use Swift language version 3.2
After I updated the podfile unfortunately it still doesn't work. Although it's updated to Swift 3.2 there are still problems. Please see my debug on  https://stackoverflow.com/questions/46368595/aviasalessdktemplate-cannot-be-imported-with-swift-3-2
Thanks so much and hope to hear from you soon.
Best,
Ned

Hi @nedbaynepowell!
In your Podfile try this versions:
pod 'HotellookSDK', :git => 'https://github.com/KosyanMedia/Hotellook-iOS-SDK-Core.git', :tag => 'v1.0.2'
pod 'SwiftProtobuf', :git => 'https://github.com/apple/swift-protobuf.git', :tag => '0.9.905'

Then pod update.
Let me know if this helped.

Thanks so much, it works now. :)


nco: 5.1.4 -> 5.1.5

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/nco/nco/releases.
meta.description for nco is: NetCDF Operator toolkit
meta.homepage for nco is: https://nco.sourceforge.net/
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 5.1.5 with grep in /nix/store/85zsdhqy44d3x442a6kvx13rl9qc9jx4-nco-5.1.5
found 5.1.5 in filename of file in /nix/store/85zsdhqy44d3x442a6kvx13rl9qc9jx4-nco-5.1.5

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
nco

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/85zsdhqy44d3x442a6kvx13rl9qc9jx4-nco-5.1.5 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A nco https://github.com/r-ryantm/nixpkgs/archive/0d09ef89ed8508c6d474fc9947b3a67313d6fcdb.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/85zsdhqy44d3x442a6kvx13rl9qc9jx4-nco-5.1.5
ls -la /nix/store/85zsdhqy44d3x442a6kvx13rl9qc9jx4-nco-5.1.5/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

nco

Maintainer pings
cc @bzizou for testing.

Result of nixpkgs-review pr 221759 run on aarch64-linux 1

1 package built:

nco


Navigate to chat when session is selected

When a session is activated we straight away naviage to the "chat page" so that you can continue chatting in that session.
For this I pass now the pageController into the SessionPage
Additionally I changed the order of the buttons: First the "Enter Session" and then the "Delete". This is more safe as you do not have to move with the mouse over the Delete button to reach the Enter button.

Good job! Can you do the same for models so we group everything into a single pull request?

Yes I will do this

Implemented now the same logic for the models. When one is activated we jump now to the chat.
Also changed the order of the buttons to match the sessions page again.


v1.14.6 release plan and checklist

This issue tracks the work that needs to be done to release v1.14.6.
If you disagree with or think I’ve missed anything, please comment and we’ll get it resolved.
Proposed deadlines

[x] Deadline for any pull requests that change UI strings: 2022-06-19
[x] Deadline for any other pull requests and translations: 2022-07-13
[x] Deadline for any tail-end maintainer work for release preparation: 2022-07-16

MUST HAVE (we should consider delay without these having been merged)

[x] #2988 - helps protect wallet users with upgrades
[x] #3030 - fixes known Bitcoin vulnerability
[x] #2758 - fixes potential vulnerability
[x] #2964 - makes using the Dogecoin Core wallet cheaper and advices 3rd party devs
[x] #2973 - we need an easy-to-use gitian script to release and to get some of the could-haves in
[x] #2976 - enables incoming work on addr messages
[x] #2991 - removes unmaintained code

SHOULD HAVE (we should do our utmost best to merge these)

[x] #2409 - dependency update
[x] #2934 - almost ready, would be a pity to not have this
[x] #2936 - dependency update
[x] #2996 - increases reliability of wallet backups
[x] #2997 - reduces unnecessary memory pressure for small nodes
[x] #3000 - adds simple constraints to an RPC call, increases reliability
[x] #3001 - removes unnecessary transaction post-processing, saves resources
[x] #3008 - removes unnecessary address processing, saves resources
[x] #3015 - cleans up network integer types
[x] #3037 - cleans up local sockets

COULD HAVE (nice to haves, non-critical for release)

[x] #2910 - cleans up warnings for compiling, non-blocking
[x] #2974 - improves ease-of-use but otherwise non-critical

Final translation updates

[x] Italian: #3014
[x] Korean: #3022
[x] Dutch: #3026
[x] Portuguese (pt_PT): #3029
[x] Bulgarian: #3036

Maintainer tasks for release

[x] Refresh baseline language files - on 2022-06-22

#3009 - baseline
#3010 - recently updated translations
#3011 - everything else

[x] Update manpages: #3027
[x] Update fixed seeds: #3038
[x] Update checkpoints: #3031
[x] Update copyrights: #3045
[x] Write release notes:

#3035 - first draft
#3043
#3044
#3046
#3047

[x] Fixate v1.14.6 in source: #3048
[x] Tag v1.14.6
[ ] Gitian builds for v1.14.6
[ ] Fast-fwd 1.14-maint
[ ] Fast-fwd master
[ ] Upload binaries and sha256sum files

Post-release tasks

[ ] Create 1.14.7-dev branch
[ ] Open 1.14.7-dev for development
[ ] Rebase open PRs
[ ] Delete 1.14.6-dev

Fixed year in deadlines 😂 - thanks @xanimo

Is it possible to include the file checksum in the release download page and the dogecoin website. Thank

Similar to bitcoin's release process, the .assert files for windows/linux can be included in the release bucket along with their respective assert.sig files including every signature.

Currently, it's not made clear to the user where to find checksums.  I don't see anything in the release description, release notes or getting started guide.

Is there an easy way to use .assert file? sha 256 checksum seems to be the most user friendly way

We can add a sha256sum file too. Adding that to the above.

Added #2991 as a must-have, this came up when looking at network hardening

Added #2996 as should have. This improves backups (prevents situations where files get overwritten by accident)
Removed #2957 and #2942 (nice to haves) - postponed until next release
Deprioritized #2959 because it can use some more time to work through some of the issues we've ran into. If it gets ready in time, we can still merge it, but there's no issue if it isn't ready in time, because we postponed all dependent changes.

Added #2997 as should-have

Added #3000 and #3001 as should-have

Changed the target date for updating translation files to 6/22 because we're still working on the review of #3001

Added #3008 as should-have because it saves us processing power.

Added #3015 as should-have because it's cleanup and small

Per the above, I've set the new proposed deadline for PRs incl translations to July 13th.

Correct, and those can be deleted once you're done. We keep those in case that there is a partial change, so you can look up the old translation.

Correct, and those can be deleted once you're done. We keep those in case that there is a partial change, so you can look up the old translation.

Okay, awesome.
Also, does the language swap mechanism in the software work similarly to how a pivot table works in something like google sheets? 🙂
(Grabs information from an array and displays it accordance with the specified parameters)

Removed #1986 and #2482(all could-haves) because they're not ready, and #2773 because it's an experimental improvement and not urgent enough.
The only other one that I am not sure of to make it in is #2959, but I'm keeping it there for now.

Added a section to track final translation updates

All must-have items are in now - I have marked the second deadline as met. Thanks everyone for your awesome work!!!
If anyone that reads this speaks Portuguese and/or Bulgarian, we could really use your help: The Portuguese translation in #3029 and the Bulgarian translation in #3036 could really use an opinion from a native speaker.

Added #3037 to should-have because it cleans up local socket code. Removed #2959 because we need more time for that.

Added "update copyrights" maintainer task as we seem to always forget that... but not this time 😊

Removed #2726 - needs some work and we think it's best to split it off into its own repo.

All work is proposed and in a good state - ✅
Open pulls are approved - ✅
24-hour grace period for these final approvals is in effect - ⏳
... after that, bar anything crazy, we'll be building the release. 🥳

Tagged v1.14.6 ✅
I'm starting a gitian build on my end now (using LXC so everyone else can use docker). We will need at least 2 attested builds before we release binaries.

I'll attach my signatures here:
bf6123a91ba2829e03dc7c48865971dd615b78249f6ee41a4e796f942bd93869  dogecoin-1.14.6-osx-unsigned.dmg
e48ac5ff72462615b3cf3fea576370aa3473383062fe711cac648fca5f6e2819  dogecoin-1.14.6-osx-unsigned.tar.gz
e3a7f1072d7763133bdb9a0be7774ce97210f3085e649cc7d103f3606ccceadf  dogecoin-1.14.6-osx64.tar.gz
e0ac42b06b6feee06f853c9c9f7657713817f993e9e00915758cf408448accee  src/dogecoin-1.14.6.tar.gz
d66c31aa4d28cef0d1ca152a4692c123b1718fc82161f3d7e4459c065377519e  dogecoin-osx-1.14-res.yml

28b6e155aabd5e5f50f520048f1bc45d73fa52637676c30e23286e30c5240e26  ./dogecoin-1.14.6-aarch64-linux-gnu-debug.tar.gz
87419c29607b2612746fccebd694037e4be7600fc32198c4989f919be20952db  ./dogecoin-1.14.6-aarch64-linux-gnu.tar.gz
36297b817e9fdbcb533575d43995a00d28648d9f2f17c09a88dd8fc39035764f  ./dogecoin-1.14.6-arm-linux-gnueabihf-debug.tar.gz
d0b7f5f4fbabb6a10078ac9cde1df7eb37bef4c2627cecfbf70746387c59f914  ./dogecoin-1.14.6-arm-linux-gnueabihf.tar.gz
df5ea74f46b2910fa6ece56c0b6099258b62f57e55175db4d7b0b52047d6d03b  ./dogecoin-1.14.6-i686-pc-linux-gnu-debug.tar.gz
3e60c4c818cb44abcca5b3bf9eff6baf86834c762e41d886c19bd721c00d0e24  ./dogecoin-1.14.6-i686-pc-linux-gnu.tar.gz
ef418bc4fd6ef69f60da37432d2b52f88c3703f666a8ab0edb0f7f8a2c9d6d28  ./dogecoin-1.14.6-x86_64-linux-gnu-debug.tar.gz
b9c5480cfd4fd34e524e057d04f6990679f2c83be5a868dab3aaaa8aa85b189c  ./dogecoin-1.14.6-x86_64-linux-gnu.tar.gz
e0ac42b06b6feee06f853c9c9f7657713817f993e9e00915758cf408448accee  ./dogecoin-1.14.6.tar.gz

ef418bc4fd6ef69f60da37432d2b52f88c3703f666a8ab0edb0f7f8a2c9d6d28  ./dogecoin-1.14.6-x86_64-linux-gnu-debug.tar.gz
b9c5480cfd4fd34e524e057d04f6990679f2c83be5a868dab3aaaa8aa85b189c  ./dogecoin-1.14.6-x86_64-linux-gnu.tar.gz

vs
a3d442b3b28d22ee08f208deb0e6a922975ad9ef3f32355de54094847981f98f  dogecoin-1.14.6-x86_64-linux-gnu-debug.tar.gz
fe9c9cdab946155866a5bd5a5127d2971a9eed3e0b65fb553fe393ad1daaebb0  dogecoin-1.14.6-x86_64-linux-gnu.tar.gz

That's a mismatch.
I'll re-run my build.

Re-built on new box:
28b6e155aabd5e5f50f520048f1bc45d73fa52637676c30e23286e30c5240e26  dogecoin-1.14.6-aarch64-linux-gnu-debug.tar.gz
87419c29607b2612746fccebd694037e4be7600fc32198c4989f919be20952db  dogecoin-1.14.6-aarch64-linux-gnu.tar.gz
36297b817e9fdbcb533575d43995a00d28648d9f2f17c09a88dd8fc39035764f  dogecoin-1.14.6-arm-linux-gnueabihf-debug.tar.gz
d0b7f5f4fbabb6a10078ac9cde1df7eb37bef4c2627cecfbf70746387c59f914  dogecoin-1.14.6-arm-linux-gnueabihf.tar.gz
df5ea74f46b2910fa6ece56c0b6099258b62f57e55175db4d7b0b52047d6d03b  dogecoin-1.14.6-i686-pc-linux-gnu-debug.tar.gz
3e60c4c818cb44abcca5b3bf9eff6baf86834c762e41d886c19bd721c00d0e24  dogecoin-1.14.6-i686-pc-linux-gnu.tar.gz
bf6123a91ba2829e03dc7c48865971dd615b78249f6ee41a4e796f942bd93869  dogecoin-1.14.6-osx-unsigned.dmg
e48ac5ff72462615b3cf3fea576370aa3473383062fe711cac648fca5f6e2819  dogecoin-1.14.6-osx-unsigned.tar.gz
e3a7f1072d7763133bdb9a0be7774ce97210f3085e649cc7d103f3606ccceadf  dogecoin-1.14.6-osx64.tar.gz
79d40c68fbf3040d8aae87a24a856cbaf732dd63851e77cf66693430ff19fe98  dogecoin-1.14.6-win32-debug.zip
c3dd01612f70afaf7b293199e016feeb8c5071fbb673a02a3baf24d04014cc02  dogecoin-1.14.6-win32-setup-unsigned.exe
c919fdc966764ec554273791699426448eedd8d305e76284e4f1cd1d5f0b5a7a  dogecoin-1.14.6-win32.zip
9d3039fa33afe7886e7761dcd735745ac870e57288328e47dddb4a24ca81889c  dogecoin-1.14.6-win64-debug.zip
888429200b5cd1a414e33215e8e8aea0957fa7a615c407b19b8a9ab2fa9e180a  dogecoin-1.14.6-win64-setup-unsigned.exe
709490ac8464b015266884831a2b5b594efc8b2c17a7e6b85255058cbee049de  dogecoin-1.14.6-win64.zip
a3d442b3b28d22ee08f208deb0e6a922975ad9ef3f32355de54094847981f98f  dogecoin-1.14.6-x86_64-linux-gnu-debug.tar.gz
fe9c9cdab946155866a5bd5a5127d2971a9eed3e0b65fb553fe393ad1daaebb0  dogecoin-1.14.6-x86_64-linux-gnu.tar.gz
e0ac42b06b6feee06f853c9c9f7657713817f993e9e00915758cf408448accee  dogecoin-1.14.6.tar.gz

This looks good, I'm going to process sigs and publish over at gitian.sigs, will supply link when done.

bf6123a91ba2829e03dc7c48865971dd615b78249f6ee41a4e796f942bd93869  dogecoin-1.14.6-osx-unsigned.dmg
e48ac5ff72462615b3cf3fea576370aa3473383062fe711cac648fca5f6e2819  dogecoin-1.14.6-osx-unsigned.tar.gz
e3a7f1072d7763133bdb9a0be7774ce97210f3085e649cc7d103f3606ccceadf  dogecoin-1.14.6-osx64.tar.gz
e0ac42b06b6feee06f853c9c9f7657713817f993e9e00915758cf408448accee  src/dogecoin-1.14.6.tar.gz
2faf4b06a4e7b28358de0bce20748e3f4355c1ca88e13521179209a319beb2e5  dogecoin-osx-1.14-res.yml
c16054edea300152e4f52068c6dbecd84e40c88330af74eb9bdadc7b0d0f58f6  dogecoin-1.14.6-win-unsigned.tar.gz
79d40c68fbf3040d8aae87a24a856cbaf732dd63851e77cf66693430ff19fe98  dogecoin-1.14.6-win32-debug.zip
c3dd01612f70afaf7b293199e016feeb8c5071fbb673a02a3baf24d04014cc02  dogecoin-1.14.6-win32-setup-unsigned.exe
c919fdc966764ec554273791699426448eedd8d305e76284e4f1cd1d5f0b5a7a  dogecoin-1.14.6-win32.zip
9d3039fa33afe7886e7761dcd735745ac870e57288328e47dddb4a24ca81889c  dogecoin-1.14.6-win64-debug.zip
888429200b5cd1a414e33215e8e8aea0957fa7a615c407b19b8a9ab2fa9e180a  dogecoin-1.14.6-win64-setup-unsigned.exe
709490ac8464b015266884831a2b5b594efc8b2c17a7e6b85255058cbee049de  dogecoin-1.14.6-win64.zip
e0ac42b06b6feee06f853c9c9f7657713817f993e9e00915758cf408448accee  src/dogecoin-1.14.6.tar.gz
1668245e33f1c3d27fe6e7fb6889a2ba5700da79a8438c1584ccd15bd5b580b4  dogecoin-win-1.14-res.yml
28b6e155aabd5e5f50f520048f1bc45d73fa52637676c30e23286e30c5240e26  dogecoin-1.14.6-aarch64-linux-gnu-debug.tar.gz
87419c29607b2612746fccebd694037e4be7600fc32198c4989f919be20952db  dogecoin-1.14.6-aarch64-linux-gnu.tar.gz
36297b817e9fdbcb533575d43995a00d28648d9f2f17c09a88dd8fc39035764f  dogecoin-1.14.6-arm-linux-gnueabihf-debug.tar.gz
d0b7f5f4fbabb6a10078ac9cde1df7eb37bef4c2627cecfbf70746387c59f914  dogecoin-1.14.6-arm-linux-gnueabihf.tar.gz
df5ea74f46b2910fa6ece56c0b6099258b62f57e55175db4d7b0b52047d6d03b  dogecoin-1.14.6-i686-pc-linux-gnu-debug.tar.gz
3e60c4c818cb44abcca5b3bf9eff6baf86834c762e41d886c19bd721c00d0e24  dogecoin-1.14.6-i686-pc-linux-gnu.tar.gz
a3d442b3b28d22ee08f208deb0e6a922975ad9ef3f32355de54094847981f98f  dogecoin-1.14.6-x86_64-linux-gnu-debug.tar.gz
fe9c9cdab946155866a5bd5a5127d2971a9eed3e0b65fb553fe393ad1daaebb0  dogecoin-1.14.6-x86_64-linux-gnu.tar.gz
e0ac42b06b6feee06f853c9c9f7657713817f993e9e00915758cf408448accee  src/dogecoin-1.14.6.tar.gz
6f65292cd451ffa98ffc4f377f099dabdbf2bc15750307a9896d5b0c80888992  dogecoin-linux-1.14-res.yml

:partying_face: :rocket: here's sigs:
https://github.com/dogecoin/gitian.sigs/pull/29

Inprocess!
bf6123a91ba2829e03dc7c48865971dd615b78249f6ee41a4e796f942bd93869  dogecoin-1.14.6-osx-unsigned.dmg
e48ac5ff72462615b3cf3fea576370aa3473383062fe711cac648fca5f6e2819  dogecoin-1.14.6-osx-unsigned.tar.gz
e3a7f1072d7763133bdb9a0be7774ce97210f3085e649cc7d103f3606ccceadf  dogecoin-1.14.6-osx64.tar.gz
e0ac42b06b6feee06f853c9c9f7657713817f993e9e00915758cf408448accee  src/dogecoin-1.14.6.tar.gz
f97005946fac85d3fca771f29ed73990b1f88b37315767b0ac441ee43a7bc7e7  dogecoin-osx-1.14-res.yml

... to be continued

Doing this for the first time, here are my signatures:
bf6123a91ba2829e03dc7c48865971dd615b78249f6ee41a4e796f942bd93869  dogecoin-1.14.6-osx-unsigned.dmg
e48ac5ff72462615b3cf3fea576370aa3473383062fe711cac648fca5f6e2819  dogecoin-1.14.6-osx-unsigned.tar.gz
e3a7f1072d7763133bdb9a0be7774ce97210f3085e649cc7d103f3606ccceadf  dogecoin-1.14.6-osx64.tar.gz
e0ac42b06b6feee06f853c9c9f7657713817f993e9e00915758cf408448accee  src/dogecoin-1.14.6.tar.gz
b13185610af8268aed66a7caab597baa013657994a60758d00d203196a6b50c4  dogecoin-osx-1.14-res.yml
c16054edea300152e4f52068c6dbecd84e40c88330af74eb9bdadc7b0d0f58f6  dogecoin-1.14.6-win-unsigned.tar.gz
79d40c68fbf3040d8aae87a24a856cbaf732dd63851e77cf66693430ff19fe98  dogecoin-1.14.6-win32-debug.zip
c3dd01612f70afaf7b293199e016feeb8c5071fbb673a02a3baf24d04014cc02  dogecoin-1.14.6-win32-setup-unsigned.exe
c919fdc966764ec554273791699426448eedd8d305e76284e4f1cd1d5f0b5a7a  dogecoin-1.14.6-win32.zip
9d3039fa33afe7886e7761dcd735745ac870e57288328e47dddb4a24ca81889c  dogecoin-1.14.6-win64-debug.zip
888429200b5cd1a414e33215e8e8aea0957fa7a615c407b19b8a9ab2fa9e180a  dogecoin-1.14.6-win64-setup-unsigned.exe
709490ac8464b015266884831a2b5b594efc8b2c17a7e6b85255058cbee049de  dogecoin-1.14.6-win64.zip
e0ac42b06b6feee06f853c9c9f7657713817f993e9e00915758cf408448accee  src/dogecoin-1.14.6.tar.gz
b1d68bd09dc14169b14e545ea9f80147eaeed7bdd9ab9629d5de4704a2dd4c10  dogecoin-win-1.14-res.yml

@xanimo's sigs are in, mine are pending in dogecoin/gitian.sigs#30
I'll do the macOs signing tomorrow - will have to see if attestation is going to work. If not, we'll have to figure that out for 1.14.7
For windows, I hope to finally have my windows certs tomorrow too. If not I will report back here.

For windows, I hope to finally have my windows certs tomorrow too. If not I will report back here.

The current reason why my cert hasn't arrived is because Sectigo has for some reason changed the country code for my phone number for dev validation, so they're trying to call me in the wrong country (continent even 😂) I'm dealing with (=waiting on) their support right now.
Worst case, we'll append signed windows binaries to the release files afterwards - wouldn't be a regression as there have never been signed windows binaries.
MacOS - simple signed binaries are going to be a go, am currently trying to find a way to get it notarized through Xcode, to make installation more user-friendly. Expect to have at least some results later.

Windows status: still waiting on Sectigo support
macOS status:

signing works
notarization seems to work
deterministic signing does not work (but I learned today that it never has for 1.14 - will open a separate issue)

PROPOSAL
At this point, we're at the same deliverables as we had with 1.14.5 for windows, and the signed Mac binary is improved but still not deterministic. To make a deterministic macOS build with signing and notarization, we'll need to do some changes to the gitian and macdeploy scripts, and probably have to integrate signapple instead of the current process, so here's my proposal:

Publish *-osx-* binaries, both unsigned deterministic and signed+notarized non-deterministic.
Publish unsigned *-win* binaries as we've done so far
Work on the signing process for macOS inside 1.14.7 together with everything else
If my Windows cert arrives this week (getting less likely as time passes) AND there isn't a similar issue with the detached windows signing, we add signed windows binaries to the release as soon as they are available. If not, we do a patch release <IP_ADDRESS> where we provide signed binaries for everything.

This can be executed right now and the release can be published as soon as we have a form of consensus on this.
Please share your thoughts.

Windows status: still waiting on Sectigo support macOS status:
* signing works

* notarization seems to work

* deterministic signing does not work (but I learned today that it never has for 1.14 - will open a separate issue)

PROPOSAL
At this point, we're at the same deliverables as we had with 1.14.5 for windows, and the signed Mac binary is improved but still not deterministic. To make a deterministic macOS build with signing and notarization, we'll need to do some changes to the gitian and macdeploy scripts, and probably have to integrate signapple instead of the current process, so here's my proposal:
1. Publish `*-osx-*` binaries, both unsigned deterministic and signed+notarized non-deterministic.

2. Publish unsigned `*-win*` binaries as we've done so far

3. Work on the signing process for macOS inside 1.14.7 together with everything else

4. If my Windows cert arrives this week (getting less likely as time passes) AND there isn't a similar issue with the detached windows signing, we add signed windows binaries to the release as soon as they are available. If not, we do a patch release <IP_ADDRESS> where we provide signed binaries for everything.

This can be executed right now and the release can be published as soon as we have a form of consensus on this.
Please share your thoughts.

This sounds sensible to me as you all have hit the baseline achieved for past releases so if anything the deterministic signed + notarized macOS binaries would be an added bonus at this point.
Re signed windows binaries, I'd opt for adding them to release as soon as they're available granted you don't encounter similar issues in the gitian build process as oppose to a <IP_ADDRESS> patch release.
Thanks for the update! :heart:

Ok so as I mentioned to Patrick otherwise -- from experience I do not have much faith in Sectigo providing a cert in a timely manner. That's just how their ship runs; I've been through the process at least 3 times and every time it was error prone and incredibly slow.
So while I am eager to see the windows build signed, I think that being at the mercy of waiting for Sectigo to go through their process. We can always add the signed release.
macOS, I think making both available will be good and, the unsigned deterministic will be available for those who care, and can compare the sigs on their own and know how to run it; whereas most laypersons will likely just go for the signed build and have a better experience.  So I think that's suitable.

I have no issue with the stated proposal since we have the binaries ready based on past releases. My comments below are mostly the same as stated above.
I have no problem releasing both macOS binaries, but the only minor issue I have is that the average person may be confused between a "deterministic" build and a "notarized" build.
I personally would prefer releasing signed windows binaries; however, it looks like Sectigo is causing issues. Since the last release only contained unsigned binaries, I have no problem releasing unsigned binaries since it won't be a regression. As already stated, we can add the signed release later.

:+1: to the proposal from me.

I agree with the proposal as we have covered our past deliverables!
Regarding the confusion @alamshafil is mentioning with macOS binaries, most people that tend to be confused will likely download the release from https://dogecoin.com/. For those using Github and having doubts, we can just provide the support through the usual channels.
Regarding Sectigo: I struggled with them for years with website certificates. It can take time, especially if there is some bureaucratic hiccup (not only, though). I could occasionally speed things up by contacting them through their web chats, which seem to work better than their phone numbers, for some reason.
Thanks all for the great work, you are awesome!

Looks like we're having consensus here so let's try and do the release this evening - let's arbitrarily pick 8pm EDT to not postpone for too long.  You're all awesome ❤

All open PRs have been re-routed to 1.14.7-dev (or closed). I will delete 1.14.6-dev in 1 hour and then we're done here.
Thanks everyone!


Git clone impossible on Windows

To Reproduce
>  git clone https://github.com/nhost/nhost
Cloning into 'nhost'...
remote: Enumerating objects: 82498, done.
remote: Counting objects: 100% (4945/4945), done.
remote: Compressing objects: 100% (2247/2247), done.
remote: Total 82498 (delta 3060), reused 4171 (delta 2576), pack-reused 77553
Receiving objects: 100% (82498/82498), 224.29 MiB | 19.21 MiB/s, done.
Resolving deltas: 100% (54274/54274), done.
error: invalid path 'docs/reference/auth/oauth-callback-url-that-will-be-used-by-the-oauth-provider-to-redirect-to-the-client-application-attention:-all-providers-are-using-a-get-operation-except-apple-and-azure-ad-that-use-post.mdx'
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'

> cd nhost

> dir
Volume in drive C has no label.
 Volume Serial Number is 1E2F-882D

 Directory of C:\Temp\nhost

25/07/2024  19:04    <DIR>          .
25/07/2024  19:04    <DIR>          ..
               0 File(s)              0 bytes
               2 Dir(s)  241,072,971,776 bytes free

> git restore --source=HEAD :/
error: invalid path 'docs/reference/auth/oauth-callback-url-that-will-be-used-by-the-oauth-provider-to-redirect-to-the-client-application-attention:-all-providers-are-using-a-get-operation-except-apple-and-azure-ad-that-use-post.mdx'

I guess error: invalid path 'docs/reference/auth/oauth-callback-url-that-will-be-used-by-the-oauth-provider-to-redirect-to-the-client-application-attention:-all-providers-are-using-a-get-operation-except-apple-and-azure-ad-that-use-post.mdx' is an invalid path for Windows (it has :, after all) and the whole git thing fails, leaving an empty folder.

Hi,
thanks for the report. Have you tried WSL2? Do you have any issues there?
Regards

Why I would use WSL2??? I'm on Windows! I don't need a linux shell for anything.
Nevertheless, this whole solution is very anti-native, so, I'm not using it anymore. Maybe it is good for web, but the world isn't resumed to a web environment.

I am sorry to hear that. What do you mean with anti native? We support react native and flutter and we have plenty of customers building for mobile. What issue are you having?

I am sorry to hear that. What do you mean with anti native? We support react native and flutter and we have plenty of customers building for mobile. What issue are you having?

That's how firebase auth works:

I call FirebaseAuth.instance.resetPassword(email: "foo@bar.com");
An e-mail is sent with a link to reset password
The link opens a Firebase Auth page to set up a new password (I don't need to program it).

That's how nhost works:

I call client.auth.resetPassword(email<EMAIL_ADDRESS>(or whatever the code is).
An e-mail is sent with a link to reset password
That link points to whatever is configurated on nHost settings (default to localhost:3000), so, I have to set up a whole web server to reset a password >.<

Considering I don't want to do that, I could set my redirect url to some custom protocol, such as my-app://redirect, so the reset password link is something like my-app://redirect&ticket=passwordReset:9f4e6dc2-64c4-4c7a-bdb5-2565cf4c9438&type=passwordReset.
So, grabbing that ticket number and calling the reset password confirmation method: ticket is invalid or expired.
So... not working.
(and, btw, is not possible to register a custom protocol so easily for Linux).
The whole thing appears to be web oriented only. It does NOT work with native credentials ()

The link opens a Firebase Auth page to set up a new password (I don't need to program it).

I am not sure how/why firebase does it but our users want to handle this in their own app/website. Also, a user using your app or website FOO trying to reset the password and being sent to a completely different company (firebase/nhost/whatever) to reset the password might be considered by most a security/privacy issue as users may not have any knowledge of this party and might regard it as an attempt at a phishing attack

That link points to whatever is configurated on nHost settings (default to localhost:3000), so, I have to set up a whole web server to reset a password >.<

You don't need a webserver, you just need something that responds. It can be a mobile or desktop app.

(and, btw, is not possible to register a custom protocol so easily for Linux).

You also don't need it. If you are writing a linux desktop app, the same app can open the webserver temporarily during the reset operation. That's how signin in with social works in all terminal and desktop applications as you need a callback in the oauth2 process.

The whole thing appears to be web oriented only

We fully support dart and react-native and we have very successful mobile only customers, but we are not here to debate this point, you have your reasons to believe that and that's fine. I just want to understand the frustration to see if there is something that can be done and/or needs doing.

It does NOT work with native credentials

I agree this is a minor shortcoming we need to fix, but there is no loss of functionality so it hasn't been a priority.

the whole process is incomplete (I have to implement reset password myself)

see my previous comment about phishing. I understand you may not care about that but the typical customer cares about providing a seamless experience keeping everything in their own website/application and avoid "scaring" their users.

considering Firebase Auth is 100% free of charge

their pricing page and all of our customers that migrated from firebase disagree with this :) statement but you should use what you think is the best tool for your use case
I just want to say thanks for the feedback, if you have more feel free to reach out


change priority of DispatchQueue

Connection with issue(s)
Resolve issue #2321
Connected to #2321
Testing and Review Notes
In same environment noted as issue, ssl verifying should be completed fast. (should be complete as much as fast with not affecting main thread)
However, it might be worthwhile to further discuss whether to change the QoS policy from default to something with a higher priority, such as userInitated.
Screenshots or Videos
To Do

[x] double check the original issue to confirm it is fully satisfied
[x] add testing notes and screenshots in PR description to help guide reviewers
[x] request the "UX" team perform a design review (if/when applicable)

Thanks, probably this implementation of using .background was caused by my low experience on what DispatchQoS.QoSClass really is.
At that time, probably, I got fooled by the word "background" to fix the "This method should not be called on the main thread as it may lead to UI unresponsiveness" message, thinking the background was only the "right" option.
I don't know about other priorities. Having it higher, could maybe lead to UI unresponsiveness? Have you tried the other priorities?
In the meantime, I can merge this.

@all-contributors please add @nnnlog for code

Below are higher priorities than default of DispatchQos:

userInteractive : The quality-of-service class for user-interactive tasks, such as animations, event handling, or updating your app's user interface.
userInitiated : The quality-of-service class for tasks that prevent the user from actively using your app.

According to definition of each priority, the heavy task such as verifying ssl certificate should not be executed in userInteractive. So, I'll test about when applying userInteractive and default priority, and check the difference between two priorities.


[data-client] use callback for error notification instead of response id

Previously the data client returned a response_id: u64 for each response and allowed consumers to report errors through a data_client.notify_bad_response(response_id, error) API. Unfortunately, this pattern effectively mandates that a data client maintains an internal cache/queue of recent requests and their associated context, which is a big pain.
This PR instead allows a data client to piggyback whatever additional context its needs in a response error callback, which a consumer can then call to notify the data client that this specific request had an issue.
By adding context into the callback closure, the data client no longer needs to maintain a recent request/response queue since whatever internal indices or context the data client needs to update internal scores is already in the right place: the callback.

rebased! just need a restamp + land

/land

@JoshLind :bulb: This PR is already queued for landing


Uncaught Error: Cannot read property 'object' of undefinedTypeError: Cannot read property 'objec...

[Enter steps to reproduce below:]

...
...

Atom Version: 1.10.2
Electron Version: 0.37.8
System: Mac OS X 10.11.6
Thrown From: Atom Core
Stack Trace
Uncaught Error: Cannot read property 'object' of undefined
TypeError: Cannot read property 'object' of undefined
at ObjectsRegistry.get (/Applications/Atom.app/Contents/Resources/electron.asar/browser/objects-registry.js:44:28)
at EventEmitter. (/Applications/Atom.app/Contents/Resources/electron.asar/browser/rpc-server.js:309:31)
at emitMany (events.js:121:13)
at EventEmitter.emit (events.js:195:7)
at EventEmitter. (/Applications/Atom.app/Contents/Resources/electron.asar/browser/api/web-contents.js:141:25)
at emitTwo (events.js:100:13)
at EventEmitter.emit (events.js:185:7)
At /Applications/Atom.app/Contents/Resources/electron.asar/renderer/api/remote.js:178

Error: Cannot read property 'object' of undefined
TypeError: Cannot read property 'object' of undefined
    at ObjectsRegistry.get (/Applications/Atom.app/Contents/Resources/electron.asar/browser/objects-registry.js:44:28)
    at EventEmitter.<anonymous> (/Applications/Atom.app/Contents/Resources/electron.asar/browser/rpc-server.js:309:31)
    at emitMany (events.js:121:13)
    at EventEmitter.emit (events.js:195:7)
    at EventEmitter.<anonymous> (/Applications/Atom.app/Contents/Resources/electron.asar/browser/api/web-contents.js:141:25)
    at emitTwo (events.js:100:13)
    at EventEmitter.emit (events.js:185:7)
    at metaToValue (/Applications/Atom.app/Contents/Resources/electron.asar/renderer/api/remote.js:178:13)
    at undefined.remoteMemberFunction (/Applications/Atom.app/Contents/Resources/electron.asar/renderer/api/remote.js:112:18)
    at AtomEnvironment.module.exports.AtomEnvironment.getWindowDimensions (/Applications/Atom.app/Contents/Resources/app.asar/src/atom-environment.js:636:29)
    at AtomEnvironment.module.exports.AtomEnvironment.storeWindowDimensions (/Applications/Atom.app/Contents/Resources/app.asar/src/atom-environment.js:670:36)
    at WindowEventHandler.module.exports.WindowEventHandler.handleWindowBlur (/Applications/Atom.app/Contents/Resources/app.asar/src/window-event-handler.js:182:35)
    at /Applications/Atom.app/Contents/Resources/app.asar/src/window-event-handler.js:3:61

Commands
 18x -5:16.7.0 core:backspace (atom-text-editor.editor.is-focused)
  5x -5:07.3.0 core:save (atom-text-editor.editor.is-focused)
     -4:02.5.0 editor:consolidate-selections (atom-text-editor.editor.is-focused)
     -4:02.5.0 core:cancel (atom-text-editor.editor.is-focused)
  2x -2:39.1.0 core:paste (atom-text-editor.editor.is-focused)
  8x -2:21.2.0 core:backspace (atom-text-editor.editor.is-focused)
  4x -2:08.4.0 core:save (atom-text-editor.editor.is-focused)
     -1:59.1.0 core:backspace (atom-text-editor.editor.is-focused)
  3x -1:58.1.0 core:save (atom-text-editor.editor.is-focused)
     -1:28.4.0 core:paste (atom-text-editor.editor.is-focused)
  2x -1:28 core:save (atom-text-editor.editor.is-focused)
     -0:10.4.0 core:cut (atom-text-editor.editor.is-focused)
     -0:08.0 core:move-left (atom-text-editor.editor.is-focused)
     -0:07.8.0 core:paste (atom-text-editor.editor.is-focused)
  9x -0:06.3.0 core:backspace (atom-text-editor.editor.is-focused)
  3x -0:04.5.0 core:save (atom-text-editor.editor.is-focused)

Config
{}

Installed Packages
# User
atom-dark-syntax, v0.27.0 (inactive)
atom-dark-ui, v0.52.0 (inactive)
atom-light-syntax, v0.28.0 (inactive)
atom-light-ui, v0.44.0 (inactive)
base16-tomorrow-dark-theme, v1.1.0 (inactive)
base16-tomorrow-light-theme, v1.1.1 (inactive)
one-dark-ui, v1.5.0 (active)
one-light-ui, v1.5.0 (inactive)
one-dark-syntax, v1.3.0 (active)
one-light-syntax, v1.3.0 (inactive)
solarized-dark-syntax, v1.0.2 (inactive)
solarized-light-syntax, v1.0.2 (inactive)
about, v1.5.3 (active)
archive-view, v0.61.1 (active)
autocomplete-atom-api, v0.10.0 (active)
autocomplete-css, v0.11.2 (active)
autocomplete-html, v0.7.2 (active)
autocomplete-plus, v2.31.1 (active)
autocomplete-snippets, v1.11.0 (active)
autoflow, v0.27.0 (inactive)
autosave, v0.23.1 (active)
background-tips, v0.26.1 (active)
bookmarks, v0.41.0 (active)
bracket-matcher, v0.82.1 (active)
command-palette, v0.38.0 (inactive)
deprecation-cop, v0.54.1 (active)
dev-live-reload, v0.47.0 (active)
encoding-selector, v0.22.0 (active)
exception-reporting, v0.39.0 (active)
find-and-replace, v0.201.0 (active)
fuzzy-finder, v1.3.0 (active)
git-diff, v1.1.0 (active)
go-to-line, v0.31.0 (inactive)
grammar-selector, v0.48.1 (active)
image-view, v0.58.2 (active)
incompatible-packages, v0.26.1 (active)
keybinding-resolver, v0.35.0 (active)
line-ending-selector, v0.5.0 (active)
link, v0.31.1 (inactive)
markdown-preview, v0.158.0 (active)
metrics, v0.53.1 (active)
notifications, v0.65.0 (active)
open-on-github, v1.2.0 (inactive)
package-generator, v1.0.0 (inactive)
settings-view, v0.242.2 (active)
snippets, v1.0.2 (active)
spell-check, v0.67.1 (active)
status-bar, v1.4.1 (active)
styleguide, v0.47.0 (active)
symbols-view, v0.113.0 (inactive)
tabs, v0.100.2 (active)
timecop, v0.33.2 (active)
tree-view, v0.208.2 (active)
update-package-dependencies, v0.10.0 (active)
welcome, v0.34.0 (active)
whitespace, v0.33.0 (active)
wrap-guide, v0.38.1 (active)
language-c, v0.52.1 (active)
language-clojure, v0.21.0 (active)
language-coffee-script, v0.47.2 (active)
language-csharp, v0.12.1 (active)
language-css, v0.37.1 (active)
language-gfm, v0.88.0 (active)
language-git, v0.15.0 (active)
language-go, v0.42.1 (active)
language-html, v0.45.1 (active)
language-hyperlink, v0.16.0 (active)
language-java, v0.23.0 (active)
language-javascript, v0.119.0 (active)
language-json, v0.18.2 (active)
language-less, v0.29.5 (active)
language-make, v0.22.2 (active)
language-mustache, v0.13.0 (active)
language-objective-c, v0.15.1 (active)
language-perl, v0.35.0 (active)
language-php, v0.37.2 (active)
language-property-list, v0.8.0 (active)
language-python, v0.45.0 (active)
language-ruby, v0.69.0 (active)
language-ruby-on-rails, v0.25.0 (active)
language-sass, v0.56.0 (active)
language-shellscript, v0.22.4 (active)
language-source, v0.9.0 (active)
language-sql, v0.23.0 (active)
language-text, v0.7.1 (active)
language-todo, v0.28.0 (active)
language-toml, v0.18.0 (active)
language-xml, v0.34.9 (active)
language-yaml, v0.26.0 (active)

# Dev
No dev packages

This is a duplicate of #11692 - feel free to subscribe there for updates.


Add rotation and key sizes to layout definition

Hi, I saw your post on lemmy and noticed the included layout -- kudos for including textual layout data!
I went ahead and added rotation data based on the kicad_pcb file. I have a script to automate this but the order doesn't match up with the matrix transform order so at the moment there's some tedious work involved. Wasn't sure if the thumb keys are supposed to be 1.25 or 1.5, I just eyeballed it.

If you're not interested feel free to close this.

this is great! thank you!


"SEE ALSO" links not showing up on the Category pages

This bug got introduced in version 5.0.0-beta42 because of a change in the Categories class.
The fix will be part of the next release, Beta43

Issue fixed in "dev" branch.  It will be part of the next release, Beta43


input.value must be set as HTML attribute for default value to work

I just noticed that if I create an input DOM element and set default value from the property
let inputEl = document.createElement("input")
input.value = "#AAA"

for a default value - it would just be reset to #FFF from your lib.
But when I test with HTML
<input value="#AAA">

it works

That's correct :)

That's correct :)

I tried to put a breakpoint there and the color was set correctly, so probably something else overriding afterwards :)

Can you give the latest version a try?


Remove flake8 optional dependencies in conda recipe

The following flake8 dependencies are listed as optional for pyjwt:
flake8
flake8-import-order
pep8-naming
This PR removes the optional flake8 dependencies from the conda recipe.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Bump. I just ran into flake8 failures after installing conda-smithy (which depends on this package). Since the flake8 dependencies are only optional testing dependencies, they really shouldn't be part of this recipe. @pmlandwehr can this be merged?

Thanks for the bump. Yeah - looks like y'all are right. Just committed a tick to the build number, since the recipe is being changed, and can merge when done.


Yank for minimal-versions support

I'm hoping to make Cargo ecosystem work with -Z minimal-versions resolution. Semver 0.1 is one of the crates that breaks this.
Could you yank 0.1.x versions of semver that don't compile with Rust 1.x?
for v in `seq 0 20`; do
    cargo yank --vers 0.1.$v
done

I don't have bash, so I could not use that, but I appreciate it. I've done so by clicking the helpful buttons on crates.io: https://crates.io/crates/semver/versions
For posterity's sake, and if anyone is curious, the issue here is that semver was initially implemented for cargo, before Rust 1.0. These versions do not compile on stable Rust, because they are older than stable Rust. As such, yanking feels appropriate, and is very unlikely to break anyone.
Thank you for bringing this up!

FWIW, semver 0.1.20 did in fact build with stable Rust. Judging by the commit history maybe 0.1.19 did as well, but Rust 1.1.0 is explicitly mentioned right before the 0.1.20 release.
Some of my dependencies were still using nix 0.6 which in turn depends on 0.1.20. All of them have since been updated so this isn't a problem for me. Still maybe the yank of 0.1.20 should be undone.

Oops, indeed the last breaking version is 0.1.17. I've incorrectly assumed it were all 0.1.x.

Okay, I've un-yanked 0.1.20. If anyone really, really wants the other few versions, I'm open to it, but given that the 0.1.x series isn't even really supported at all, keeping just the final one seems fine to me.


can we have the auto-disappear notification?

Hello! I want to pop up a notification, and it will disappear automatically after a short while. Can we have this one? Thanks

@zesluo This should be the current behavior of notifications - if they don't have a button, they should disappear after a while. Are you not seeing this?


SAM-2517:MathJax cannot be rendered when the student takes the assessmen...

...t via URL

We found an issue with de anonymous tests and I'm fixing it.

Issue fixed


feature: finish OpenAI LocalModelProvider's calculatePrice() usage

I didn't find a way to get the token count for "Chat" mode (getOpenAiModelType(p.subType) == "Chat"), because completion.Usage doesn't exist. Need to figure out how to do it properly.
https://github.com/casibase/casibase/blob/6e95ad7ff55f3cc92068dc0b803b889d993a0a3d/model/local.go#L286-L292

Fixed by: https://github.com/casibase/casibase/commit/5038f69b2ba7ad1320ec603a364437d71031a91b


Got a lot of 504 lately with valid content...

Hi!
I use prerender with on the chrome branch.
Node 6.11.2
Chrome 64.0.3282.140
Prerender was working well until a couple of days. I pulled the latest version from the branch and I test my app locally.
I got 504 errors all the time, even if my page`s content is returned. You can see in the screenshot that the status in Postman is 504, but the size of the content is 54k.
The only "special" feature that I use is Firebase... but I doubt it's the reason why it does not work, because it worked well before.
I'm a bit loss and I don`t know where to look at....
Please help.
Thanks

After some debugging:
server._send = function(req, res) { 	req.prerender.statusCode = parseInt(req.prerender.statusCode) || 504; 	[...]
the req.prerender.statusCode is undefined, even if I have content... I'll continue my investigation, but if you could gove me some hints on where to check that would be appreciated.

Can you use the latest version of the master branch? We merged the chrome branch into master and already pushed out a fix on master for this issue. Or, ideally, use npm to download our latest version of prerender which uses Chrome and has the fix in it.

Hi!
It worked. Thanks... I'll look into switching to the npm package in the future.
VB

Great!


"Aușeu, Cacuciu Vechi, Codrișoru, Gheghie, Groși, Luncșoara" are villages in "Aușeu" common, "BIHOR" county

Description
Check that the locality is displayed in the search bar in accordance with Act 2 02/16/1968

Precondition
Empty the search bar after every step

Steps 1
Acces to the link https://peviitor-ro.github.io/ui.orase/
Expected result
The page opens

Steps 2
Write "Aușeu"
Expected result
In the drop down menu you find "Aușeu, BIHOR"
Test Data
Aușeu

Steps 3
Write "Cacuciu Vechi"
Expected result
In the drop down menu you find "Cacuciu Vechi, BIHOR(Aușeu)"
Test Data
Cacuciu Vechi

Steps 4
Write "Codrișoru"
Expected result
In the drop down menu you find "Codrișoru, BIHOR(Aușeu)"
Test Data
Codrișoru

Steps 5
Write "Gheghie"
Expected result
In the drop down menu you find "Gheghie, BIHOR(Aușeu)"
Test Data
Gheghie

Steps 6
Write "Groși"
Expected result
In the drop down menu you find "Groși, BIHOR(Aușeu)"
Test Data
Groși

Steps 7
Write "Luncșoara"
Expected result
In the drop down menu you find "Luncșoara, BIHOR(Aușeu)"
Test Data
Luncșoara


Support context in stateless components

const MyComponent (props, context) => ( );

etc.
Actually, I'm not even sure if we support a props argument without destructuring, check that too.

In the upcoming release, we no longer transform stateless components (the new react-hot-loader can handles them on it's own).


[DOCFIX] docs/cn/Web-Interface.md

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/17235/
Test PASSed.


This is the Pre-Loader for HealHub

https://user-images.githubusercontent.com/71378462/152600937-c6ef6b2f-ff90-40e7-9603-9d84a865f1fa.mp4

also, add the link. to the website


Add: Audit Log export

In addition to making a reader friendly export (e.g. PDF), I suggest that we also allow exporting the data as an XML file which can be used as input in the batch mode.


Satellite fetch from db

Fixed fetch. Some satellites have some messed up data for now, but our fetch function should be correct

Changed margin for the requested orbit data to be proportional to its size (instead of linear)
Added a start position for the orbit line, to make sure it starts where the satellite currently is


Version 2.0.0 not found

Version 2.0.0 not found on www.npmjs.com. Have you published the new version?

Still testing it, sorry. Will follow up this week.
On Mon, Mar 13, 2017 at 02:30 Luto Yvan<EMAIL_ADDRESS>wrote:

Version 2.0.0 not found on www.npmjs.com. Have you published the new
version?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/artefact-group/yeoman-option-or-prompt/issues/10, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAHx9LRHuw_SxfPBilgd8peA0D3vxgF6ks5rlQzLgaJpZM4MbBIJ
.

Any updates on this?

Version 2.0 is published, sorry for the wait.


Alternate spark runtime implementation

Why are these changes needed?
Related issue number (if any).
#197

I think its time to merge
It might require some additional small changes to run fuzzy, but we can work it out later


Set a strict global umask value

What would you like to be added:
umask value of 077 or minimum 027
Why is this needed:
The permissive value of 022 should not be used if possible.

Fixed with https://github.com/gardenlinux/gardenlinux/commit/460ec2923000b4ca578b23f9745a773798959052

The umask must be set to 077 and it should actually be set in the server feature, or better yet in base.
The test should be also be then moved to the proper feature.


Feature: Create image by calling compose endpoint on Image Builder

bad bad request
curl -v -H "Content-Type: application/json"  http://localhost:3000/api/edge/v1/images -d '{wrong json}'
minimum valid request
curl -v -H "Content-Type: application/json" http://localhost:3000/api/edge/v1/images -d '{"Distribution": "rhel-8", "OutputType": "tar", "Commit": {"Arch": "x86_64"}}'
with packages:
curl -v -H "Content-Type: application/json" http://localhost:3000/api/edge/v1/images -d '{"Distribution": "rhel-8", "OutputType": "tar", "Commit": {"Arch": "x86_64"}, "Packages" : [ { "name" : "vim"  }]}'
Still have to:

Write better tests

Low-priority, probably not worthy to do right now:

Perfect API Docs - We're gonna need to spend some time figuring out how to migrate to a tool that uses open api v3

@maxamillion apart from tests, this is the best i could do right now 😓
take a look, especially at the models, because I'm still not sure what goes into the image and what goes into the commit (maybe the packages have to move to the commit)

If you can make the GitHub Actions checks happy, I'm good with the PR. LGTM :+1:

@maxamillion i think we're good now! i still wanna make those tests look a little bit better but this is a blocker for the other tasks so we can do it in another PR

Merging this since Adam's on PTO and already commented that he was good with the changes :)


Fix Microsoft.Insights go/terraform 'full' package (update activityLogAlerts_API.json)

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Please ensure to add changelog with this PR by answering the following questions.

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[x] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When you are targeting to deploy new service/feature to public regions? Please provide date, or month to public if date is not available yet.
When you expect to publish swagger? Please provide date, or month to public if date is not available yet.
If it's an update to existing version,  please select SDKs of specific language and CLIs that require refresh after swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[x] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[ ] No, no need to refresh for updates in this PR

Contribution checklist:

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[ ] Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

Adding new API(s)
Adding a new API version
[ ] Ensure to copy the existing version into new directory structure for first commit (including refactoring) and then push new changes including version updates in separate commits. This is required to review the changes efficiently.
Adding a new service

[ ] Please ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in stable version
[ ] Removing properties in stable version
[ ] Removing API version(s) in stable version
[ ] Updating API in stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

@ArcturusZhang stable/2020-10-01/activityLogAlerts_API.json was released for go in Tag: package-2020-10-only.
However, in latest tag package-2021-04 there is a previous version.
This PR is for fixing go SDK, creating a new tag package-2021-07 for updating activityLogAlerts_API.json version

@ArcturusZhang is there something pending?

@ArcturusZhang @weidongxu-microsoft ping!


Create linear export for GNPS fbmn remove concurrency

Still in test. Seems like we still face concurrency problems

@SteffenHeu I think this fixes the export issue


Data Model Integrity Checks

HQDM has a lot of flexibility in how a data model is created, with none of the relationships being mandatory in the current code. This is not a problem in itself, but it raises the issue of how should HQDM be used and how can we check that the data model is not missing some required triple in the Jena database. Data Integration between databases will be easier if they all use HQDM in the same way.
One way is to implement a series of SPARQL data integrity checks that can be run against a database to check whether it complies with the guidelines agreed on by  some interested community. For example, this SPARQL query CONSTRUCTS some triples to indicate when some required triples are missing. It checks that every participant_in an association is also a member_of_kind of at least one role (the constructed triples are only in the query results, not the database):
PREFIX hqdm: <http://www.semanticweb.org/hqdm#>

construct {
  ?s hqdm:error_participant_with_no_role "Should be a member_of_kind of a role.".
  ?s a ?type.
}
where {
    ?s hqdm:participant_in ?association;
       a ?type.

    ?association a hqdm:association.

    OPTIONAL {
      ?s hqdm:member_of_kind ?kind.
      ?kind a hqdm:role.
    }

    FILTER(!bound(?kind))
}

This might need to be a separate data-integrity or data-validation module with options to run it against local or remote SPARQL endpoints or against in-memory databases as part of unit tests in core.

Theses checks were needed to get #38 working with the right test data, so they will be included in the same PR.


⚠ GitLab Server has degraded performance

In ebf1b49, GitLab Server (https://gitlab01.its-telekom.eu) experienced degraded performance:

HTTP code: 200
Response time: 14030 ms

Resolved: GitLab Server performance has improved in 1494f79.


Add e2e test for default integration test

Description
Add a test to ensure the default integration test is created automatically when a new Application is created.
https://issues.redhat.com/browse/HACBS-2193
Type of change

[ ] Feature
[ ] Bugfix
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[x] Other (please describe): e2e tests

Browser conformance:

[x] Chrome
[ ] Firefox
[ ] Safari
[ ] Edge

/ok-to-test

@subhashkhileri I believe I have address your comments :pray:

/lgtm

/approve

@subhashkhileri ready for another look!

/approve

/retest


Use External SQL Database in a nav/bc container from development purpose

Hello,
I tried to set up a connection in a container of an external SQL Database of 60gb.
i tried some script but i always the following message :
docker run -it --name sqlconnectiontest microsoft/mssql-server-windows-developer powershell -command "Invoke-Sqlcmd -ServerInstance 'localhost' -Username 'sa' -Password '{Apassword}' -Database 'test' -Query 'SELECT COUNT(*) FROM [dbo].[User]'"
Invoke-Sqlcmd : A connection was successfully established with the server, but
then an error occurred during the login process. (provider: Shared Memory
Provider, error: 0 - No process is on the other end of the pipe.)
At line:1 char:1
+ Invoke-Sqlcmd -ServerInstance 'localhost' -Username 'sa' -Password 'B ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Invoke-Sqlcmd], SqlExcept
   ion
    + FullyQualifiedErrorId : SqlExectionError,Microsoft.SqlServer.Management.
   PowerShell.GetScriptCommand

Invoke-Sqlcmd :
At line:1 char:1
+ Invoke-Sqlcmd -ServerInstance 'localhost' -Username 'sa' -Password 'B ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ParserError: (:) [Invoke-Sqlcmd], ParserExceptio
   n
    + FullyQualifiedErrorId : ExecutionFailureException,Microsoft.SqlServer.Ma
   nagement.PowerShell.GetScriptCommand

Could you tell me what is wrong in my installation ?
Thanks.

SQL Server images on Windows are very old and not something I can support here.
My recommendation is to install SQL Server on the host or a server if you want to host the database outside the NAV/BC container.

Read more about that here: https://freddysblog.com/2019/11/04/using-sql-server-on-the-host/


coredns pods not scaling > 2 ?

We can use the hack/test scripts to make clusters to test on:
 hack/test_e2e.sh -i ipv4 -b iptables

However, if i scale up the coredns replicas on these, it seems like they fail health checks:
Events:
  Type     Reason     Age                   From                                     Message
  ----     ------     ----                  ----                                     -------
  Normal   Scheduled  5m43s                 default-scheduler                        Successfully assigned kube-system/coredns-78fcd69978-x4tfv to kpng-e2e-ipv4-iptables-worker2
  Normal   Pulled     5m41s                 kubelet, kpng-e2e-ipv4-iptables-worker2  Container image "k8s.gcr.io/coredns/coredns:v1.8.4" already present on machine
  Normal   Created    5m41s                 kubelet, kpng-e2e-ipv4-iptables-worker2  Created container coredns
  Normal   Started    5m41s                 kubelet, kpng-e2e-ipv4-iptables-worker2  Started container coredns
  Warning  Unhealthy  37s (x36 over 5m40s)  kubelet, kpng-e2e-ipv4-iptables-worker2  Readiness probe failed: HTTP probe failed with statuscode: 503

Looks like this is b/c we hardcode the kuberentes apiserver kubeconfig, to only be kubernetes-control-plane or whatever
coredns-78fcd69978-p7g45                                       1/1     Running   0          21m     <IP_ADDRESS>    kpng-e2e-ipv4-iptables-control-plane   <none>           <none>
coredns-78fcd69978-pz4nq                                       1/1     Running   0          21m     <IP_ADDRESS>    kpng-e2e-ipv4-iptables-control-plane   <none>           <none>

Thus, the only kpng processes that are working, are the ones that are running on the docker node, that is named
- cluster:
    certificate-authority: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    server: https://kpng-proxy-control-plane:6443

@FriedrichWilken !!!!!!!!!!!
kpng-e2e-ipv4-iptables-control-plane
``` !!!!!!!!!!

So now, were seeing that the coredns pod seems to be infinitely waiting for the kubernetes service to come up:
[INFO] plugin/kubernetes: dns ep controller is NOT NIL
[INFO] plugin/kubernetes: svc controller: %!(EXTRA bool=false)
[INFO] plugin/kubernetes: ep controller: %!(EXTRA bool=false)
[INFO] plugin/kubernetes: pod controllertrue
[INFO] plugin/kubernetes: ns controller: %!(EXTRA bool=false)
[INFO] plugin/ready: Still waiting on: "kubernetes"
[INFO] plugin/kubernetes: dns ep controller is NOT NIL
[INFO] plugin/kubernetes: svc controller: %!(EXTRA bool=false)
[INFO] plugin/kubernetes: ep controller: %!(EXTRA bool=false)
[INFO] plugin/kubernetes: pod controllertrue
[INFO] plugin/kubernetes: ns controller: %!(EXTRA bool=false)
[INFO] plugin/ready: Still waiting on: "kubernetes"

Now, trying to figure out wether waiting on kubernetes means:

cant route to the apiserver?
cant get certain endpoints from the apiserver?

So filed https://github.com/coredns/coredns/issues/5035 to ask the coredns folks out of curiosity, how to determine what "specific" part of the kubernetes plugin is complaining.
...


Support Django 4.0 and 3.2 and drop previous Django versions

This pull request uses #17 as a base (thanks @johnthagen) but also includes Django 4 support. It also removes support for Django 3.0 and 3.1 as they are EOL. The lint error B023 is ignored since it was causing issues with circleci through the TestSerializer class declared in a loop.

@lvoytek Given we have not heard back from @rpkilby in a while (#19), we may need to fork this project and push under a new name to PyPI

@johnthagen  That's fair. I figured I might as well send in a pr in case we ever hear back.

As the maintainer has not responded in a year, I created a friendly fork that tests against the latest Python and Django versions

https://pypi.org/project/djangorestframework-guardian2/

It incorporates many of the changes in this PR.


Package request: phantun

Project description
A lightweight and fast UDP to TCP obfuscator.
Metadata

homepage URL: https://github.com/dndx/phantun
source URL: https://github.com/dndx/phantun
license: mit, apache
platforms: unix, linux, darwin

Note for maintainers: Please tag this issue in your PR.

Add a :+1: reaction to issues you find important.

Would be good to wait for https://github.com/dndx/phantun/issues/138 to be resolved first


adding file input for custom upload

This PR brings in the file input and displays an image on the canvas as expected
Screen Recording:
https://cloudapp.loganarnett.com/4guJQEKR

#4 Solved via this pull request!


Bandwidth management

Hi,
Using C++ server with uWebsockets on windows (VS2015), I have an issue when users have a low bandwidth. The messageQueue increases until the process reaches the memory limit (2Go on Windows 7).
How to control the messageQueue length, or size in bytes, to stop sending data to clients when the bandwidth isn't good enough ? I didn't find a way to solve this using the callback on WebSocket::send.
How to reproduce:

Declare a uWebsocket server (with SSL in my case)
Connect a User on it
Send more than 100 ko/s of data to the client (WebSocket::send)
Set a bandwidth limit of 5 ko/s on the client websocket (using NetLimiter for example)
Monitor messageQueue or memory use of uWebsocket server

Best regards,
Guillaume

Ok I solved it by doing something similar to this:
Monitoring::getInstance()->m_size += msg.length();
ws.send(msg.c_str(), msg.length(), uWS::OpCode::TEXT, [](void* webSocket, void* data, bool cancelled, void* reserved)
{
    if (data)
    {
        Monitoring::getInstance()->m_size -= (unsigned int)data;
    }
}, (void*)msg.length());

Then I can control Monitoring::getInstance()->m_size any time I want to check if my clients are saturated.
It's not very sexy but effective. If you have a better solution feel free to tell me.
Regards,
Guillaume


Problem with escapes in links

I have as input: [link](\(foo\)) (see http://spec.commonmark.org/0.27/#example-464).
In my visit(Link node) the reference text I get is \(foo\)which means that the escapes are not processed. Thus when I render this in HTML I get: ... instead of ....
Would be nice if flexmark-java could process the escapes and have a way in a Link object to get the processed reference.
WDYT?

@vmassol, it is a bug, same as was in wiki links. It is a left over from changing from escape processing during parsing in commonmark-java to source based AST which keeps escapes as is to have source matching. I'll fix it and make a release with the accumulated fixes.

ok great, thanks!

@vmassol, just checked and the rendering of link does do escape correctly. So what you are referring to is links in the AST. Which is correct since the AST has source based text which includes all escapes.
What you need to do to get unescaped content is to apply the unescape() method on the BasedSequence.
All the text in the AST is source based so you can get the offset into original source via:

BasedSequence.getStartOffset()
BasedSequence.getEndOffset()
BasedSequence.getSourceRange()
BasedSequence.getIndexOffset(int)

This means that the string represents sub-sequence of the original source.

hmmm ok will test.

Ok just tested and it works.
BTW other question: is there some escape utility class that I can reuse in my Renderer to escape characters depending on the context (whether I'm in a link reference, link label, etc)?
Thanks

@vmassol, take a look at CoreNodeRenderer for all the unescaping that it does before rendering and the Escaping class used for all kinds of input conditioning such as normalizing EOL, unescaping, escaping, url encoding and decoding.
The best examples or usage are in the core code and in the extensions.

Closing since it's woking fine.


Loggin stopped with API timeout

Describe the bug
I've used teslamate 10 months. But it can't aggregate logs from tesla anymore. I think it stopped 4~5 days ago when I upgraded my tesla model 3 to 2020.36.10 I guess. After that, teslamate cannot aggregate logs from my tesla. I guess it but, I don't know the exact timing because I don't drive my car every day.
There was a status error on my teslamate dashboard. So, as the document, I inserted new tokens and delete an old token in DB. After that, I can't sign-in again.
Expected behavior

How to reproduce it (as minimally and precisely as possible):
I don't know why.

Relevant entries from the logs
teslamate_1  | 16:55:35.314 [info] GET /sign_in
teslamate_1  | 16:55:35.317 [info] Sent 200 in 3ms
teslamate_1  | 17:00:06.132 [info] GET /sign_in
teslamate_1  | 17:00:06.136 [info] Sent 200 in 3ms
teslamate_1  | 17:01:01.858 [info] Elixir.TeslaMate.Api / unhandled message: {#Reference<0.1210462020.1935409153.218839>,
teslamate_1  |  {:error, %Mint.TransportError{reason: :timeout}}}
teslamate_1  | 17:01:06.861 [info] Elixir.TeslaMate.Api / unhandled message: {#Reference<0.1210462020.1935409153.218871>,
teslamate_1  |  {:error, %Mint.TransportError{reason: :timeout}}}

Screenshots

I hide my personal information. ID/password is correct.
Environment

TeslaMate version: 1.19.4
Type of installation: Docker
OS TeslaMate is installed on: Ubuntu 18.04
User OS & Browser: Chrome

I believe it is because tesla block request from AWS and GCP.
https://teslamotorsclub.com/tmc/threads/teslafi-and-other-aws-and-gcp-clients-currently-blocked-access-to-tesla-api.206245/
It's running on AWS.


Implement a watch-dog mechanism which can kill runaway extension host processes

In certain circumstances, e.g. extension that does while (true) loop, the extension host process will not terminate unless killed via task manager.
Implement a watch-dog mechanism that can kill runaway extension host processes.
NB: This was not an issue on Windows until we made the process be forked with the detached  option to allow 5s for the extensions to gracefully shut down.

An idea would be to:

write a nodejs native addon
it installs an interval timer on the JS event loop
at each execution of the timer, a call is made to C++ land to let it know the JS event loop is alive
create a thread that sleeps for ~20s
when the thread wakes up, it checks the last time the JS event loop was alive

API: http://docs.libuv.org/en/v1.x/threading.html

Cool idea. Will avoid having yet another process running.

Can this also detect how much % CPU the process is using, give a notification which process is long-running, and give the user the option of restarting/killing it? That way you would also expose potentially problematic extensions?

Well, we'd want the JS stack trace, not the C++ one (otherwise we'd just see v8 being in the stack).
That appears to be difficult from the discussion in https://github.com/nodejs/node-v0.x-archive/issues/25263

Due to instability (increased number of crashes), the watch-dog code is now disabled -- starting with today's Insiders Build (2017-08-23). We have also upgraded to Electron 1.7.4 and 1.7.5 and we should be cautious of introducing too much instability at once.

Re-iterating thoughts expressed by @sjelfull . I've been suffering from high cpu on an rMBP and can't figure out which extension is causing this.
This is overly tough to diagnose: whenever I launch developer tools, it seems the problem goes away...literally, I launch the tools and the fans start to calm down, eventually turning off completely. Makes no sense. Because I have no idea what's causing it, I can't try to repro. The problem just seems to randomly appear.
Having some sort of automated way to identify problematic extensions would be extremely helpful, perhaps more so than just quietly killing them.

This has been implemented now on master.

Adding verification needed, but this probably needs some test plan input and testing across OS (cc @mjbvz).

I created https://github.com/Microsoft/vscode/issues/59303