Analysis server does not watch files in unversioned dependencies that are not part of the analysis roots

Filing here at the request of @DanTup -- https://github.com/Dart-Code/Dart-Code/issues/4725
In pubspec.yaml, it is possible to depend upon unversioned projects by path, e.g.:
dependencies:
  serverpod_client:
    path: ../vendor/serverpod/packages/serverpod_client

The files in a dependency like this are not monitored for changes by Dart-Code. Consequently, whenever you make changes in the dependency project, you have to go Ctrl+Shift+P > "Developer: Reload Window" and then wait for all the dependencies to be scanned.
All depended-upon files in path: dependencies should be watched for changes, just like files in the main project.

Dart version and tooling diagnostic info (dart info)

$ dart info

If providing this information as part of reporting a bug, please review the information
below to ensure it only contains things you're comfortable posting publicly.

#### General info

- Dart 3.1.0 (stable) (Tue Aug 15 21:33:36 2023 +0000) on "linux_x64"
- on linux / Linux 6.4.12-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Aug 23 17:46:49 UTC 2023
- locale is en_US.utf8

#### Process info

|  Memory |  CPU | Elapsed time | Command line                                                                               |
| ------: | ---: | -----------: | ------------------------------------------------------------------------------------------ |
|  438 MB | 3.2% |        06:37 | dart --enable-vm-service=0 --pause_isolates_on_start --disable-dart-dev -DSILENT_VM_SERVICE=true --write-service-info=file:<path>/vm.json --pause_isolates_on_exit --enable-asserts <path>/main.dart |
|   88 MB | 0.2% |        06:37 | dart debug_adapter                                                                         |
|   72 MB | 0.0% |  17-01:27:10 | dart devtools --machine --try-ports 10 --allow-embedding                                   |
|   77 MB | 0.0% |  17-01:26:51 | dart devtools --machine --try-ports 10 --allow-embedding                                   |
|   77 MB | 0.0% |  17-00:57:44 | dart devtools --machine --try-ports 10 --allow-embedding                                   |
|   77 MB | 0.0% |  15-21:52:39 | dart devtools --machine --try-ports 10 --allow-embedding                                   |
|   76 MB | 0.0% |     03:45:29 | dart devtools --machine --try-ports 10 --allow-embedding                                   |
| 1053 MB | 1.0% |     03:45:29 | dart language-server --protocol=lsp --client-id=VS-Code --client-version=3.72.2            |
|  411 MB | 1.5% |        06:55 | dart language-server --protocol=lsp --client-id=VS-Code --client-version=3.72.2            |
|  103 MB | 0.1% |     03:45:29 | flutter_tools.snapshot daemon                                                              |
|  676 MB | 0.4% |        31:06 | flutter_tools.snapshot run --machine --start-paused -d emulator-5554 --devtools-server-address http:<path>/ --target lib/main.dart |
|  726 MB | 0.3% |        31:05 | frontend_server.dart.snapshot --sdk-root <path>/ --incremental --target=flutter --experimental-emit-debug-metadata -DFLUTTER_WEB_AUTO_DETECT=true -DFLUTTER_WEB_CANVASKIT_URL=https:<path>/ --output-dill <path>/app.dill --packages <path>/package_config.json -Ddart.vm.profile=false -Ddart.vm.product=false --enable-asserts --track-widget-creation --filesystem-scheme org-dartlang-root --initialize-from-dill build/204ea416f1812abf3cc545dddda97605.cache.dill.track.dill --source file:<path>/dart_plugin_registrant.dart --source package:flutter<path>/dart_plugin_registrant.dart -Dflutter.dart_plugin_registrant=file:<path>/dart_plugin_registrant.dart --verbosity=error --enable-experiment=alternative-invalidation-strategy |

Whether you are using Windows, macOS, or Linux (if applicable)

Linux

Whether you are using Chrome, Safari, Firefox, Edge (if applicable)

N/A

@bwilkerson I thought this had come up before but I couldn't find any issues.
I think the server only watches files inside analysis roots (or with overlays), so if you have a path dependency that isn't open in the workspace and you edit it outside of this server, the changes will not be noticed.
My recommendation for VS Code users is generally to have a single window with both sets of code open rather than having two different windows that overlap (which avoids this issue and avoids having multiple servers analyzing some of the same content). I don't know if there are good reasons not to do this though (@lukehutch I'm curious to know your reasons for using two windows), or whether that's alone is a reason this shouldn't be supported.
If this was supported, there's a question about whether it should only be for path dependencies, or if the folders in pubcache should be watched too (my feeling is that those should be immutable and would result in a lot of watchers, although it feels slightly inconsistent for one to be watched and not the other).

We shouldn't need to watch the files in the pub cache, as you noted they're intended to be treated as read-only. And we don't need to know about new directories being added until they're actually referenced from a package_config.json file.
The analysis server currently treats any files outside of the analysis roots as similarly being read-only. I'm not sure how difficult or expensive it would be to change that, though at the moment I don't think server has any special knowledge of the pub cache, and it might need to in order to support this.
@lukehutch I have a question to add to Danny's: Are these two (or more) directories part of a monorepo (in the sense of a directory containing two or more packages that are always expected to be kept in sync, versioned together, etc.)?

@lukehutch

@DanTup I don't like the two window solution because

I may have misunderstood something - my suggestion is to not use two windows. My understanding was that you had a project open in VS Code and were editing some files (that its projects referenced via a path dependency and not in the workspace) outside of that VS Code window (which I assumed, was in a second VS Code window).
If you're not using two windows, can you clarify how the files which aren't in the workspace are being edited (and why you don't want to add that project to the same VS Code window). Thanks!

I am using Serverpod, and it generates client code from the definition of endpoints in a separate server project (which I do have open in another window, yes, but I am not directly editing the generated client code).

Ah, gotcha. Whether the code is modified by a tool or manually in the other window doesn't change a lot here though. I guess my question is really why you don't add the server project to the original VS Code window. If you did this, it would automatically be watched (and it would reduce your resources because you don't need a second analysis server for that other VS Code window).
If the reason for this is that some things don't work correctly when you have them in the same workspace/window, I'd be very interested in knowing what those things are. If it's just that you want the code on another monitor or something, then I don't have a good reply to that currently 🙃

Honestly the reason is that I didn't even know it was possible to have two projects open in the same window! I thought the analysis root was defined by the directory you open VS Code in.
It sounds like I have a solution for my usecase (I'll try it out sometime today). I don't know whether it is worth pursuing further the request to automatically analyze unversioned dependencies, but that seems potentially worthwhile.

Honestly the reason is that I didn't even know it was possible to have two projects open in the same window! I thought the analysis root was defined by the directory you open VS Code in.

Early on, it was the case that VS Code could only open a single folder. It has been supported for some time though - they called it Multi-root Workspaces.
You can use File -> Add Folder to Workspace to add multiple, or multi-select folders from the Open Folder dialog (although they have to be siblings to do that).
When you have multiple folders open, you can click File -> Save Workspace As to save a .code-workspace file. That file can contain not only a set of folders to open, but also workspace settings and launch configurations. I use this quite a lot when working in the Dart SDK so I can have just the relevant folders open, and have settings and launch configurations that suit me without having to commit them to the repository (or ignore them).
Please let us know how it feels when you try it out. While it would be nice to support what's requested here, if the most common reason to hit this issue is just not knowing that you can have multiple folders in a workspace, it might be better to try and improve discoverability or documentation of that instead (because it will reduce overall resource use by not having two analysis servers analyzing the same code).

@DanTup OK, so this is hilarious, but when I was reading your instructions, I was thinking "What platform is he talking about? There's no File menu on Linux"...
Turns out there is in fact a menu bar, and I have never even noticed it was there...
I think my brain just saw the menu bar as window chrome, and ignored it, especially since I'm using a dark theme, and the menu bar is light (doesn't match the theme).
As far as the docs, the docs are really good and really clear already, but I confess I have never gone and read the manual for VS Code. I suspect this is true for a lot of people. We want to figure it out as we go, without reading anything, and everything should be obvious.
Now that I tried multi-root workspaces, all my problems are solved. I added the flutter, client, and server projects to a single workspace, started the Serverpod commandline generator tool in watch mode, and now changes I make actually affect all the projects at once, just as I needed.
So the final effect of enabling this is to make me realize that basically I was asking for something that already existed, although I asked for this sort of dependency tracking to be automatic, based on the unversioned dependencies of the project.
Maybe then what could be done is that if you add an unversioned dependency to the project, the project will be added to your multi-root workspace?
There are two changes I would love to see to how multi-root workspaces work:

Currently you have to do code myproject.code-workspace, not code ., to open the multi-root workspace. I would strongly prefer VS Code to save multi-workspace information to .vscode/settings.json rather than to a separate file like this, so that typing code . would open the project with its previous state, whether that is single-root or multi-root. Currently that's how single-root projects work -- the exact state of the editor is restored when you open the same directory. This is not the case for multi-root workspaces.
It's also a pain to have to manually save the myproject.code-workspace file, including deciding where to save it. I would like to see the saving of this file to happen automatically too -- either by saving the info to .vscode/settings.json as recommended above, or by automatically saving the file to .vscode/project.code-workspace or similar.

So basically neither the loading nor the saving of .code-workspace files should be manual.

Other issues I'm discovering with having multiple projects open:
(1) Launch configurations are listed in a per-project list:

however, these attempt to run the main method only from the project where you most recently opened a Dart file.
(2) Setting breakpoints no longer works properly with multiple projects open. The breakpoints are showing as unverified:

Maybe then what could be done is that if you add an unversioned dependency to the project, the project will be added to your multi-root workspace?

Adding the folder directly is a bit disruptive (it could trigger a full extension host restart) so I don't think we should do it automatically, but we could perhaps prompt ("Your workspace projects contain path dependencies, add them to the workspace?"). The only niggle is is once you create a multi-root workspace, you're prompted to save it when you close, and this might also feel a little odd.
Still, if you file an issue for this at https://github.com/Dart-Code/Dart-Code, we can let it collect 👍 's to see if there's interest in it.

Currently you have to do code myproject.code-workspace, not code ., to open the multi-root workspace.

If you put your .code-workspace file inside the folder, VS Code does prompt ("Did you want to open the code-workspace?") when you open the folder. But I agree this isn't perfect (esp. if you don't want to commit it). I have a terminal alias c to open VS Code for the current directory and have some special cases because of this in my PowerShell profile:
function x-c($path)  {
	# Special-case folders where we want to open workspaces...
	if ($PWD.Path -eq "C:\Dev\Google\devtools") {
		$path ??= "C:\Dev\Code Workspaces\DevTools.code-workspace"
	}
	# ... (snip) ...

	$path ??= "."
	code $path
};
Set-Alias c   x-c

While not ideal, you might be able to do something similar for bash.

I would strongly prefer VS Code to save multi-workspace information to .vscode/settings.json rather than to a separate file like this

How this works is all controlled by VS Code and not something we can influence, but I agree it'd be nice if there was an option to do this more easily. Note that there doesn't have to be a 1:1 mapping from folders to workspaces though - I have multiple code-workspace files for the same repos where I might work on different sets of packages.

It's also a pain to have to manually save the myproject.code-workspace file, including deciding where to save it. I would like to see the saving of this file to happen automatically too

I agree this could probably be more seamless with the concept of a default/preferred workspace for a folder. Again, it'd need to be built into VS Code though. FWIW I have a "Code Workspaces" folder which I have pinned to my favourites in the explorer window:

Again it's not perfect, but it works well for me (and keeps these files outside of the repos, since they contain launch configs and settings that might be specific to me that others aren't interested in).

(1) Launch configurations are listed in a per-project list:
however, these attempt to run the main method only from the project where you most recently opened a Dart file, not from the project selected in the list (click_flutter or click_server).

This sounds like a bug - could you file at https://github.com/Dart-Code/Dart-Code and I'll take a look?

(2) Setting breakpoints no longer works properly with multiple projects open. The breakpoints are showing as unverified:

Are you sure this is related to multiple projects? There are some known issues about breakpoints appearing as unresolved until right before they're executed (because when using the new debug adapters, we support proper resolution but the VM only resolves them right before they execute them). There's an open issue about that at https://github.com/Dart-Code/Dart-Code/issues/4734. If that doesn't match what you're seeing, please open an additional Dart-Code issue and we can debug.
Thanks!

If you put your .code-workspace file inside the folder, VS Code does prompt ("Did you want to open the code-workspace?") when you open the folder.

I don't see that behavior on my end. I have a myproject.code-workspace file in the current directory, but if I run code ., I am not asked if I want to open the workspace. I have to manually open it with code myproject.code-workspace to open the workspace.

I don't see that behavior on my end. I have a myproject.code-workspace file in the current directory, but if I run code ., I am not asked if I want to open the workspace. I have to manually open it with code myproject.code-workspace to open the workspace.

That seems to be reported at https://github.com/microsoft/vscode/issues/185423 and based on https://github.com/microsoft/vscode/issues/125315#issuecomment-855584260 is apparently deliberate - the notification only shows the very first time and is otherwise hidden in the bell.

Let me first check -- the behavior I'm seeing is that when I hit F5 (Run), the first time I try to run a project, I have to run from the Dart file containing main. Otherwise, the run configuration json file is opened by VS Code. After successfully running once, usually (but not always?) if I have some Dart file open, hitting F5 runs the same main function.

I'm not sure if I complete understand the steps (so an issue with exact steps to repro might help), but the way this should work is:

You press F5 with a Dart file open
VS Code reads the current entry from launch.json (if it exists) and passes that to us
If there is a program specified in that launch config (which there won't be if one isn't defined in the launch config, or there was no launch config) we will run that
Otherwise, we will try to infer what we should run

If your open file looks runnable (eg. it's inside bin/, tool/, test/ or at lib/main.dart) then we will try to run that
Otherwise, we will try to locate the project containing the open file and then look in some well-known locations (lib/main.dart, bin/main.dart) to see if we can find a likely entry point there.

If you have a non-dart file open and press F5:

VS Code will check if you have a launch configuration selected and if so run that
If not, it will try to find a debugger for the active file

Since Dart does not register a debugger for YAML, this will probably fail and ask you to create a launch config

So the way to ensure that pressing F5 always runs your app is to ensure you have a launch configuration (and it is selected) that has a program field that points to a Dart script. If this doesn't work, please provide a small sample project and instructions so I can investigate.

Breakpoints appear to be more commonly unconfirmed for code that is outside the current workspace, i.e. in dependencies

I'm not aware of any issues that would cause these to behave differently - if you have good steps/an example to repro this, please file an additional issue for me to look at. Thanks!

Getting back to this issue, @lukehutch wrote

In Dart, the equivalent of package_config.json is pubspec.yaml, and it is very easy to detect unversioned (potentially read/write) projects: they are included as dependencies by path, not by package/version, and not by git URL.

So what I'm proposing is that the analyzer detect these situations, and set up multiple analysis roots in one project.

@bwilkerson @scheglov do you have thoughts here? I think I've been running into this while developing an analyzer plugin, referenced as a path dependency. Can we just watch the path of a non-versioned dependency, or do we need to add another analysis root, an analysis context...?

I can't think of any reason why it would be a problem for server to watch non-versioned dependencies, whether they're introduced as a path dependency directly or as a path-based dependency override.
I don't think we want to create a separate analysis context for such dependencies, though. That would add too much overhead and probably cause UX problems that we don't need to introduce.

We also encountered a similar issue in Android Studio. Here is my development environment:
IDE environment:
Android Studio Giraffe | 2022.3.1 Patch 1
Build #AI-223.8836.35.2231.10671973, built on August 17, 2023

Runtime version: 17.0.6+0-17.0.6b829.9-10027231 x86_64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.

Flutter environment
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.10.0, on macOS 14.1.1 23B81 darwin-x64, locale zh-Hans-US)
[!] Android toolchain - develop for Android devices (Android SDK version 33.0.1)
    ✗ Android license status unknown.
      Run `flutter doctor --android-licenses` to accept the SDK licenses.
      See https://flutter.dev/docs/get-started/install/macos#android-setup for more details.
[✓] Xcode - develop for iOS and macOS (Xcode 14.2)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2021.3)
[✓] Android Studio (version 2022.3)
[✓] IntelliJ IDEA Ultimate Edition (version 2021.2.4)
[✓] VS Code (version 1.78.0)
[✓] Connected device (2 available)

Android Studio plugins version:

Flutter: 77.1.1
Dart:    223.8977

We have a Flutter application that depends on a component called foo.
name: flutter_app_sample

...

dependencies:
 foo: 1.0.0

When we develop the component foo, in order to open only one IDE(Android Studio), we will rewrite the dependency to change the remote dependency to a local path dependency.
name: flutter_app_sample

...

dependencies:
 foo: 1.0.0

dependency_overrides:
 foo:
  path: /Users/franticn/Projects/Samples/foo

Then run flutter pub get. Later, we can see the locally dependent foo in the External Libraries in Android Studio.

Since it is a local dependency, it is unversioned. So we can directly develop the code of flutter_app_sample and foo in one project.
However, for foo, Dart Analysis is disabled for it. Editing the files directly in one IDE window in the above way will result in no code completion and reminders, but executing the command dart analyze in the directory where foo is located is possible.

At the same time, checking the checkbox Scope analysis to current package in Dart Analysis Server Settings does not work either.

In my understanding, Scope analysis to current package is for this scenario?
I think this development method is also quite common, maybe. However, there is no good way to support it. Therefore, I submitted this comment in the hope of getting help from everyone.

@lukehutch

@DanTup I don't like the two window solution because

I may have misunderstood something - my suggestion is to not use two windows. My understanding was that you had a project open in VS Code and were editing some files (that its projects referenced via a path dependency and not in the workspace) outside of that VS Code window (which I assumed, was in a second VS Code window).
If you're not using two windows, can you clarify how the files which aren't in the workspace are being edited (and why you don't want to add that project to the same VS Code window). Thanks!

To address the question of "how the files which aren't in the workspace are being edited", if you depend on a component through a local dependency in VS Code, you can find your component in the VS Code EXPLORER -> DEPENDENCIES -> transitive dependencies after running pub get. However, Dart Analysis also does not work.

To address the question of "how the files which aren't in the workspace are being edited", if you depend on a component through a local dependency in VS Code, you can find your component in the VS Code EXPLORER -> DEPENDENCIES -> transitive dependencies after running pub get. However, Dart Analysis also does not work.

Got it, thanks. If you're going to be modifying files from a path dependency like this, I would recommend adding them to the workspace (File -> Add Folder to Workspace). There are many differences between dependencies that are just discovered as dependencies and folders that are explicitly in the workspace (for example when debugging, packages inside the workspace are considered "my code" and dependencies not inside the workspace are considered "external packages") and implementing the change requested here won't change all of those.


dnm: dummy

Depends-on: github.com/kata-containers/packaging/491
Fixes: #490
Signed-off-by: Eric Ernst<EMAIL_ADDRESS>

/test

/test

/test

/test

ARM is failing with qemu checkout failing cause of changed files and q35 is failing with the network_ns failure which are both consistent and i believe have patches en route to fix them both.


Add Lolex Car from Kerbal Stuff

This pull request was automatically generated by Kerbal Stuff on behalf of rdk, to add Lolex Car to CKAN.
Please direct questions about this pull request to rdk.

@techman83:
Jenkins fails with
[ERROR] FATAL UNHANDLED EXCEPTION: CKAN.FileNotFoundKraken: Could not find LolexCar directory in zipfile to install but reports success.

Refer KSP-CKAN/CKAN#1273


Missing readiness probe for GKE/Ingress integration

Description
We want to use BotKube with MS Teams integration. We do have an existing K8s cluster running on GKE, and we want to expose the BotKube API over an existing GKE Ingress instance. However, GKE Ingress seems to require an HTTP Probe returning 200 for Ingress backend readiness check. Unfortunately, we cannot find a documentation or way to use the BotKube container for that purpose,
Expected behavior
The BotKube container provides a readiness probe that can also be used for Ingress backend healthchecks.
Actual behavior
There seems to be no probe in the current BotKube container image,

Hi @mirkosertic
You are right. I checked and we don't have any healthcheck endpoint exposed from Botkube container.
I see two options:

add global healthcheck e.g. {host}:{botkube_port}/healthz so we can also utilize that on liveness probe for Botkube itself.
add a dedicated MS Teams healthcheck e.g. {host}:{ms_teams_port}/bots/teams/heathcheck
@pkosiec any thoughs?

We will try to incorporate that into the current release to make it available as soon as possible.

Summary after dev-team meeting:

Introduce Botkube healthz endpoint that returns the 200 (OK).
Later we will maybe return JSON with information about Botkube core health

and enabled plugins (after https://github.com/kubeshop/botkube/issues/878)
and communications platform status (is it possible?)


tmt-reboot: Add efibootmgr configuration and option to disable it

Some UEFI systems that has efibootmgr installed need BootNext to be set BootCurrent before reboot.
efibootmgr configuration could be a default step in tmt-reboot and provide a full compatibility with rstrnt-reboot
But sometime, for example for kexec testing, a soft reboot is necessary.
An updated tmt-reboot could provide both reboot options:

Configure efibootmgr before reboot by default
Option to disable efibootmgr configuration when necessary

[1] https://restraint.readthedocs.io/en/latest/commands.html#rstrnt-prepare-reboot
https://github.com/restraint-harness/restraint/blob/master/scripts/rstrnt-prepare-reboot

Seems this is a priority for the Kernel team, let's try to find somebody who could implement it. Testing Farm team can provide an UEFI enabled machine if that would help with testing (or a Beaker machine can be used)

@juk suggested that as for now it's not necessary to add a new script rstrnt-prepare-reboot. The functionality could be added directly to tmt-reboot (and its aliases) with option which would disable the efibootmgr adjustments. @pfdaly, would you be interested in implemeting this?

I'll give it a quick read through now with the intention to start implementing something on Monday.

Note that the current implementation of the functionality in Restraint scripts is harmful: https://github.com/restraint-harness/restraint/pull/260

Thanks for sharing the link! From the discussion in the above-mentioned issue, @pcahyna, @juk, do you have any specific recommendation about the way how we should approach it in tmt implementation?

Hi, I am from kernel QE team and my team is responsible for testing kdump/crash related functionalities. Thanks @juk raising the request for tmt-reboot enhancement. This is what we need in kexec test.
I am kinds of lost in the discussion of rstrnt-prepare-reboot and rstrnt-reboot in https://github.com/restraint-harness/restraint/pull/260. It seems the issue reporter tried to fix is the timeout of efibootmgr - to make sure efibootmgr nextboot configure doesn't expirer before system fully shut down and reboot. I guess it doesn't conflict with this ticket no matter https://github.com/restraint-harness/restraint/pull/260 is implemented or not.
restrnt-reboot performs a regular boot. Due to Beaker constraints on UEFI system, in order to perform a regular boot, the efibootmgr Nextboot option must be set to a disk boot (the value taken from current boot), otherwise the next boot is always a network boot which would cause the Beaker UEFI system to re-install from a PXE boot - it will break a Beaker test unexpectedly. The setting of efibootmgr nextboot is always a part of restrnt-reboot command. What rstrnt-prepare-reboot does is to abstract the efibootmrg -n implementation to a separate function/script. So the user could choose either

to run rstrnt-prepare-reboot independently to set efi next boot for preparing a panic test,
or to run restrnt-reboot which always call rstrnt-prepare-reboot so Beaker UEFI system could perform a regular boot instead of going to pxe boot installation unexpectedly.

The request in this issue for a third scenario: kexec boot.
kexec boot is a regular reboot command called after kexec -l command (This is not a panic test). It will kexec boot to another kernel without going through the regular bios boot process. So if 'restrnt-reboot' is called and efi nextboot set to disk, it will not take affect in the kexec boot, but in the task/jobs run after the kexec boot test. So for kexec boot test, we will run "reboot" (not restrnt-reboot) explicitly to make sure a kexec boot is performed without interrupting any job/tasks run afterwards on the system.
When it comes to running kexec/panic tests in tmt environement. tmt guide says rstrnt-reboot is backward compatible in tmt (i.e. rstrnt-reboot = tmt-reboot). So we hope tmt could provide

rstrnt-reboot/tmt-reboot exactly same in restraint or in tmt environment - That is, efibootmgr nextboot is configured to allow Beaker UEFI system to perform a regular boot.
rstrnt-reboot support an option to leave efibootmgr nextboot as it is. Currently kexec -l xxx && reboot doesn't work in tmt, it would lost connection to the test machine.

@psss as @emmawu mentioned https://github.com/restraint-harness/restraint/pull/260 is not a concern at the moment.
If necessary it could be address later once enhancement to configure efibootmgr nextboot is in-place.

@pfdaly hi, so are you working on this?

@pfdaly promised to resume work on this soon.
thanks for clarification @juk and @emmawu

@emmawu Could you please review https://github.com/teemtee/tmt/pull/1506/commits/4e40d0e94cc6d1f97081f9200f65353df291fc07#diff-a9d33e5ac8c84b8e638d87df49f589692e4271162fc04fc5bbd45b93b2d8d55aR29
Noticed that "efi" option is disabled by default. @emmawu would it work for you?
So to configure nextboot you would need to enable "efi" option each time you do tmt-reboot.

@juk,  Thanks. The change looks good to me. Then with this change, running tmt-reboot with option '-e', it will not update the efi BootNext.

It seems the issue reporter tried to fix is the timeout of efibootmgr - to make sure efibootmgr nextboot configure doesn't expirer before system fully shut down and reboot. I guess it doesn't conflict with this ticket (...)

No, it does not conflict with this ticket, but it would be good to not reintroduce the same problem.


Add arm build to travis

We keep seeing regressions on ARM.  It's necessary we start building there or we're going to continue to see last-minute issues on that platform when we try to cut a release.  Need the following before this build will pass:

[x] travis-ci/apt-package-whitelist#802
[ ] travis-ci/apt-package-whitelist#850
[ ] travis-ci/apt-package-whitelist#882
[x] travis-ci/apt-package-whitelist#851
[ ] 3x (arm, linux, mac) multi-platform build configured

Looks like this image needs to run sudo apt-get -y install g++-arm-linux-gnueabihf

The above links seem to be about adding gcc-4.9-base in Travis whitelists? It seems like a gcc 4.9 upgrade would be independent (or rather complicate things) for supporting ARM cross-compiling.
It should be fine to use version 4.6 of arm-linux-gnueabihf-g++.
When it later comes to Android, we will need gcc 4.8 or newer as the STL support in NDK fall further behind, but ARM Linux should be fine on the same gcc we use for x86 Linux.

Unfortunately we can't use sudo because we are using containerized builds on Travis.  I'd much rather get them to add this package to the whitelist than switch back to the legacy build system.

Ahh I see travis-ci/apt-package-whitelist#846 is for cpp-4.9-arm-linux-gnueabi

Closing this as this is unlikely to ever happen in a billion goddamn years.


Configure flake8-docstring

The travis is failing, but is this some kind of setup problem with travis?

Travis is failing for another reason. We should try to fix that first before we merge this PR.

Ok. At our meeting.
On Wed, Nov 11, 2020 at 1:20 PM Chris Timperley<EMAIL_ADDRESS>wrote:

Travis is failing for another reason. We should try to fix that first
before we merge this PR.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ChrisTimperley/roswire/pull/437#issuecomment-725047529,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA7X6AESQHJV3B2SKMTUIMLSPHKFPANCNFSM4TQ3O5JQ
.

This posted one day ago. https://travis-ci.community/t/cant-deploy-to-pypi-anymore-pkg-resources-contextualversionconflict-importlib-metadata-0-18/10494/9


[Feature Request]: Allow change of primary key

Package
lucia-auth
Describe the problem
First of all, thank you to pilcrowOnPaper and all contributors for this amazing auth library. It has been a pleasure working with it and I truly appreciate your work.
However, as I was trying to implement the oauth functionality, I noticed something in the docs:
"Primary keys cannot be created using createKey()."
While the intention is good, I don't think it should be impossible to create a different primary key in case you lose access to your oauth account and I want my users to be able to sign up quickly using google, github or another oauth provider. and later switch to a "stand-alone" account in case they lose access / don't want to use that provider anymore.
Describe the proposed solution
My solution would be:
Add a function auth.setPrimaryKey(userId: string, providerId: string) which changes the primary key to a different existing key.
Alternatives considered
When creating an account using an oauth provider:
const { existingUser, providerUser } = await discordAuth.validateCallback(code);
    const user = existingUser ?? await auth.createUser({
      primaryKey: {
        providerId: 'username',
        providerUserId: providerUser.username,
        password: null
      },
      attributes: {
        username: providerUser.username,
        standalone: false
      }
    });

    existingUser ?? await auth.createKey(user.userId, {
      type: "persistent",
      providerId: "discord",
      providerUserId: providerUser.id,
      password: null
    });

    const session = await auth.createSession(user.userId);
    locals.auth.setSession(session);

and when authenticating that user:
const key = await auth.useKey('username', username, password);
 if(!(await auth.getUser(key.userId).standalone)) {
	return fail(400, {
		message: 'This account is not standalone.'
	});
 }
 const session = await auth.createSession(key.userId);
 locals.auth.setSession(session);

Additional information
The examples given are for SvelteKit

Yeah an API to address this will likely be added in v2

We've removed primary keys in v2 beta


Lint readme

I need any commit to land on the release branch to trigger the RC.6 build in OSCI, so I thought I would check
the readme.
Description
Added a comma and removed spaces at the end of the lines
Checklist

Did nothing - this is just a comma and some whitespaces

Testing Performed

Did nothing - this is just a comma and some whitespaces

This PR has nothing to do with the release. Please push an empty commit to the release branch from your local clone and remove this PR from the milestone.


Add IETF field hasher

Based on my older work, but rebased on top of more recent work: #21 should be merged first, since this work branched off the tip of #21.
Description

Add a field hasher compatible with IETF specifications.
The DefaultHasher previously available is moved from mod.rs to its own file default_hasher.rs.
IETFHasher is placed in its own file too.
Both hashers are exposed directly in the field_hashers module, so that instead of calling:

use field_hashers::default_hasher::DefaultHasher;

You can directly import the hasher:
use field_hashers::DefaultHasher;

Previous unit tests using DefaultHasher pass.

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (master)
[ ] Linked to Github issue with discussion and accepted design OR have an explanation in the PR that describes this work.
[ ] Wrote unit tests
[x] Updated relevant documentation in the code
[ ] Added a relevant changelog entry to the Pending section in CHANGELOG.md
[x] Re-reviewed Files changed in the Github PR explorer

Actually let's only add the IETF hasher once finished and tested fully.


[3478] DateTime.UtcNow returning wrong time

Fixed multiple issues with DateTime, including #3478.

The issues affecting DayOfYear property seems to be only triggered by South America (potentially south hemisphere countries), due to the different time zones set up.


Remove NOTE about switching context

This commit suggests removing the NOTE about switching context as at
least when using drg 0.8.0 there was no prompting about a context name,
and drg switched to the default context automatically.

@jbtrystram  Yea, that might indeed be the case with newer drg version.

yup drg now automatically switch to the new context when logging in, except if you add the -k flag.
I'll be releasing drg 0.9.0 this week btw


Implement the generation of dashboards

Given a structure and confidence scores.

Could be considered a duplicate of #484. We were able to generate local dashboards earlier (since #325).


[IO-845] test links to targets outside the source directory

Another characterization test, but this one is for behavior I expect we'll want to keep. Specifically it tests that when a link inside the source directory points to a file outside the source directory, the newly copied link still points to that same file.
I do think we should separate this case from the case where the target of the link is inside the source directory. In that case, I think we'll want to repoint the link to aim at the new copy of the target rather than the original target. That change is not made in this PR.
Note that this might lock in the breakage that Google reported with their test resource files. However, the more I think about that the more I'm convinced that resolving all aliases to actual files is surprising behavior. Consider a case where a single file is linked to from three different places. Copying the directory would change the graph and replace one file with four independent copies.
@garydgregory @eamonnmcmanus

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

Comparison is base (4ad9b41) 85.99% compared to head (963cc88) 85.99%.

Additional details and impacted files
@@            Coverage Diff            @@
##             master     #571   +/-   ##
=========================================
  Coverage     85.99%   85.99%
  Complexity     3498     3498
=========================================
  Files           231      231
  Lines          8254     8254
  Branches        964      964
=========================================
  Hits           7098     7098
  Misses          866      866
  Partials        290      290

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

Failure looks flaky and unrelated:
Error: Action 'https://api.github.com/repos/actions/cache/tarball/13aacd865c20de90d75de3b17ebe84f7a17d57d2' download has timed out. Error: The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing.


HTTP messages should use CRLF as the line separator

The problem
HTTP messages should use CRLF as the end of line marker.
Detailed description
According to the HTTP spec,  the CRLF sequence must be used as the line separator in all parts of a HTTP message  except for the entity body. The entity body for "text types" is allowed to have CRLF, LF or CR, but the canonical form also has CRLF as a separator and it's the recommended one.
The safest and most cohesive approach for HTTP messages generated in STYX seems to be codifying the new line marker as CRLF in all the cases.
Relevant parts of the spec:
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
protocol elements except the entity-body (see appendix 19.3 for
tolerant applications). The end-of-line marker within an entity-body
is defined by its associated media type, as described in section 3.7.
from RFC2616 https://tools.ietf.org/html/rfc2616#section-2.2
MIME's canonical form requires that media subtypes of the "text" type
use CRLF as the text line break.  HTTP allows the transfer of text
media with plain CR or LF alone representing a line break, when such
line breaks are consistent for an entire representation.  An HTTP
sender MAY generate, and a recipient MUST be able to parse, line
breaks in text media that consist of CRLF, bare CR, or bare LF.  In
addition, text media in HTTP is not limited to charsets that use
octets 13 and 10 for CR and LF, respectively.  This flexibility
regarding line breaks applies only to text within a representation
that has been assigned a "text" media type; it does not apply to
"multipart" types or HTTP elements outside the payload body (e.g.,
header fields).
from RFC 7231 https://tools.ietf.org/html/rfc7231#section-<IP_ADDRESS>

Hi @dvlato can you

provide a specific example or use case that demonstrates this issue?
also describe what is the particular issue this is causing, as in "a test case NNN fails on Windows"?

I am curious about the impact of this because Styx doesn't do any HTTP framing itself. All of this happens via Netty. It would be rather surprising if Netty was not following the HTTP spec. But even if they were not, it wouldn't probably matter due to the popularity of the project.

After reviewing this, we are adding LF characters after the body of our messages in a few different points:
-PluginToggleHandler
-StyxConfigurationHandler
-VersionTextHandler
-OriginsReloadCommandHandler
There are no LF characters used as line separators in any other parts of the message (headers, or bodies of mime/multipart)  and the LF after the body in those admin endpoints was requested for specific usages.   Changing the LF for a CRLF could break compatibility with tools that do not support CRLF.
Since the current LFs are consistent for the entire text body and for compatibility reasons with automated tools, we can close this issue.


Unsupported Currency representation: GALAXY

Address r3Si5cWtHZZuKXQERoaTKc7Vhw53RdGi2A
name Galaxy
IssuedCurrencyAmount can't support name's Galaxy
ISO_REGEX = Pattern.compile("^[A-Z0-9]{3}$");

https://xrpl.org/currency-formats.html#nonstandard-currency-codes

Hi @tinshen, I am assuming that you were able to solve this since you closed the issue, but want to make sure you aren't still having trouble.

Hi @tinshen, I am assuming that you were able to solve this since you closed the issue, but want to make sure you aren't still having trouble.

tks.
I have solved the problem.


[Docs] Add information to typography

[ ] PR has tests / docs demo, and is linted.
[ ] Commit and PR titles begin with [ComponentName], and are in imperative form: "[Component] Fix leaky abstraction".
[ ] Description explains the issue / use-case resolved, and auto-closes the related issue(s) (http://tr.im/vFqem).

@oliviertassinari  What do think of dividing the Roboto font section in two headings.
One heading saying 'Roboto CDN' and another saying  'Install with npm'. Similar to this link.
http://getbootstrap.com/getting-started/.
Let me know what you think.


NPC strike damage partials don't behave correctly with splash before regular damage

Brochmaw's "Hot Oil" strike is:
"damageRolls": {
	"4fZGQNzx1Cd3Bk0L": {
		"category": "splash",
		"damage": "3",
		"damageType": "fire"
	},
	"HMuWVKqBEU2nbxQf": {
		"category": "persistent",
		"damage": "1d8",
		"damageType": "fire"
	},
	"bQZTcRzXQXaZVxLz": {
		"damage": "3d6+7",
		"damageType": "fire"
	}
}

which results in:

If I edit the json to put the regular damage first, it results in:

Data issue was fixed by https://github.com/foundryvtt/pf2e/pull/11050, but underlying issue remains.


Node 7 Tag and NPM Push Needed

A tag for Node 7 and a push up to NPM is needed.
Right now, I cannot get from NPM a working version of statsd for node7.

Agreed. A new release is needed so that distros that install node 7 by default are supported.

Would great if a new version was tagged and released as currently we cannot use statsd with node 7 or 8. There are a few other comments mentioning this here https://github.com/etsy/statsd/pull/593

Done, we now support up to node 12 😄 sorry this took so long, the project is now being revived!


QG X checks Release 3.2

QG checks
Please keep this issue open until QG 3.2 is concluded and will be managed by the Issue Creator!
We will inform you about finding and proposals in separated issues, this issue here is for the Overview of the Checks!
Product Name: Managed Identity Wallet
Product Owner:
Helm Chart Version:
App Version:
Check of Tractus-X Release Guidelines
This QG 4 Check is depending on the mandatory information from our current Release Guidelines.
TRG 1 Documentation

[ ] TRG 1.01 appropriate README.md
[ ] TRG 1.02 appropriate INSTALL.md
[ ] TRG 1.03 appropriate CHANGELOG.md

TRG 2 Git

[ ] TRG 2.01 default branch is named main

[ ] TRG 2.03 repository structure

Checks within TRG 2.03

[ ] TRG 2.03 /docs directory contains detailed product related documentation for the Tractus-X product
[ ] TRG 2.03 /charts directory contains the Helm chart for the Tractus-X product IF available
[ ] TRG 2.03 AUTHORS.md file (optional) (TRG 2.03)
[ ] TRG 2.03 CODE_OF_CONDUCT.md file (TRG 2.03)
[ ] TRG 2.03 CONTRIBUTING.md file (TRG 2.03)
[ ] TRG 2.03 DEPENDENCIES file(s) with up to date content (Dash tool generated) (TRG 2.03)
[ ] TRG 2.03 LICENSE file (TRG 2.03)
[ ] TRG 2.03 NOTICE.md file (TRG 2.03)
[ ] TRG 2.03 SECURITY.md file (TRG 2.03)

[ ] TRG 2.04 Leading product repository

Checks within TRG 2.04

[ ] TRG 2.04 repository name must be productname without prefix or suffix
[ ] TRG 2.04 should contain the release
[ ] TRG 2.04 references/urls to the product's other repositories
[ ] TRG 2.04 might contain product helm chart(s)
[ ] TRG 2.04 README.md: contains the urls for the underlying applications

[ ] TRG 2.05 .tractusx metafile in a proper format

TRG 3 Kubernetes

[ ] TRG 3.02 PersistentVolume and PersistentVolumeClaim is used when needed

TRG 4 Container

[ ] TRG 4.01 semantic versioning and tagging

[ ] TRG 4.02 top level README.md file, that contains information about the used base image

[ ] TRG 4.03 Image has USER command and Non Root Container

Checks within TRG 4.03

[ ] TRG 4.03 deployment.yaml has runAsUser and allowPrivilegeEscalation: false properly set

[ ] TRG 4.05 released image must be place DockerHub as mandatory container registry; remove GHCR references

[ ] TRG 4.06 Notice File for DockerHub has all necessary information

Checks within TRG 4.06

[ ] TRG 4.06 Link to the source of your base image (Container registry and GitHub if available)
[ ] TRG 4.06 Link to your product image on DockerHub
[ ] TRG 4.06 Link to your repository on GitHub
[ ] TRG 4.06 Direct link to the Dockerfile used to build your image
[ ] TRG 4.06 Link to LICENCE file in your repo as Project License (make clear, that this is the PROJECT licence, not an image license

TRG 5 Helm

[ ] TRG 5.01 Helm chart must be released

Checks within TRG 5.01

[ ] TRG 5.01 appropriate semantic versioning for version and appVersion has to be used in Chart.yaml
[ ] TRG 5.01 must not contain any environment specific values-xyz.yaml
[ ] TRG 5.01 values.yaml file must contain proper default values/placeholders
[ ] TRG 5.01 No hostname provided for ingress
[ ] TRG 5.01 Ingress is disabled
[ ] TRG 5.01 No references to any secret engine service (e.g.: Hashicorp Vault)
[ ] TRG 5.01 Dependencies should be prefixed with the nameOverride and/or fullnameOverride properties
[ ] TRG 5.01 Image tag is set to the Chart.yaml appVersion property
[ ] TRG 5.01 must be deployable to any environment without overwriting default values with a simple helm install command
[ ] TRG 5.01 dependencies have to be declared in Chart.yaml NOT requirements.yml

[ ] TRG 5.02 Helm chart location in /charts directory and correct structure

Checks within TRG 5.02

[ ] TRG 5.02 each file must contain the Apache 2.0 Licence
[ ] TRG 5.02 latest tag is not used in helm chart be default

charts/
    chartNameA/
      Chart.yaml
      ...
    chartNameB/
      Chart.yaml
      ...
AUTHORS.md
DEPENDENCIES.md
LICENCE
README.md

[ ] TRG 5.04 CPU and memory limits and requests are properly set

[ ] TRG 5.06 application must be configurable through the Helm chart

[ ] TRG 5.07 dependencies are present in the Chart.yaml they are properly configured

[ ] TRG 5.08 a product has a single deployable helm chart that contains all components

Checks within TRG 5.08

[ ] TRG 5.08 name of the Chart should be just the product-name without prefix or suffix
[ ] TRG 5.08 values file should contain all available variables (even from subcharts) with default values and comments about what they do
[ ] TRG 5.08 helm install command should successfully install the chart to any supported Kubernetes version cluster (without overwriting default values)
[ ] TRG 5.08 helm test runs without errors

[ ] TRG 5.09 Helm Test running properly

Checks within TRG 5.09

[ ] TRG 5.09 A GitHub action exist which builds or uses the helm chart which gets released
[ ] TRG 5.09 The GitHub action can be triggered manually through Github WebUI manually running a workflow
[ ] TRG 5.09 Helm test verifies that the application is up and running

[ ] TRG 5.10 Products need to support 3 versions at a time

Checks within TRG 5.10

[ ] TRG 5.10 latest (K8s version 1.25)
[ ] TRG 5.10 latest - 1 (K8s version 1.24)
[ ] TRG 5.10 latest - 2  (K8s version 1.23)

[ ] TRG 5.11 Upgradeability PRERELEASE

Checks within TRG 5.11

[ ] TRG 5.11 Based on the Helm test workflow, you must provide a GitHub action which takes the latest released helm chart, does an installation of it and then execute the upgrade to the current / new version.

TRG 6 Released Helm Chart

[ ] TRG 6.01 Released Helm Chart

TRG 7 Open Source Governance

[ ] TRG 7.01 Legal Documentation

[ ] TRG 7.02 License and copyright header

[ ] TRG 7.03 IP checks for project content

[ ] TRG 7.04 IP checks for 3rd party content

Checks within TRG 7.04

[ ] TRG 7.04 DEPENDENCIES file is up-to-date and reflects the current use of the 3rd party content
[ ] TRG 7.04 all libraries listed there should have the status "approved"
[ ] TRG 7.04 no libraries with status "rejected"
[ ] TRG 7.04 for libraries with status "restricted", the according IP issues must be present (issue number in the source column)

[ ] TRG 7.05 Legal information for distributions

[ ] TRG 7.06 Legal information for end user content

[ ] TRG 7.07 Legal notice for documentation

Hints
Information Sharing

FYI @pmoscode, @DominikPinsel, @mknoopvw: We are currently already starting the Release Guideline Checks for the upcoming Tractus-X 3.2 release. Could you clarify, which MIW version is targeted for the 3.2 release and roughly, when this will be present? The checks will be done for the specific MIW release. I'll already have a look at some of the checks and raise issues, if i find things that need to be fixed/added. If you are still in active development for the 3.2 Release, I can also postpone the checks for a bit

@SebastianBezold the version number under which the release will be released is not yet defined, nor is a date determined.
Hence, nothing is released yet.
Feel free to conduct those checks already and please notify us if you find something so that we may fix before it, too.
If you do not perform the checks, that is fine, too,.

I would also suggest, to cleanup the CHANGELOG.md. There are a lot of releases mentioned, but this repo does not contain any release. We could start with a "fresh" changelog and add the feature info to an initial release. What do you think @mknoopvw

Upgradeability not checked, since this is an initial release. Added #69 though, as a reminder for upcoming releases

Hi @mknoopvw and @pmoscode, could you please "self-asses" TRG 7.05?
In short, the TRG says, that you need to include the NOTICE, LICENSE, and DEPENDENCIES file in the META-INF directory of the .jar file you build.
Not a Gradle expert, so I unfortunately cannot point you to an example

HI @mknoopvw, @pmoscode, @borisrizov-zf,
From my point of view, the newly created RC.3 is a good candidate for the actual release.
You can use it to do your re-tests. All issues that are open to complete the Quality Gate check from my side are docs related (final CHANGELOG and legal notice for documentation), that can be done separately

Hi @mknoopvw, @pmoscode, @borisrizov-zf
I created the 0.1.0 release from rc.3.
Release is available here: https://github.com/eclipse-tractusx/managed-identity-wallet/releases/tag/v0.1.0
Chart release as well: https://github.com/eclipse-tractusx/managed-identity-wallet/releases/tag/managed-identity-wallet-0.1.0
0.1.0 Docker image tag also available: https://hub.docker.com/r/tractusx/managed-identity-wallet/tags
I also tested the helm install helm install miw tractusx-dev/managed-identity-wallet --version 0.1.0 --namespace miw --create-namespace and all pods are starting and keep running
So I'll close the QGate issue. The other open findings, that are linked to this issue should be fixed "soon'ish" though


Verifying github account

Keybase was unable to find the keybase.md gist that I created to verify my Github account. An automated email advised me to open an issue here to investigate.

Same here keybase.md gist

Same problem here too - keybase.md

I just created my https://gist.github.com/hoyuyiu/bc0e3d2973d654b8b3bf7c4faf20cc2b.
And I too side unreachable on the keybase client app.

same issue - need a fix

I'm in he same boat. Posted my gist, but Keybase says "unreachable".

I waited and it worked
Michael

On Mon, Sep 9, 2019 at 4:24 PM, Betty<EMAIL_ADDRESS>wrote:
I'm in he same boat. Posted my gist, but Keybase says "unreachable".
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/keybase/client/issues/19361?email_source=notifications&email_token=AMHUQNC7MRGJKSIPJEJROKTQI3LMVA5CNFSM4IU75KB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6JKO5Y#issuecomment-529704823,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMHUQNCWAZZSKLZ6N3YBBQDQI3LMVANCNFSM4IU75KBQ
.

Too many people trying to do it at the same time?

SOLVED:
Go to windows command prompt and type in
keybase prove github
delete your old gist and create a new one copying and pasting from the code that the command prompt displays.
it will ask to check github; choose yes and it will work in seconds.
Note: I could not get it to work with the gist I had already created; I had to redo it.

I have 32 bits Windows how to install on it?

SOLVED:
Go to windows command prompt and type in
keybase prove github
delete your old gist and create a new one copying and pasting from the code that the command prompt displays.
it will ask to check github; choose yes and it will work in seconds.
Note: I could not get it to work with the gist I had already created; I had to redo it.

This still didn't work. Permission Denied!

Same issue here...

did you delete your gist and copy and paste from the command prompt text rather than the text on the app?

did you delete your gist and copy and paste from the command prompt text rather than the text on the app?

I used the command line text.

I was able to complete the verification by repeating the process on a Linux box.

I created a github gist on keybase.md but the keybase client says it is unreachable. Please help me verify.

Thanks, I used the command lines and it worked.
Shedrach
On Thu, Sep 12, 2019 at 9:35 AM rax87<EMAIL_ADDRESS>wrote:

use the cmd method. then wait around 30 mins, it eventually works
On Thu, 12 Sep 2019 at 02:48, kongvy<EMAIL_ADDRESS>wrote:

I created a github gist on keybase.md but the keybase client says it is
unreachable. Please help me verify.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
https://github.com/keybase/client/issues/19361?email_source=notifications&email_token=AJ4CL6DVOT6QA73S4HPMDULQJGNVFA5CNFSM4IU75KB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6QMQ4Y#issuecomment-530630771
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AJ4CL6GL3WWZBMUPXZKQALDQJGNVFANCNFSM4IU75KBQ
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/keybase/client/issues/19361?email_source=notifications&email_token=AJ6ELIA4GZVSUOKTHHTOO23QJH5MBA5CNFSM4IU75KB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6RDQJY#issuecomment-530724903,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJ6ELIEPJFZR62JJMCTZJITQJH5MBANCNFSM4IU75KBQ
.


com.azure.core.http.HttpHeaders as public response headers contract

Response headers contract changed to com.azure.core.http.HttpHeaders
Internal httpHeader types (nested consts groups) are either renamed appropriately or removed
TODO: It might impact performance (need to run the perf benchmark)

Future work

CosmosException protected exception change would be a different PR
Remove Comsos HttpHeaders and fully leverage core HttpHeaders across including request path
Work with azure.core team to undertnd the implementaion reason and optiimzations (Why ConcurrentHashMap, initialcapacity)

Fixes: #11222

Here are the perf numbers

counter
RUN1 (master)
RUN2 (master)
RUN1(PR)
RUN2(PR)

mean rate
10332.04
10501.42
10231.82
9997.79

1-minute rate
9848.01
10006.35
9663.18
9772.05

5-minute rate
4979.89
4926.60
5041.40
4949.97

15-minute rate
3647.43
3526.00
3757.96
3596.68

With the latest PR 5 runs (including all optimizations)

counter
RUN1
RUN2
RUN3
RUN4
RUN5

total time
92
93
88
91
95

mean rate
10753.39
10695.11
11309.63
10954.95
10458.41

1-minute rate
9987.19
10070.64
10271.09
10253.08
10185.69

5-minute rate
5390.47
5407.82
5755.39
5562.00
5460.26

15-minute rate
4148.75
4182.36
4555.01
4299.99
4195.58


Dockerize

Added persist folder for mounting user-specific settings in docker
Placed .dummy file in persist folder to be able to create "empty folder"
Added .dummy to .gitignore
Added variable to define path to possible autentification file in a central way
Add os import and If/Else to check for auth file and execute command regarding to the availability of the auth file

ATTENTION:

My service is running at the moment, with this updated repo, then created a docker container for that (currently: "docker pull shur3d/ytmusicapi_microservice:experimental") and i can send requests to the container and get back a result
I have no idea how to check if authentication works, but it seems that this microservice is working for itsself

Feel free to change anything to a state you might like better
Thanks for your support

Looks good :slightly_smiling_face: :+1:
I'm assuming you've tested both cases (with and without auth.)? ^^

Sorry for the very late reply.
Without auth-file:
INFO:     Will watch for changes in these directories: ['/home/user/python-ytmusicapi-server']
INFO:     Uvicorn running on http://<IP_ADDRESS>:30010 (Press CTRL+C to quit)
INFO:     Started reloader process [1] using statreload
INFO:     Started server process [8]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
No authentication file found > Using YT without Auth
INFO:     <IP_ADDRESS>:38622 - "GET /search?q=Nevermind&maxResults=3 HTTP/1.1" 200 OK
INFO:     <IP_ADDRESS>:38622 - "GET /favicon.ico HTTP/1.1" 404 Not Found

With correclty named file "headers_auth.json" in folder persist
INFO:     Will watch for changes in these directories: ['/home/user/python-ytmusicapi-server']
INFO:     Uvicorn running on http://<IP_ADDRESS>:30010 (Press CTRL+C to quit)
INFO:     Started reloader process [1] using statreload
INFO:     Started server process [9]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
Found authentication file > Using YT-Auth ...
INFO:     <IP_ADDRESS>:38628 - "GET /search?q=Nevermind&maxResults=3 HTTP/1.1" 200 OK

Looks good to me, but i can't really proof that in my case my auth really works.
But in both cases i got correct feedback when checking:
http://mysecretip:30010/search?q=Nevermind&maxResults=3

Thanks for your support.
I updated the container to v0.3 including documentation.
https://hub.docker.com/r/shur3d/ytmusicapi_microservice
Feelin' strong :muscle::smiley:

I've added the Docker URL to the README :slightly_smiling_face:


Freeze model issue

I have frozen a tensorflow model in order to use it in a C++ application. Everything works fine if I freeze the model in my laptop with a GeForce 740m compute capablity 3.5. But if I freeze the same model in a GeForce 1080 compute capability 6.1 I receive this run time error:
Invalid argument: Cannot assign a device for operation 'CTCGreedyDecoder': Could not satisfy explicit device specification '/gpu:0' because no supported kernel for GPU devices is available.
Have you ever experienced this kind of issue? @FloopCZ
Does it mean that if I want to use a frozen model in a C++ application, I have to use GPUs with the same compute capibility for freezing and running the model?

Hi, I have not seen this issue yet. Have you tried the shared build or the static build? The static build is slightly limited.

I've tried the shared build...

what is you CUDA version?

Closing for inactivity. Reopen if the issue persists.
You can try the prebuilt images from DockerHub. See #72.


Error: Failed to list files from FTP server on Windows

Error: Failed to list files from FTP server.
Please open an incident on GitHub:
https://github.com/scriptPilot/app-framework/issues
(Windows 7)

Root cause propably an active FTP mode - not support so far ... maybe somebody knows another Node.js FTP client?

https://github.com/mscdex/node-ftp/issues/100
https://github.com/sergi/jsftp/issues/49

On macOS, it works!


[backport] Fix comments and add TODO to indexing routines

Backport of #6789

[automatic post] Jenkins, test this please.

Jenkins CI test (for commit 7111273de33a5840362db51a302c11741490b94f, target branch v6) succeeded!

Jenkins, test this please.

Jenkins CI test (for commit 7111273de33a5840362db51a302c11741490b94f, target branch v6) failed with status FAILURE.

CI failures seem irrelevant. LGTM!


⌘+L only works for current line

I have assigned hotkey ⌘+L to select current line. In the video you say that if you keep pressing ⌘+L it will keep selecting successive lines, but that does not work. ⌘+L only works for the current line, repressing the hotkey does not do anything.
Am I missing something?

Actually assign it to “Select current line and expand into next block”.
Looking forward to more feedback.


[BUG] 'mlx.core.floor_divide' crashes unexpectedly

Describe the bug
when I use 'mlx.core.floor_divide' API, it did not run as expected, and the error message returned showed that a and b can be integer values.
To Reproduce
Include code snippet
import mlx.core as mx
x=9
y=1
mx.floor_divide(a=x, b=y)

Expected behavior
mx.floor_divide(a=x, b=y) = 9
Desktop (please complete the following information):

OS Version: MacOS 14.2.1
Version 0.7.0

When I set x and y as arrays, I still cannot run successfully

That is expected behavior, the first two arguments to floor divide are positional only, you cannot name them. There we are following the numpy API so the same would not work in numpy.
It should work if you do:
mx.floor_divide(1, 2)

Note almost all of our ops have the input array (or arrays) as positional only and the remaining arguments as optionally named arguments.
We are trying to follow numpy in that convention, if you encounter any discrepancy, please file an issue!


Update to 1.19

Not sure if there are any bugs or not. I'm tired lmao

Thank you for your contribution.


FreeRTOS TCP V2.4.0: DHCP Fails

So, before, while I've been using FreeRTOS TCP V2.3.3 my device used to cold boot (fist time power on) with following code:
int main(void) {
	bsd_init();
	const uint8_t addr_dummy[4] = { 0, 0, 0, 0 };
	FreeRTOS_IPInit(addr_dummy, addr_dummy, addr_dummy, addr_dummy, bsd_get_MAC_Addr());
	// {"create tasks"}
	vTaskStartScheduler();
	bsd_critical_fail_trap(__func__);
};//main()

And everything worked flawlessly, until I tried FreeRTOS TCP V2.4.0, which caused the following problem: the system completely fails to digest received DHCP responce. Inifinitely.
Debugging revealed the following problem:
Before, in FreeRTOSv202107.00/FreeRTOS-Plus/Source/FreeRTOS-Plus-TCP/FreeRTOS_UDP_IP.c, Line 318
vARPRefreshCacheEntry() was called unconditionally. And everything worked.
Now, in file FreeRTOSv202112.00/FreeRTOS-Plus/Source/FreeRTOS-Plus-TCP/FreeRTOS_UDP_IP.c, Line 322
xCheckRequiresARPResolution() is called first instead. Inside, it checks if' 'SourceIPAddress' belongs to the same subnet. Obviously, when network is not initialized yet, this check fails, so network never gets initialized.
The solution is to call FreeRTOS_IPInit() with NetMask of <IP_ADDRESS> on cold (first) boot.
I would not call it a bug, but rather a significant change in behavior, which was not reflected in release notes and caused quite a bit of time loss.
So, please either mention this change in release notes, or allow skipping xCheckRequiresARPResolution() before network is initialized (e.g. if (*ipLOCAL_IP_ADDRESS_POINTER == 0) { /* skip ARP processing */ }).

Hello @RuStrannik, I am sorry to hear that you had these problems with +TCP V2.4.0.
And thanks a lot for reporting this. We were not yet aware of this change in behaviour.
I will sort it out and come back to it.
Hein

As you see here above, I already created a PR to repair this.
Thanks for sorting out the problem and reporting about it.
Hein

@htibosch, thank you for prompt response, that solves the problem.

Hello @RuStrannik,
Apologies for the trouble the change has caused you. We added the change (using xCheckRequiresARPResolution) since that is what RFCs require - we need to send out an ARP Packet for any new local subnet IP we encounter. But as you correctly pointed out, this caused an unforeseen issue with DHCP.
I am reviewing the PR that @htibosch has raised. After minor fixes, we shall merge it soon to the mainline of the repository.

I agree, having xCheckRequiresARPResolution() totally makes sense, I'm glad that this side effect got fixed so quickly.


Week 5

Week 5
Submenu with html table and JavaScript tutorial
Team Project
New Vocab Terms
Flask Customization:

Thoughts

Good customizations to flask index and stub pages
Great additions to vocab list
Working submenu that links to different pages
Looks like you were working hard on your JavaScript tutorial

Overall Grade

2.7
Graded by Ben Lee

Nice visuals and personalization of FLask page.   Worked on vocab blog.   Made table in HTML for Fastpages and had issues.
2.7

2.7, I saw you made all the changes necessary, and I liked your group's idea for the project


How to use InitialValues With Deep Form

Hello,
how can i pass an initial object to a form (seperate component) set inside another global form??
I'm using the deep form concept but i cannot initialize my form.
any help please?

You can use initialValues to initial deep forms.
reduxForm({
  form: "myform",
  fields: [
    "name",
    "phones[]",
    "address.street",
    "address.city",
  ],
  initialValues: {
    name: "John Doe",
    phones: [
      "555-1234",
      "555-5678",
    ],
    address: {
      street: "1052 Huntz Lane",
      city: "Boston",
    }
  }
})

In the future, we recommend that you ask questions on StackOverflow first, and file issues if you’re confident the bug is in the library.


Handle changes to DigitalOcean slugs

DO change their valid Kubernetes versions frequently and this will break the existing module with a hard-coded slug.
Ideally, the module should determine the latest version automatically.

This is available via a data source: https://www.terraform.io/docs/providers/do/d/kubernetes_versions.html

Fixed in https://github.com/telliott-io/kube-clusters/commit/88d59e1ae628aaf1e36cf9fbfbadd12b61fd1c8e


Where is the TFRT's MLIR translation code from TF GraphDef to TFRT dialects?

Hi, Can you tell me where is the code about MLIR translatation from TF GraphDef to TFRT dialects?
I read the code and can just find the runtime implementation code only.
I also searched the TensorFlow repo, just find something like tensorflow/compiler/mlir/tfr, not sure whether it is.

Hi,
Thank you for your interest. This is being developed. Unfortunately the
open sourcing is being blocked by some build management issues.
On Mon, Nov 23, 2020 at 8:20 PM Yan Chunwei<EMAIL_ADDRESS>wrote:

Hi, Can you tell me where is the code about MLIR translatation from TF
GraphDef to TFRT dialects?
I read the code and can just find the runtime implementation code only.
I also searched the TensorFlow repo, just find something like
tensorflow/compiler/mlir/tfr
https://github.com/tensorflow/tensorflow/tree/master/tensorflow/compiler/mlir/tfr,
not sure whether it is.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/runtime/issues/32, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHMYR5CGDKW2NKSOO2L5K3SRMX7LANCNFSM4UAJNA6Q
.

I see, thank you!

Hi, @mhong .


Components should work with undefined value

In a normal app, you'd frequently have a component (e.g. slider) that works on more than one object at a time. You can have many selected objects, each with a different value, in which case the slider's value should be undefined until the user interacts with the slider.

Fixed by @darung


databaseType isn't known by json-schema

When using Prisma in combination with MongoDB right now and opening a prisma.yml file in VSC, you'll see the following warning message for the databaseType field:

I assume this is because the databaseType isn't yet published in the JSON schema on schema.org.
This is related to #3506

no updates ?


MFA Changes to NPS Extension

https://learn.microsoft.com/en-us/azure/active-directory/authentication/how-to-mfa-number-match#nps-extension
Per the changes written in the above KB:

If your organization uses Remote Desktop Gateway and the user is registered for OTP code along with Microsoft Authenticator push notifications, the user won't be able to meet the Azure AD MFA challenge and Remote Desktop Gateway sign-in will fail. In this case, you can set OVERRIDE_NUMBER_MATCHING_WITH_OTP = FALSE to fall back to Approve/Deny push notifications with Microsoft Authenticator.

This KB may need to be updated to incorporate this change.

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

ID: 5d46abb2-6ad9-e86e-8808-b69ca11922d8
Version Independent ID: c4ccd9d6-13c7-6150-6a44-241bdf9b0982
Content: Use number matching in multifactor authentication (MFA) notifications - Azure Active Directory - Microsoft Entra
Content Source: articles/active-directory/authentication/how-to-mfa-number-match.md
Service: active-directory
Sub-service: authentication
GitHub Login: @mjsantani
Microsoft Alias: justinha

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

@urbndude
Thanks for bringing this to our attention.
I'm going to assign this to the document author so they can take a look at it accordingly

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

I think this is fixed. If not, please submit a pull request with the changes you suggest. #please-close


Why not use singleton of the HttpClient object?

Would it have better performance by having a shared HttpClient object so that it reuses port for getting messages instead of allocate and dispose each time?
https://github.com/Scooletz/QueueBatch/blob/107e2f6447bd32203698cff9dd8a1aec7c2e0e21/src/QueueBatch/Impl/Queues/FastCloudQueue.cs#L118

This is by design. The pooling is done on the handler level, in a way similar to the HttpClientFactory. The client itself, is disposed similarly to package I mentioned.
Http handlers are cached for a specific amount of time using a concurrent friendly cache, so the costs of creation etc should be amortized in time.
Does it answer the question? If yes, please close, if not - please provide more evidence and/or background for this issue.

yes it does thank you


Fix typo in README

In Installation section
import com.getcapacitor.community.firebasecrashlytic.FirebaseCrashlytics;
is corrected in
import com.getcapacitor.community.firebasecrashlytics.FirebaseCrashlytics;
and in Usage section
FirebaseCrashlytic.crash({ ... });
is corrected in
FirebaseCrashlytics.crash({ ... });

is this plugin still maintained ?


Update dali to 1.44 and TRITON container to 24.11

Signed-off-by: Michal Zientkiewicz<EMAIL_ADDRESS>

CI MESSAGE: [21090590]: BUILD STARTED

CI MESSAGE: [21090590]: BUILD FAILED

CI MESSAGE: [21093591]: BUILD STARTED

CI MESSAGE: [21093591]: BUILD FAILED

CI MESSAGE: [21093854]: BUILD STARTED

CI MESSAGE: [21093957]: BUILD STARTED

CI MESSAGE: [21093957]: BUILD FAILED

CI MESSAGE: [21094120]: BUILD STARTED

CI MESSAGE: [21094120]: BUILD FAILED

CI MESSAGE: [21094935]: BUILD STARTED

CI MESSAGE: [21094935]: BUILD PASSED


refactory: containerMetrics => systemProcessMetrics

took me a while until I understand why containerMetrics need used in the process code path.
it's acutally a special container => system container

@jichenjc let's keep the container metric naming. If we decide to expose processes in each container in the future, container metric is more appropriate.

I also prefer to use containerMetrics or processesMetrics (plural as it could be aggregation of processes), because systemProcessMetrics can be misleading as they are not necessarily user processes.
Btw, are you also changing the key of this map? I mean instead of use containerID?

@jichenjc the process metrics are extracted from each container. Currently only the system processes are exported. It is possible in the future, all the processes in all containers are exported too, if the prometheus client scaling issue is resolved.

all the processes in all containers are exported too, if the prometheus client scaling issue is resolved.

ok, what's the use case of expose process in container if we do have container metrics ?
curious because I Think the goal is to expose container metrics through container method and process through process method only?

As all processes have a cgroup ID and some cgroups can have container id (a docker container has only one cgroup).
Libvirt domain also have a cgroup ID.
One solution would be changing the logic to cgroup metrics. Wdyt?

One solution would be changing the logic to cgroup metrics.

you mean instead of each process metric, we expose cgroup instead?
@rootfs what's your suggestion?

@jichenjc I had another idea for this.
We can use a generic name, metricsMap and choose the key based on the level of aggregation needed/configured.
The options for the key can be podID, containerID, cgroupID and processID. Different level of aggregation will have different overhead and purposes. Wdyt?

@jichenjc and @rootfs, after reviewing of the code, I noticed that there are now two maps: c.ContainersMetrics and c.ProcessMetrics, which seem to contain duplicated information.
It would be better to have a single map to reduce overhead and simplify the code.
As suggested before, the map could be configured with different keys depending on whether Kepler will report per-process or per-container metrics.

As suggested before, the map could be configured with different keys depending on whether Kepler will report per-process or per-container metrics.

that's a good idea, I will check what we can do on this ,guess it's due to we add container first then process
so should consider refactory if possible

we have following logic for now:
container metrics => use container ID which is a string / and no process ID
process metrics => system ID (all process share same string) / process ID
so how about we do a fmt("%s-%d", <system container ID >, PID)  as key for processes
for each process then we can combine them together as a new variable like metrics ?
and for process we can ignore all the container related stuff like PodName, Namespace etc?

@jichenjc sounds interesting.

and for process we can ignore all the container related stuff like PodName, Namespace etc?

That is right!
Btw, do you think that PID from different container will collide?
If not, why not only use the PID as the key?
So, we don't need to create a key with containerID-PID when per-process metrics is enabled.
Therefore, when  per-process metrics is enabled we use the PID as the key, otherwise we can use the containerID.
In my point of view, when per-process metrics is enabled there's no need to aggregate the metrics per container in the metrics map. We should report the energy/metrics per-process also in the Prometheus metrics. That is we will need to add a new label to the Prometheus metrics that includes the process name and ID. This way, users can aggregate the container metrics using a Prometheus query.


Build is failing per third-party license differences

See https://github.com/erlef/setup-beam/runs/4572138656?check_suite_focus=true as an example.

Hey.
You have to check the actions (I think it's npm run licenses) to update this locally, after which you have to upload the differences too.
We should probably have a "How to contribute" part in the README because some details (like this) aren't immediately obvious.

Yeah, I knew that part but I wasn't sure why there was a diff all of a sudden, I guess it just grabbed some latest versions in ci.

That's the main part of it I don't like (this whole licensing thing - we inherited it, we didn't come up with it). This only proves that even for a given fixed version there are some internal moving parts (mostly some JS lib.).
Should we try to automate the update of that file? I'm sure whoever's doing it is not validating ALL the updates licenses one by one.

Well, I guess the question I ask myself is what do we get out of checking the licenses? I think perhaps made since when github owned the action as setup-elixir, but I don't think it makes sense for us.

Well, I guess the question I ask myself is what do we get out of checking the licenses? I think perhaps made since when github owned the action as setup-elixir, but I don't think it makes sense for us.

We check the licenses to make sure they're updated (as per the version we're pulling). Otherwise you might be importing a version of a dep. that has a non-proper (updated) license. This only happens when the license changes (or is added or removed), I imagine. But I'm Ok with whatever is decided for this. No real opinion on having the licenses declared or not (don't know if it's a legal requirement).

We check the licenses to make sure they're updated (as per the version we're pulling). Otherwise you might be importing a version of a dep. that has a non-proper (updated) license. This only happens when the license changes (or is added or removed), I imagine. But I'm Ok with whatever is decided for this. No real opinion on having the licenses declared or not (don't know if it's a legal requirement).

@starbelly, do you think it's relevant to keep the generated 3rd party licenses next to the software? I mean, I don't see this being done often, but there might be good reason for this to have happened from the get-go.
If not, we should get rid of everything 3rd party license -related and avoid this class of issues.

Actually yeah, per the licenses of some of the third party deps, they must be included since pulling down the action from github ci is considered distribution.

Ok, do you know how to automate this? 😄 I mean, we can always do it just before a release, but if automatic, it would probably be better.

@paulo-ferraz-oliveira Yeah, I think it's best if done before a release to ease the friction. We could setup scheduled builds to keep us in check.

We could setup scheduled builds to keep us in check.

Does this mean "send us an email", or something? I've not used that before.

https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#onschedule


⚠ Bofrost.es has degraded performance

In aa10c59, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1467 ms

Resolved: Bofrost.es performance has improved in 9a408bd after 6 minutes.


Consultant Details - remove incorrect/test hardcoded values

Cornerstone project:  consultant-details.js
Names should be 'Tastefully Simple' if not otherwise set.

Use environment specific domain URL, not the hardcoded production URL
Just a thought:  Can this No Consultant image be added to BigCommerce and just reference it from there?  Everyone uses the same image, regardless of environment.

Created a Razoyo ticket for this issue: https://razoyo.atlassian.net/browse/TST-157

@richierubin can you specify what you want instead of:
"Testing Shop or Host with me headline"
We will add the noconsultant image to the theme and just reference it that way.

@richierubin The script for the Consultant page is written in Shogun via custom elements. It's in Consultant page - script file
Got to change the default value for the Consultant Name to "Tastefully Simple". But still need clarification on what should be the default value for the Headline

For the noconsultant image, here's how we did it with Shogun:
In the custom element for the basic info section, we added a no_consultant_photo variable and changed its value type to Image (URL) to have the ability to upload an image. We applied that variable in the onerror attribute.

Then in the Shogun editor, you can upload any image you want in the no_consultant_photo field

In the script, we changed this code
var imgError =
            "this.onerror=null;" +
             "this.src='https://www.tastefullysimple.com/_/media/images/noconsultantphoto.png';";

$img.setAttribute('onerror', imgError);

To this, to account for when there's an image coming from the API or not

This is the headline.

@jsmnglng-w we have decided to hide the headline if you don't get a value from the API.

Removed the default value for the headline when you don't get any value from the API

@jsmnglng-w, @wbyrnetx has this fix being included in a PR?  Or no PR needed shogun widget change?

@TastefullySimple no PR needed. It's in Shogun widget (file name: Consultant page - script)

Can this be closed now?

With no image uploaded, and only the default of Consultant homepage headline- which is " hello there!"-Then nothing shows on the webpage.

However if they don't upload an image, but they do update the Consultant homepage headline- it did display as what was entered. Which is good, and what I would have expected to happen.

Fixed, closing - thanks


Make SharedSecret (de)serializable

Hello!
All is in the title: I'd like for SharedSecret to be (de)serializable. Is this fine?

It sure seems odd to me for SharedSecret to be serializable. Its purpose is to be established without ever being transmitted over the wire.
I’m not sure what use cases you have in mind, but in pretty much any of them I would think it makes more sense to derive some other value from the SharedSecret first before transmitting it over the wire, which allows it to be bound to a particular application. That’s how e.g. TLS 1.3 session resumption works, for example.

To be frank I'm not 100% sure I will need this, but even if I do it will not exactly be transmitted over the wire. I'll get back to you once I get a more expert opinion on the exact use case.

I'm closing this until I get more details on the exact use case.


Delays/missed keystrokes when typing in modals

Moved from AugurProject/augur.js#47, since augur.js just handles the username/password once they're submitted.  This affects the market creation modal as well.
I suspect the underlying issue here is excessive network I/O.  My reason for this is that this problem is intermittent but more-or-less regular, and seems to coincide with block arrivals (which initiate a series of direct-to-geth RPC requests).  One solution might be to just avoid sending any read operations to geth, and get everything from the cache instead.  Another solution could be to throttle network traffic: when I manually turn on throttling in Chrome's network panel, this problem seems to go away.

i think batching/trimming the onBlock update calls would probably make this a non-issue.

Hello,
To be sure is this regarding the client at http://client.augur.net/markets?
Is an example of one of these misbehaving text modals the one that appears when clicking "Submit a Market"?
Are there other examples?
Best,
Baz

If you click "Register" or "Sign in", this happens in the username/password fields, as well.

I can no longer reproduce this; guessing it was inadvertently fixed while optimizing augur and/or augur.js.


Disable infinite scroll when number of cells is 1

I am not able to disable infinite scroll when number of items are 1. Help

Hi !
Thx for your feedback, you can now update InfiniteLayout to <IP_ADDRESS>, there is a new public property called "isEnabled", you can easily add a condition just before reloading data in your collectionView.

Thanks, @arnauddorgans
it is working now.


[PSRule] Run PSRule pre-flight validation on the whole library (scheduled pipeline)

This issue is about implementing a scheduled pipeline to run PSRule validation checks on the whole repository.
This is useful to provide an overview of all failing checks per module overtime (if any).
A status badge should also be added to the repo home page.
Note: the same has been planned for Linter and broken link checks as commented in issue #2363
PR https://github.com/Azure/ResourceModules/pull/2094 hosts a PoC triggered on pull request.

Suggestion: Move to todo and complete as first.
Implementation is almost ready in branch hack/topic6


Swift5.1 Error -- Crash

I want to bring yogakit to my project
But it will lead to crash, I don't know why

Tool
Version

Xcode
11.5

CocoaPods
1.9.2

Podfile
platform: ios 9.0

YogaKit
13.0.1

//Xcode Swift5.1 Project ViewController add this code, but Layout cannot be displayed, Even crash

func createUI() {

        let fontNames = UIFont.fontNames(forFamilyName: "PingFang HK")
        print(fontNames)

        for i in 0..<fontNames.count {
            let label = UILabel()
            label.text = "the \(i) label.."
            label.font = UIFont.init(name: fontNames[i], size: 20)
            view.addSubview(label)

            label.configureLayout { (layout) in
                layout.isEnabled = true
            }
        }

        view.configureLayout { (layout) in
            layout.isEnabled = true
            layout.flexDirection = .column
            layout.justifyContent = .flexStart
            layout.alignItems = .flexStart
            layout.paddingLeft = 15
        }

        view.yoga.applyLayout(preservingOrigin: false)
}

Message

feeling problem is on the SceneDelegate

Because width or height is nagative, fixed in my PR: https://github.com/facebook/yoga/pull/1026

We are deprecating YogaKit as part of the Yoga 2.0 release. We are still going to release a new revision based on the current state of the repo, but won't be accepting new contributions, since we are going to be removing it from the repo after.


docs: wasm configuration

Add documentation around the wasm support needed for the default Shiki syntax highlighter.

Closing in favor of https://github.com/nuxt-modules/mdc/pull/167


Run cli command with --samples 3 will trigger error

Describe the bug
After running a while, the cli response the following:
Error: Cannot create new tab, and no tabs already open.
at C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\gather\connections\cri.js:45:35
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async Driver.connect (C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\gather\driver.js:119:5)
at async Function.run (C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\gather\gather-runner.js:484:7)
at async Function._gatherArtifactsFromBrowser (C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\runner.js:264:23)
at async Function.gather (C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\runner.js:170:21)
at async lighthouse (C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\index.js:50:21)
at async file:///C:/Users/ant008/AppData/Local/npm-cache/_npx/9c5b11f5f0ea845b/node_modules/@unlighthouse/core/dist/process/lighthouse.mjs:16:26
Error: Cannot create new tab, and no tabs already open.
at C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\gather\connections\cri.js:45:35
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async Driver.connect (C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\gather\driver.js:119:5)
at async Function.run (C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\gather\gather-runner.js:484:7)
at async Function._gatherArtifactsFromBrowser (C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\runner.js:264:23)
at async Function.gather (C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\runner.js:170:21)
at async lighthouse (C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\index.js:50:21)
at async file:///C:/Users/ant008/AppData/Local/npm-cache/_npx/9c5b11f5f0ea845b/node_modules/@unlighthouse/core/dist/process/lighthouse.mjs:16:26
C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\gather\driver.js:348
asyncTimeout = setTimeout(reject, timeout, new LHError(LHError.errors.PROTOCOL_TIMEOUT, {
^
LighthouseError [LHError]: PROTOCOL_TIMEOUT
at C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\gather\driver.js:348:50
at new Promise ()
at Driver.sendCommandToSession (C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\gather\driver.js:346:28)
at Driver.sendCommand (C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\gather\driver.js:369:17)
at Object.clearDataForOrigin (C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\gather\driver\storage.js:58:19)
at Function.disposeDriver (C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\gather\gather-runner.js:179:39)
at Function.run (C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\gather\gather-runner.js:532:20)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async Function._gatherArtifactsFromBrowser (C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\runner.js:264:23)
at async Function.gather (C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\runner.js:170:21) {
code: 'PROTOCOL_TIMEOUT',
friendlyMessage: {
i18nId: 'lighthouse-core/lib/lh-error.js | protocolTimeout',
values: {
errorCode: 'PROTOCOL_TIMEOUT',
protocolMethod: 'Storage.clearDataForOrigin'
},
formattedDefault: 'Waiting for DevTools protocol response has exceeded the allotted time. (Method: Storage.clearDataForOrigin)'
},
lhrRuntimeError: true,
protocolMethod: 'Storage.clearDataForOrigin'
}
Node.js v17.1.0
ERROR  Failed to run lighthouse for route Command failed with exit code 1: node<EMAIL_ADDRESS>--cache=true --routeReport={"route":{"url":"https://next.syopex.com/brand/skll"},"artifactPath":"D:\Frontend\unlighthouse\.unlighthouse\next.syopex.com\e6ae\reports\brand\skll"} --lighthouseOptions={"onlyCategories":["performance","accessibility","best-practices","seo"],"throttlingMethod":"provided","throttling":{"rttMs":0,"throughputKbps":0,"cpuSlowdownMultiplier":1,"requestLatencyMs":0,"downloadThroughputKbps":0,"uploadThroughputKbps":0},"formFactor":"mobile","screenEmulation":{"mobile":true,"width":360,"height":640,"deviceScaleFactor":2}} --port=54889
Error: Cannot create new tab, and no tabs already open.
at C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\gather\connections\cri.js:45:35
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async Driver.connect (C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\gather\driver.js:119:5)
at async Function.run (C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\gather\gather-runner.js:484:7)
at async Function._gatherArtifactsFromBrowser (C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\runner.js:264:23)
at async Function.gather (C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\runner.js:170:21)
at async lighthouse (C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\index.js:50:21)
at async file:///C:/Users/ant008/AppData/Local/npm-cache/_npx/9c5b11f5f0ea845b/node_modules/@unlighthouse/core/dist/process/lighthouse.mjs:16:26
C:\Users\ant008\AppData\Local\npm-cache_npx\9c5b11f5f0ea845b\node_modules\lighthouse\lighthouse-core\gather\driver.js:348
asyncTimeout = setTimeout(reject, timeout, new LHError(LHError.errors.PROTOCOL_TIMEOUT, {
Reproduction
npx unlighthouse-puppeteer --site next.syopex.com --samples 3 OR npx unlighthouse --site next.syopex.com --samples 3
System / Nuxt Info
System:
    OS: Windows 10 10.0.19045
    CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
    Memory: 7.24 GB / 15.92 GB
  Binaries:
    Node: 17.1.0 - C:\Program Files\nodejs\node.EXE
    npm: 8.1.2 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Spartan (44.19041.1266.0), Chromium (113.0.1774.35)
    Internet Explorer: 11.0.19041.1566

Same here using the unlighthouse command with an unlighthouse.config.ts file with scanner.samples 3 set.
Reproduction
unlighthouse
System / Nuxt Info
System:
OS: macOS 12.6.5
CPU: Apple M1 Max
Memory: 32 GB
Binaries:
Node: 16.20.0
npm: 9.6.6
Browsers:
Chrome Version 113.0.5672.92 (Official Build) (arm64)

Hi, thanks for the issue :)
This may be resolved with Unlighthouse 0.7.0 with the updated Puppeteer dependency. If it still doesn't work you can try to pass the config: chrome.useSystem: false and use the fallback Chrome installer.

Hi, thanks for the issue :)
I am not able to replicate it personally, though this may be resolved with Unlighthouse 0.7.0 with the updated Puppeteer dependency. If it still doesn't work you can try to pass the config: chrome.useSystem: false and use the fallback Chrome installer.

I tried to put chrome.useSystem:false in the unlighthouse config file, it did download a fallback chrome automatically but still response the same error. I also tried to manually point it to my local chrome installation (both chrome and edge tested), and it also response same error.
Here is my config:
export default {
  puppeteerClusterOptions: {
      // only run 1 worker at a time
    maxConcurrency: 1
  },
  puppeteerOptions: {
    executablePath: 'C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe'
  }
}

Sorry I'd like to help further but I can't replicate on my Linux laptop, if any Windows users have capacity to help me debug it would be appreicated.

I saw this issue when I tried sampling, I'll see if I can debug it and figure out what the issue is.

I have made two attempts to upgrade so far, it hasn't been very successful as there's many breaking changes (cjs support is dropped). Will attempt again soon .

Just ran into this issue myself. Seems related to this.

Just to give more information about the problem, it also occurs for me on MacOS
System:
    OS: MacOs Monterey 12.1
  Binaries:
    Node: 18.17.0
    npm: 9.4.1
  Browsers:
    Chrome(Version 114.0.5735.248)

IUnderstanding this is a Lighthouse 9 issue.

I have made two attempts to upgrade so far, it hasn't been very successful as there's many breaking changes (cjs support is dropped). Will attempt again soon .

I'm really looking forward to this. This is especially important in CI environment since the CPU/Memory power varies in quite a lot when running against multiple pages. Without samples, it is really hard to set a meaningful budget to warn about performance issue.

The problem can be resolved by bumping the version of the Lighthouse package inside @unlighthouse/core.
https://github.com/harlan-zw/unlighthouse/pull/183 made that changes to the codebase. However, the current version (v0.10.6) still uses Lighthouse (^9.6.8) so we may need to wait for the new version release.
For those interested, here's a GitHub workflow file where the Lighthouse version is manually updated.

The problem can be resolved by bumping the version of the Lighthouse package inside @unlighthouse/core.
#183 made that changes to the codebase. However, the current version (v0.10.6) still uses Lighthouse (^9.6.8) so we may need to wait for the new version release.
For those interested, here's a GitHub workflow file where the Lighthouse version is manually updated.

Just tried this. Though --samples can be used now, I noticed that Lighthouse crashes fairly frequently. Not sure whether this is related to the compatibility with the current @unlighthouse/core implementation.