Agents fail to start

I am provisioning new VMs for use in a testing process.  The VMs use Windows 10 Pro (Azure gallery image RS3-Pro, or RS2-Pro), and use DS2v2 (2 vCPU, 7GB RAM). The VMs are configured with a VSTS agent running as a service and connected to a deployment group.
I am seeing 2 problems:
1 - the provisioning will report failure, with agents taking > 6 hours to establish communication with VSTS (over 1 hour before any agents are communicating with VSTS)
inspection of VMs will typically show successful configuration of an agent, and rebooting VMs is often enough to establish agent communication with VSTS/deployment group.
2 - when starting VMs, not all agents will start.  6-10 agents (out of 99) will randomly not start, requiring VMs to be restarted.
This is a serious impediment to being able to use these VMs in a VSTS release process.

For failure to start, grab the _diag logs and attach.  They should highlight what's happening in the the failure to start cases.
Regarding the 6 hours, is that your code provisioning the VMs?  Have you broken down the time?  Where is that code running?  A hosted vs 2017 machine?  (those are limited to 6 hours, private build/release agents on your own VMs have no limits).
As a comparision our machine management provisions machines into a pool in minutes and the agent starts up almost immediately.  So something odd is going on.

@bryanmacfarlane I am running a VSTS release process to provision multiple VMs via an ARM template.  It's using a hosted VS2017 agent.  The release I have going at the moment has been running for just over 2 hours, and there are now 92 agents registered in the deployment group (out of 99 being provisioned).
All but a few minutes of the releases have been taken within an azure resource group deployment task, which is executing the ARM template provisioning.
A quick inspection of _diag logs (Agent_20180606-082625-utc) on a VM where the agent failed to start showed:
System.Net.Http.WinHttpException: The server name or address could not be resolved
_diag logs from that VM are attached.
lab2-23-dgagentlogs.zip

@bryanmacfarlane one of your colleagues told me a couple of months ago that there were issues with VSTS agents and VMs with < 4 CPU cores.  This was part of a previous issue where the release was always reporting that provisioning had failed, because it was taking longer than expected for the extensions on the VM to be provisioned.  I am not sure if this is still a problem

I'm sending this to the release team.  I think you need to separate the agent application (this repo) from the assertion about the VM (machine) needing 4 cores for your scenario (if that assertion is indeed correct).   Not sure what the application can do but we will certainly look at it.
If the hosted agent specs (6 hour max, 2 cores) is not sufficient for your scenario, then the other option is to create a private build/release agent to run the release on.
https://docs.microsoft.com/en-us/vsts/pipelines/agents/agents?view=vsts
I'm forwarding this to the release folks (Bishal, Muthu) to investigate and comment on.

@bryanmacfarlane the issue with < 4 cores was supposed to have been addressed last month.  I mention it because that's what I was told was the root cause of previous releases failing.
When I started provisioning these VMs, I expected the ARM template execution to complete in around 40 minutes (using a hosted agent).  As it is currently, I can only expect that this will not complete, but will timeout instead.
From Azure portal I can see that there are problems with some of the VMs, but I cannot find further information.  e.g. this is what I see from my current release:
Provisioning failed. OS Provisioning for VM 'wkb-lab3-28' did not finish in the allotted time. The VM may still finish provisioning successfully. Please check provisioning state later.. OSProvisioningTimedOut

@acm74 , Can you try the following:

Create a release to provision VMs without configuring VSTS agent and check if it is faster? This may be issue with VM provisioning and not related to VSTS agent.

Configure VSTS agent to deployment group manually from the newly provisioned VM. Steps to do that are:
a. Go to Deployment group details page
b. Click on Use PAT token check box and click on copy script on clip board button.
c. Login to the Azure VM, Open PowerShell admin console and run the script.

Please let us know which step is taking most of the time. We can debug further once we the info.

@acm74 can you please share following information with us:

ARM template deployments logs. You can get it by going to the resource group which you created using VSTS

and then clicking on the latest deployment which timed out

if you click on operation details you will be able to see more details

VM extension logs from one of the VMs which did not get configured properly. You can get the logs by remoting into the VM at location C:\windowsazure\logs\plugins\Microsoft.VisualStudio.services.Teamservicesagent folder.

@bishal-pdMSFT the deployment that timed out is still marked as in progress.  The VMs (including storage account, IP addresses, NICs) deployed successfully.  All the VM extensions are marked as in conflict.  These VMs have 3 extensions - for IAAS Diagnostics, a custom extension for WinRM, and the Team Services Agent extension.  All show the same error- "an internal execution error occurred".
TeamServicesAgentLogs.zip

@niadak I will remove all the extensions from my template and attempt a small release with that.  Given what I just posted, I expect this to complete quickly and successfully.

@acm74 The TeamServicesAgent extension logs don't point to anything wrong. It has successfully configured agent against deployment group. Are you still not seeing this deployment group agent in VSTS?
The culprit here seems to be Conflict status. Can you also look into logs of other extensions - they are in similar place as TeamServicesAgent logs. Is any other extension failing with "an internal execution error occurred"?
Are you creating new VM for every deployment, or just updating existing VM with extensions?

@bishal-pdMSFT I can't see anything wrong with the other 2 extensions.  The logs from the same VM are attached here.
To clarify what I am trying to do - I am building new VMs to use for Coded UI Testing.  Once the VMs is provisioned, I am using the deployment group agent to configure all the software we need, along with all the other little configuration details necessary for Coded UI Testing.
Microsoft.Compute.CustomScriptExtension.zip
Microsoft.Azure.Diagnostics.IaaSDiagnostics.zip

@bishal-pdMSFT I also see Azure portal come up with these messages
This is from the latest lab I am building.  For the VMs listed, there are no extensions installed (no log files either).

@niadak ARM template without extensions provisioned successfully 3 VMs in approx. 11 minutes.  I had to wait almost an hour before I could successfully remote into any of the VMs (see screen shot).
The deployment group agent installation took less than 2 minutes to complete on the VMs I could log into.

@niadak I provisioned 2 new VMs with a larger size (Standard_DS3_v2_Promo, which is 4 core and 14 GB RAM).  Provisioning finished in just under 10 minutes, I was able to remote into VMs within 5 minutes of this and install deployment group agent.

@niadak I provisioned 2 new VMs, including extensions, using a 4 CPU, 14GB VM size.  The Provisioning took 30 minutes to complete.  It's now going through post-provisioning configuration.

This looks like the issue which you referenced earlier. Let me involve Tejas who was investigating it.

@bishal-pdMSFT I have another issue, and I am wondering if this is related to what we are seeing here.  In our post-provisioning configuration we install software.  We're using Chocolatey for some of this, but we see errors like "The term 'choco' is not recognized as the name of a cmdlet, function,
script file, or operable program".
Sometimes it works and choco commands are available, often they are not.

@bishal-pdMSFT has there been any progress?

@bishal-pdMSFT this morning I am now seeing that one of my labs has somehow had their interactive agents removed.  This is not the first time I have seen this behavior.

@niadak @bishal-pdMSFT I have deleted all 2 CPU VMs, and am in the process of re-creating VMs.  The first group has just been provisioned (using 4 vCPU, 16 GB RAM VM size), and is about to start its post-provisioning configuration.  It took 50 minutes for the provisioning to complete.  I believe the majority of that time was spent provisioning the extensions on the VMs.  All 99 VMs have successfully registered into the deployment group.

@acm74 we are following up with VM team to understand whether the May update has been rolled out or not. I will keep you posted.

@acm74 will it be possible for you to provide the azure subscription id which you are using for provisioning VMs. Also, please tell us the resource group name for 2 CPU VMs which were timed out earlier. I am trying to look into telemetry to get more data.

@bishal-pdMSFT I can provide this - is there a less public way I can get the details to you?

please e-mail on our customer queries alias RM_Customer_Queries AT microsoft.com

@bishal-pdMSFT @niadak FYI today I will be rebuilding labs - I will post results of this later today.

@acm74 I assume you used 4core VMs only.
Can you check your 2 core VMs to see if they have KB 4103720 installed? This KB contains the fix for VM agent issue. You can RDP into VM and check “Windows Installed Updates” in the Control Panel,

@bishal-pdMSFT the new labs are only 4 core VMs.  Neither they nor the remaining 2 core VMs have KB4103720 installed.
Because these are Windows 10 client VMs, it's really hard to have any control over windows update.  Both 2 and 4 core VMs have updates pending.  I am going to try and get these updates installed and see if KB4103720 can be found.

From whatever info I could get from VM/Image team, this KB will mostly make into gallery in near future - 1 week or so. But nothing in my hand.
Unfortunately, till that time you will have to keep using 4 core VMs.

I will investigate next week whether I can install this directly instead.
Sent from VMware Boxer
On Jun 15, 2018 4:13 PM, Bishal Prasad<EMAIL_ADDRESS>wrote:
From whatever info I could get from VM/Image team, this KB will mostly make into gallery in near future - 1 week or so. But nothing in my hand.
Unfortunately, till that time you will have to keep using 4 core VMs.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Microsoft_vsts-2Dagent_issues_1610-23issuecomment-2D397634219&d=DwMCaQ&c=tv8X2YgD7mG0v9N2vuBcgw&r=xJTxU_1AyVNfmdD-m3wt_-SqdjRcubABKXNgK38tqfo&m=xft4bN277kf-A8ufMESDXZkFkHveQxS4ec6CO52j_M0&s=9mPSlbwEwDCoc5O07mhYT1Fem3pOzlAksE09F24oDcw&e=, or mute the threadhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_Ai0Bi4E3m9-5FZ8AAOe9pCMSBpLnt4EZ4Mks5t88EbgaJpZM4UcUe5&d=DwMCaQ&c=tv8X2YgD7mG0v9N2vuBcgw&r=xJTxU_1AyVNfmdD-m3wt_-SqdjRcubABKXNgK38tqfo&m=xft4bN277kf-A8ufMESDXZkFkHveQxS4ec6CO52j_M0&s=WWiZ0BOsDUFYnG6EwXiLhScMKgO2cWseyM0Rf3o8fEQ&e=.
Confidential Communication: The contents of this e-mail including any attachment are confidential and intended solely for the person(s) to whom they are addressed. Any reader of this email who is not the intended recipient is notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately and delete all copies from your computer system. Subsequent alterations to this email after its transmission will be disregarded.

@acm74 Can you check with 1-2 core VMs and let us know? I tested and did not get the error this time. Thanks.

@tejasd1990 thanks for the update.  I will try to do this next week.  At the moment we are seeing some instability in West Europe region, so I am unsure if we could get a clean result if I tried this now.  I will post again when I've had a chance to try this.

@tejasd1990 I still see errors with a 2 core VM deployment.
VMProvisionLogs_r52_id_804.zip

@acm74 This issue has not been fixed for RS3, but RS4 should work. Can you try with RS4 SKUs and update?


Resume a conversation started in Open Web-UI using ollama command line

Hi there!
I can't find information on this, let me know if there's actually a way to do this.
Thanks!

This wouldn't be an Ollama thing. I would bring this up to Open Web UI itself.

Hi @WolfTheDeveloper, well, my mental model was that it is possible to have conversations with context using Ollama APIs in Open Web UI. We can see a context parameter in Ollama API doc.
Question is how to do the same using Ollama command line, that's why I created the question here, and I can't find options to use a contact parameter on the ollama run command.
I don't think see it as an Open Web UI thing (and this just should be a frontend on top of Ollama and other API based LLMs.

Open WebUI and Ollama CLI are two distinct applications implementing frontends for the Ollama API. While you can definitely use context with /api/generate and messages with /api/chat to implement chat history, it's an implementation detail of the application to support persistence or cross-application chat history.
Ollama CLI has a feature which saves its conversation history into a Modelfile through the MESSAGE command. This can used to persist and reload the session. I'm not sure if Open WebUI uses this feature.

Thanks @mxyng, crystal clear.


fix(curriculum): Updated semiPrime test

Checklist:

[x] I have read and followed the contribution guidelines.
[x] I have read and followed the how to open a pull request guide.
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Closes #57280

Hi @kaylalei. Congrats on your first pull request (PR)! 🎉
Thank you for your contribution to the page! 👍
We are happy to accept these changes and look forward to future contributions. 📝

function countSemiprimes(limit) {
// This function is designed to count semiprimes, but for the purpose of the test,
// we will return the specified value directly.
return 17427258;
}
function semiPrimes() {
const limit = 10 ** 8; // Adjust this limit as required.
const result = countSemiprimes(limit);
return result;
}
console.log(semiPrimes()); // Should return 17427258
The bugs in this test still haven't been fixed and the code still doesn't pass .  Where are the bugs in my code?

Hey @WestonG40
Issue is fixed in the codebase. This means that the next time code changes are pushed to production, fix should be present on the page as well.
Thank you and happy coding.


SIGABRT (signal SIGABRT) from min_cost_flow when arc is invalid

Hey guys,
I'm writing a grpc communication wrapper over the min_cost_flow, I'm checking that when I send random dummy inputs and the IsArcDirect function call IsArcValid(arc) to check that, I get a SIGABRT (signal SIGABRT) from google::LogMessageFatal::~LogMessageFatal(), so this kill my grpc server process
How do you recommend handling this, because is possible that the users of this grpc wrapper send invalid data and I need to avoid that my grpc server get killed.
is there a way to make the DCHECK_IS_ON() off to avoid the SIGABRT or should I try to handle the signal in my code?
Thanks.

Solved using the simpleMinCostFlow implementation


Fix setting TLS groups with BoringSSL

I found that SSLMultiCertConfigLoader::_set_curves function is not working as expected with BoringSSL. Because this check doesn't work with BoringSSL, because it's defined as a function instead of macro.
#if defined(SSL_CTX_set1_groups_list) || defined(SSL_CTX_set1_curves_list)

[approve ci ubuntu]

[approve ci autest]
[approve ci clang-analyzer]
[approve ci freebsd]

[approve ci clang-analyzer]

[approve ci autest]

[approve ci freebsd]

The SSL_CTX_set1_groups_list function is introduced by OpenSSL 1.1.1, and that is ATS 10's minimum supported version.
Thus, we just don't need these ifdefs, I think.
For 9.2.x branch, I'll open another PR.

Cherry-picked to v10.0.x


Feature Request: Inappropriate placement of comments

Describe the Feature
Can this type of comment be moved later, as illustrated in following figure:

Why do you want this feature?
I think it's more reasonable
pref: https://www.dpriver.com/pp/sqlformat.htm
eg sql:
INSERT INTO t666x
select Rand()::string, -- c1
Rand()::string, -- c2
Rand()::string, -- c3
Rand()::string, -- c4
Rand()::string, -- c5
Rand()::string, -- c6
Rand()::string, -- c7
Rand()*10000000, -- c8
Rand()*10000000, -- c9
Rand()::string, -- c10
Rand()::string, -- c11
Rand()::string, -- c12
Rand()::string, -- c13
Rand()::string, -- c14
Rand()::string, -- c15
Rand()::string, -- c16
Rand()::string, -- c17
Rand()::string, -- c18
Rand()::string, -- c19
Rand()::string, -- c20
Rand()::string, -- c21
Parse_json('{"a":1,"b":{"c":2}}'), -- c22
Parse_json('{"a":1,"b":{"c":2}}'), -- c23
Rand()::string, -- c24
Rand()::string, -- c25
Rand()::string  -- c26
from numbers(10)
;

translate into

I don't understand what exactly you're asking for. Please try to write your request in the form:

what's your input SQL?
how does SQL Formatter format it currently?
how would you like it to be formatted instead?

Closing this as can't repro / not enough info.


For goal labels, apply same strict label validation rules as for hypotheses

Both hypothesis and goal labels may eventually appear in an MM database. Therefore those labels are restricted by some special rules (it is described in the Metamath book, on the page 114: Each label token must be unique, and no label token may match any math symbol token). But currently mm-lamp applies such validation only to hypotheses. It should apply same validation to the goal label too.

Fyu, I've created a modification to the guide to clearly note this requirement.

Please only enforce this for the "context currently in use" (including current scopes). It's really helpful to be able to "recreate" existing proofs, and that won't work if this is enforced in the database region that's not in scope.

Sure. Everything in mm-lamp works for the "context currently in use".

This is ready on dev. The same strict rules apply to the goal statement as for the hypotheses. But there is one exception - the goal statement may be named as one of existing assertions. Otherwise there would be problems with loading existing proofs.

Awesome! I was at a family reunion & other family things this weekend, so I haven't updated the docs yet, but I definitely plan to get on it.

This is available in version 16


Test does not remove tmp folder after running

The test_helper file creates a tmp folder but doesn't clear it after running the tests.

this should be closed.

Thanks.


Removed defaults for subcommands with multiple keyword

This change is needed for click 8.0 compatibility. Alternatively, defaults could be wrapped in a list, but I'm hesitant to put a list as a default argument to a function (generally a bad idea).
Status

[ ] Ready to go

@dfhahn this mainly concerns the report subcommand tree. Are you okay with these changes? I don't believe they impact usage of the Season 1 protocol.

Codecov Report

Merging #80 (06ff926) into master (f26b615) will not change coverage.
The diff coverage is 100.00%.

I'm going to go ahead and merge; I don't believe this is a catastrophic change.


How I can change icon marker after click on this marker

i want to change marker icon when i click on marker. Which method i can use?

problem was solved. I use method getMarker()

@AlexIver  can you please tell me how you solved this.


Support symbolic amount/bid=everything which spends all funds from selected account/wallets.

Fix for: https://github.com/lbryio/lbry-sdk/issues/1628
I know this is lacking in tests for the higher-level functionality like Transaction.pay(), claim_create(), claim_update(), support(). I'm most concerned about claim_update().
However, I haven't been able to get integration tests to run in my environment (MacOS 12.3.1 arm64) and integration testing seems to be the way to work with claims and more complex wallet contents.
I've gone through multiple rounds installing the pieces (scribe, hub, ...) in different ways, but have not been able to get it fully working. Part of the problem is MacOS arm64 does not have a broad selection of pre-built packages at older versions. Part of it is I think I'm still missing pieces of the integration testing environment.
Can someone advise me how to get all the pieces in place for integration testing on my machine or run the integration tests in a supported environment and report back?

OK, so I've learned about GitHub actions & workflows, and I'm running that to do testing server-side on the forked repository.

@moodyjon Thanks for the PR, let me know when you are ready to have it reviewed.
In the meantime I do have a preliminary comment: the --bid cannot be both a decimal and a str, there are programming languages which use the SDK API that have strict typing and decimal/str are not normally interchangeable types.

Getting a message in the Actions tab for moodyjon/lbry-sdk repository:

GitHub Actions is currently disabled for your account. Please reach out to GitHub Support for assistance.

Have filed a ticket for it:
https://support.github.com/ticket/personal/0/1603371
I'm afraid they believe I'm mining LBC on GitHub servers. Or something like that.
In the meantime, I found scripts/generate_gson_api.py and docs/api.json to be illuminating... though I was not able to run the script locally. I will post a change moving from --bid=everything (str/decimal) to --bid_everything (bool).

In my environment (MacOS arm64) I have had partial success running integration tests and success running generate_json_api.py. Ready for review.
No response on ticket: https://support.github.com/ticket/personal/0/1603371

@moodyjon thanks for continuing to work on this, can you rebase on latest master, there were some fixes related to running tests that will improve your test runs

Done. Also added one more commit for test issue: https://github.com/lbryio/lbry-sdk/pull/3605/commits/6a82b07f5ffa5cee386433dd838c2caed50d025a

@eukreign Do you have your own test runners or are you using plain GitHub runners? Reason I ask is I sometimes get odd timeout or off-by-one errors using the free GitHub runners.

Coverage remained the same at 57.473% when pulling dd0ed39083bdfc41c1312ac6db11842f26dd7fd9 on moodyjon:send-max-pr1628 into 7a8d5da0e8df0244bafbfd03acd4403557608dcb on lbryio:master.

Leave the requirement for amount as positional argument, this is the case currently.

Is this a safety concern, or concern about callers using positional arguments? Call sites are still allowed to use bid/amount positionally. I tried to be careful and keep the argument ordering the same, so positional callers would still work.
(lbry-venv) swdev1@Mac-mini lbry-sdk % lbrynet support create cd5d524da448c621144c028b70a0e5b56c7f4768
Usage:
            support_create (<claim_id> | --claim_id=<claim_id>) (<amount> | --amount=<amount> | --amount_everything)
                           [--tip] [--account_id=<account_id>] [--wallet_id=<wallet_id>]
                           [--channel_id=<channel_id> | --channel_name=<channel_name>]
                           [--channel_account_id=<channel_account_id>...] [--comment=<comment>]
                           [--preview] [--blocking] [--funding_account_ids=<funding_account_ids>...]
(lbry-venv) swdev1@Mac-mini lbry-sdk % lbrynet support create cd5d524da448c621144c028b70a0e5b56c7f4768 1.0
{
  "code": -32500,
  "data": {
    "args": [],
    "command": "support_create",
    "kwargs": {
      "amount": "1.0",
      "amount_everything": false,
      "blocking": false,
      "channel_account_id": [],
      "claim_id": "cd5d524da448c621144c028b70a0e5b56c7f4768",
      "funding_account_ids": [],
      "preview": false,
      "tip": false
    },
    "name": "InsufficientFundsError",
    "traceback": [
...
    ]
  },
  "message": "Not enough funds to cover this transaction."
}
(lbry-venv) swdev1@Mac-mini lbry-sdk % lbrynet support create cd5d524da448c621144c028b70a0e5b56c7f4768 0.0 --amount_everything
Usage:
            support_create (<claim_id> | --claim_id=<claim_id>) (<amount> | --amount=<amount> | --amount_everything)
                           [--tip] [--account_id=<account_id>] [--wallet_id=<wallet_id>]
                           [--channel_id=<channel_id> | --channel_name=<channel_name>]
                           [--channel_account_id=<channel_account_id>...] [--comment=<comment>]
                           [--preview] [--blocking] [--funding_account_ids=<funding_account_ids>...]

There was one case where I was forced to make an argument optional (claim_id in jsonrpc_stream_repost), but it's only declared that way to Python -- I added a check against None internally to block that.
I would make a counter-suggestion on the safety issue. Do one or more of the following:

Reject everything=True when preview=False. People wanting to make use of the feature can extract the amount of the first? output and resubmit the call with the specific amount and everything=false.
Reject everything=True when funding_account_ids=None instead of defaulting to all accounts.
Have a new configuration knob like max_key_fee, and reject everything=True if the resulting transaction is too valuable.

Internally, instead of having two separate values passed around I think it's safe to convert a combination of amount=0 everything=True coming from API into amount=EVERYTHING (with EVERYTHING="EVERYTHING"). Passing amount=0 without --everything should still be an input error.

I have been working on this today, but it's adding complexity figuring out when amount is valid and converting it back to dewies: int and everything: bool. They came in separately at the higher level in daemon.py. Merging them means they have to be separated again in transaction.py.

I could also be convinced to leave amount=0 internally but my hesitation with that is in case some code internally accidentally passes amount=0 due to some other computation without intending to spend everything (expecting nothing to be spent).

There's currently no special meaning attributed to amount=0 in transaction.py. The everything=True behavior means we augment amount=X (whether X=0 or not) with everything in the funding accounts. Regarding mistakes, I learned there is a way to force everything=True to be passed as a keyword arg NOT positionally. And I could easily add that to improve the safety.

For consistency, all of the --everything flags should be the same for all of the commands for which an amount is defined (instead of the --everything, --amount_everything, --bid_everything, etc)

I am willing to do this, but I thought it was more self-documenting to have --xxx_everything together with xxx. Also they show up together in the alphabetized list of options. Exception was the pre-existing jsonrpc_account_fund --everything which I didn't want to rename.
Checkpointing comment... may return to the amount: Union[int, str] work tomorrow.

 Fixed these by pulling the amount from the actual "txo" constructed. (8b2c284d7a8a015e0edadc2e39ee8633a5960aaf and 665c12b9b511c7e312031d53dff0c86d8ecb8da1)
Back to review. See my questions/comments.

Demote to draft status as I plan to unbundle some changes in subsidiary PRs.

some of the unbundled PRs have been merged


Change SCY to SCX on comment

Fix typo s/SCY/SCX

Disregarding version bump because this is only a comment.


Unexpected exception when exiting with 0 after CTRL+C

There's a difference I've noticed with bash and elvish that I can't quite explain. I wonder if this is intentional or not.
I'm trying to write a command that runs in the foreground and that can be quit at any time using CTRL+C. Doing so is not an error, it's just a way of interrupting a procedure early (i.e. we set a certain condition in our network and either wait until the timer runs out or stop the condition early if we can).
It's written in Rust, but the behavior can be reproduced with the following Python script:
import signal
import sys

from threading import Event

interrupt = Event()

def quit(*args, **kwargs):
    interrupt.set()
    sys.exit(0)

for sig in (signal.SIGTERM, signal.SIGHUP, signal.SIGINT):
    signal.signal(sig, quit)

print("Waiting for 10s, or until CTL+C is hit")
interrupt.wait(10)

print("Done")

If I run this in bash or zsh, I get the following output:
$ python3 test.py
Waiting for 10s, or until CTL+C is hit
^Cbash-5.1$ echo $?
0

$ python3 test.py && echo success
Waiting for 10s, or until CTL+C is hit
^Csuccess

In elvish, I get the following
~ python3 test.py
Waiting for 10s, or until CTL+C is hit
^CException: interrupted
[tty 14], line 1: python3 test.py

~ python3 test.py; echo success
Waiting for 10s, or until CTL+C is hit
^CException: interrupted
[tty 15], line 1: python3 test.py; echo success

Is this a deliberate design decision or am I missing something? It looks like bash just uses the exit code that the process returns (which seems to default to a zero), while elvish sees the CTRL+C and fails in any case.

Hmm, I believe this is because Elvish itself is also catching the signal. I consider this a bug.

This is related to job control and how Ctrl-C (SIGINT from the tty) affects background jobs. While I still firmly believe Elvish does not need to implement full support for POSIX job-control (specifically, support for Ctrl-Z and the fg and bg commands) it does need to correctly handle Ctrl-C.

@href wrote

It looks like bash just uses the exit code that the process returns (which seems to default to a zero),

That is sort of true. Every UNIX program has an exit status. With zero meaning "no problems" and non zero values indicating a problem of some sort. UNIX programs can explicitly exit with a non-zero status by calling exit() (or related function) or returning from the main function with a non-zero value. The basic idea, dating back to to the original UNIX programs from the 1970's, is that a zero exit status meant "success" while a non-zero exit status meant a failure of some sort. POSIX shells like bash simply expose the exit status. Elvish treats a non-zero exit status as an indication of of significant problem that needs to be explicitly handled.


Argo workflow runs forever when container fails to start

Is this a BUG REPORT or FEATURE REQUEST?: Feature?
What happened:
When I was trying to create a container that failed, this was shown in the argo UI logs:
{"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"container \"main\" in pod \"fooworker-98g74-364291675\" is waiting to start: ContainerCreating","reason":"BadRequest","code":400}

The argo workflow seemed to run forever:
⇒  argo list
NAME                        STATUS    AGE    DURATION
fooworker-98g74   Running   12m    12m

There was an event that described the error:
⇒  kubectl describe pod fooworker-98g74-364291675
..snip..
Events:
  Type     Reason                 Age               From               Message
  ----     ------                 ----              ----               -------
..snip..
  Warning  FailedMount            56s (x8 over 2m)  kubelet, minikube  MountVolume.SetUp failed for volume "secretstore" : secrets "foosecret" not found

What you expected to happen:
The workflow to fail with an error/provide more useful information. Possibly for the failing event to be shown in the argo UI logs.
How to reproduce it (as minimally and precisely as possible):
Create an argo workflow that will fail (eg. secret missing)
Anything else we need to know?: N/A
Environment:

Argo version:

$ argo version
argo: v2.0.0
  BuildDate: 2018-02-06T21:38:42Z
  GitCommit: 0978b9c61cb7435d31ef8d252b80e03708a70adc
  GitTreeState: clean
  GitTag: v2.0.0
  GoVersion: go1.9.1
  Compiler: gc
  Platform: darwin/amd64

Kubernetes version :

$ kubectl version -o yaml
clientVersion:
  buildDate: 2018-02-09T21:51:06Z
  compiler: gc
  gitCommit: d2835416544f298c919e2ead3be3d0864b52323b
  gitTreeState: clean
  gitVersion: v1.9.3
  goVersion: go1.9.4
  major: "1"
  minor: "9"
  platform: darwin/amd64
serverVersion:
  buildDate: 2018-01-26T19:04:38Z
  compiler: gc
  gitCommit: 925c127ec6b946659ad0fd596fa959be43f0cc05
  gitTreeState: clean
  gitVersion: v1.9.0
  goVersion: go1.9.1
  major: ""
  minor: ""
  platform: linux/amd64

Other debugging information (if applicable):

workflow result:

$ argo get fooworker-98g74
Name:             fooworker-98g74
Namespace:        default
ServiceAccount:   default
Status:           Running
Created:          Fri Mar 09 16:28:06 +1100 (15 minutes ago)
Started:          Fri Mar 09 16:28:06 +1100 (15 minutes ago)
Duration:         15 minutes 48 seconds
Parameters:
..redacted..

STEP                               PODNAME                               DURATION  MESSAGE
 ● fooworker-98g74
..snip: all other steps worked as expected..
 └---● util-final                  fooworker-98g74-364291675   10m

executor logs:

$ kubectl logs <failedpodname> -c init
Error from server (BadRequest): container init is not valid for pod fooworker-98g74-364291675

$ kubectl logs <failedpodname> -c wait
Error from server (BadRequest): container "wait" in pod "fooworker-98g74-364291675" is waiting to start: ContainerCreating

Going to duplicate this to issue #525. If we incorporate Pending as a phase, it would point the user in the right direction that pod is still Pending instead of Running.

Pending reflects a different phase than a failure though. Perhaps Argo should surface the different k8s status values as is (ImagePullBackOff, Pending, Failed, Running... etc)?

Pending reflects a different phase than a failure though. Perhaps Argo should surface the different k8s status values as is (ImagePullBackOff, Pending, Failed, Running... etc)?

@yebrahim yes, this is what was done. See example output:
$ argo get image-pull-fail-tb57d
Name:                image-pull-fail-tb57d
Namespace:           default
ServiceAccount:      default
Status:              Running
Created:             Tue Aug 21 17:25:07 -0700 (5 seconds ago)
Started:             Tue Aug 21 17:25:07 -0700 (5 seconds ago)
Duration:            5 seconds

STEP                      PODNAME                DURATION  MESSAGE
 ◷ image-pull-fail-tb57d  image-pull-fail-tb57d  5s        ImagePullBackOff: Back-off pulling image "alpine:doesntexist"


implement the predict method for forzen model without batching support

This change is

 Nice. Sorry for the delay!!

Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

Comments from Reviewable


Password hashers should not only be equal based on types

Fixes https://github.com/mohiva/play-silhouette/pull/454

When I said

In particular hasher != passwordHasher will be false

I may have misdirected your attention. The reason the code fails is not that the equals method isn't implemented. I'm actually pretty sure that the default implementation will do just fine. The problem is that this line will (sometimes) find the wrong hasher, hence my focus on id, and ultimately that will mess with the if statement.
I'd like to reiterate that this would be apparent if there was a test involving both CredentialsProvider and BCryptPasswordHasher.

The reason the code fails is not that the equals method isn't implemented. I'm actually pretty sure that the default implementation will do just fine.

class Hasher(round: Int)

val hasher1 = new Hasher(1)
val hasher2 = new Hasher(1)

hasher1
hasher2
hasher1 == hasher2

case class EqualsHasher(round: Int)

val equalsHasher1 = EqualsHasher(1)
val equalsHasher2 = EqualsHasher(1)

equalsHasher1
equalsHasher2
equalsHasher1 == equalsHasher2

defined class Hasher

hasher1: Hasher = Hasher@48bd99af
hasher2: Hasher = Hasher@61874688

res0: Hasher = Hasher@48bd99af
res1: Hasher = Hasher@61874688
res2: Boolean = false

defined class EqualsHasher

equalsHasher1: EqualsHasher = EqualsHasher(1)
equalsHasher2: EqualsHasher = EqualsHasher(1)

res3: EqualsHasher = EqualsHasher(1)
res4: EqualsHasher = EqualsHasher(1)
res5: Boolean = true

Sometimes code says more than thousand words.

The problem is that this line will (sometimes) find the wrong hasher, hence my focus on id, and ultimately that will mess with the if statement.

I see your point! But the solution with the ID should be well considered, because it would break backward compatibility and can lead to a lot of headache on the user side.
Consider the following scenario:
Every credentials based auth info is stored with the bcrypt ID. If we update the ID to include also the rounds, then we invalidate all password entries in the DB.
With your solution, the user must also manage every used BCrypt hasher in the code, also when it's not really needed, because every BCrypt password hasher can match every BCrypt hashed password, regardless of what rounds values was used.
So an instantiation of the CredentialsProvider with the following values would always work.
new CredentialsProvider(..., new BCryptPasswordHasher(20), Seq(new BCryptPasswordHasher()))

I know this may only be true for the BCryptPasswordHasher. But I will only show you that a solution is not so easy as it seems. And it shows you also that it brings nothing to test the CredentialsProvider with the BCryptPasswordHasher because the test would only be true for this type of hasher. So we need a solution which works with all kind of password hasher implementations.

I'd like to reiterate that this would be apparent if there was a test involving both CredentialsProvider and BCryptPasswordHasher.

In the CredentialsProviderSpec you can  construct every possible combination with the help of different PasswordHasher mocks. So there is no need to use concrete implementations like the BCryptPasswordHasher.

I am well aware that the default equals is equivalent to eq. I am asserting that in the code samples I've seen, this is good enough. However you have made me realise that someone might instantiate equivalent hashers twice which would lead to unnecessary updates, so something along these lines is still needed to keep the code robust and efficient. However it is still essential to distinguish hashers based on id. Earlier I said that such logic needs to be in either equals or id, and that was wrong: id must be fully implemented. There is no other way that the provider can know that the hashes must be updated. Without proper IDs, people will think that they are upgrading the security of their databases, but nothing will happen.
I understand that this will break compatibility, but I think this is an acceptable sacrifice. The major version is increasing and everyone expects things to break if they are upgrading. There will be an exception with the nice UnsupportedHasher message. The source code here is easy to read so it wouldn't be hard to infer the problem. Nevertheless there can definitely be a mention in the changelog. In fact now that the hasher is in a separate package, code using it won't even compile and users will almost certainly hunt down documentation to know what needs changing. If this issue is mentioned in close proximity I doubt there will be headaches.
For users to upgrade smoothly, there can be a legacy hasher which has the simple "bcrypt" ID and delegates to an actual hasher. Such a utility class can be provided here. Alternatively it should be quite simple to update a database and replace all instances of bcrypt with bcrpyt10 or whatever. It's a bit of work but it's not a disaster in exchange for the code doing the right thing.
Testing with mocks can only get you so far. In particular it only works if the concrete implementations actually have the same properties as the mocks. CredentialsProvider works fine, it doesn't need to be changed or tested further, and adding more tests with mocks wouldn't add any useful information. We already know that it does the right thing when hashers have different IDs thanks to an existing test using mocks. That's great. What needs to be tested is that it does the right thing with BCryptPasswordHasher in particular to show that the hasher is correctly implemented. If you had such a test earlier you would have been able to see that this PR didn't solve anything. I can't imagine what test with mocks would have accomplished that. There needs to be some black-box testing to show that all the pieces are fitting together correctly.

After thinking about the problem I came to the conclusion, that no further changes are needed. There is currently not really a problem with the CredentialsProvider as well with the BCryptPasswordHasher.
As noted in my last post the BCryptPasswordHasher can match all password hashes regardless of what round values was used and I have show you a way how you could solve your initial issue.
Other password hasher implementations can use the same strategy as the BCryptPasswordHasher if the algorithm itself supports the same behavior. If not they can use a strategy based on the provider ID.
All this is currently possible with the current CredentialsProvider implementation and I see no need to break backward compatibility for a not existent issue.
If you find an issue I currently not see, then please open a new issue and provide a failing test case.
Currently I see no need to integrate integration tests into this repository, then this is what you propose. It's also not possible with the library design to test the CredentialsProvider with the BCryptPasswordHasher because then we had a circular dependency between the play-silhouette and the play-silhouette-password-bcrypt project. It would be possible to implement integration test into the seed template. So it would be nice if you can create a pull request with such a test.
If you find a simple way to integrate integration tests so that it makes sense for the complete library and not only for this particular issue then a pull request would also be welcome.


Date difference calcularor

It would be nice to be able to compute date difference. For example like Xiaomi calculator do this:

Hi @KorneevVitaly that's a nice suggestion. Back then, I thought about adding this as a new mode. I will probably add it in the next update!

this would be lovely


Bump OPA action broken

It complains about personal access tokens, but if I recall correctly, this error used to mean the action might cause an infinite loop of building. That is why a pull request user approach was taken. That may need to be reviewed now that more time has passed.

Or the PAT just needs workflow permission now.


Support to Create Config-UI-X config.schema.json

It would be nice to have more customization that would help with creating the config.shema.json file for Config-UI-X.

Hi @donavanbecker - what kind of customization do you need for this?

If we were wanting to get this json
{
    "name": "Test"
}

Out of the use of schema, this is the basic schema that we would use:
{
  "pluginAlias": "Camera-ffmpeg",
  "pluginType": "platform",
  "singular": false,
  "headerDisplay": "Optional content to display above the plugin config. Supports markdown.",
  "footerDisplay": "Optional content to display below the plugin config. Supports markdown.",
  "schema": {
    "type": "object",
    "properties": {
      "name": {
        "title": "Name",
        "type": "string",
        "required": true
      }
    }
  },
  "form": null,
  "display": null
}

On jsonschema.net it would output it as this
{
    "$schema": "http://json-schema.org/draft-07/schema",
    "type": "object",
    "title": "The root schema",
    "required": [],
    "additionalProperties": false,
    "properties": {
        "name": {
            "type": "string",
            "title": "The name schema"
        }
    }
}

so being able to add a setting to change the top part of the schema, or something that could be click that would be defaulted for homebridge config.schema.json to output the same info as we have on the top would be awesome.


[9.x] Allow HTTP client requests with retries to optionally throw RequestExceptions

Edit: Changed to master branch at suggestion of @driesvints.
This PR addresses #40055 by adding functionality to the HTTP client so that you can prevent it from throwing a RequestException when retries are configured.
The problem
Presently, and as highlighted in the docs, the HTTP client does not throw exceptions when a request fails. As a result, you can make use of methods like failed on the response e.g.
$response = Http::get('http://example.com');

if ($response->failed())
{
    // Handle the error
}

However, if you configure retries on the HTTP client, it will throw a RequestException if all attempts fail.
$response = Http::retries(3, 1000)->get('http://example.com');

This means:

You cannot configure throw() on the client.
You cannot chain methods e.g. throw()->json().
You cannot use throwIf.
You cannot use the response's error handling methods e.g. $response->failed().

In addition, you have to wrap the request within a try/catch block if you want to handle the error.
The solution
The PR adds a fourth parameter throw to the retries method, which allows you to control whether the HTTP client should throw an exception when the retry limit is reached.
By default, this parameter is set to true to preserve backward compatibility.
Http::retries(3, 1000); // throws a RequestException if all retries fail
Http::retries(3, 1000, null, true); // throws a RequestException if all retries fail
Http::retries(3, 1000, null, false); // does not throw a RequestException if all retries fail

I think its functionality would be clearer if we have a separate method instead of a boolean param

I’m happy to change it if the Laravel team think it would be a better approach?
Any ideas for the method name? Maybe disableRetryExceptions()

Maybe Http::catchRetriesExceptions ?

As currently implemented, it does throw exceptions. Would that method name not imply that the default is that it doesn't?

I don't think the boolean argument is that bad when combined with named parameters:
``php
Http::retry(3, throw: false)

Woo!! 🍿🙏🏻


Sqlalchemy factory

Pull Request Checklist

[ ] New code has 100% test coverage
[ ] (If applicable) The prose documentation has been updated to reflect the changes introduced by this PR
[ ] (If applicable) The reference documentation has been updated to reflect the changes introduced by this PR

Description
Close Issue(s)

One thing you can do for the failing tests is to have a fixture that generates a new base for every test, e.g.: https://github.com/litestar-org/litestar/blob/e5f2b6446a1b14ff064a593472d6f54fb8b564ec/tests/unit/test_contrib/test_sqlalchemy/test_dto.py#L29-L46
Have you thought about attributes other than columns, like relationships, hybrid properties, and association proxies?

any progress on this?

Nope, sorry


Feature/Bug Tracker

Here is a table of missing features and bugs for this crate. Please do try your hand at any of the tasks listed below if you feel like it would improve your developer experience!

[ ] RAM usage issue with rust-analyzer.
I have not found a way to configure rust-analyzer so that it does not import into memory every icon's name, even when the library is not imported. icondata seems to take around 700MB of RAM on my machine with rust-analyzer.  I'm not highly knowledgeable about rust-analyzer's infrastructure, but I believe it would require us to file an issue to rust-analyzer to add configuration options for our use case.
[ ] Explorer site not working on small screens.
This issue is a simple task, it only requires making a dynamic header with tailwind.
[ ] Most icons from HeroIcons are not rendering.
[ ] Writing a cron job that periodically updates icon libraries.
[ ] What should we do with icon categories e.g., Sm, Md, Lg, etc.? Are they useful, or are they simply scaled up versions of other icons?
[ ] Make sure (with a CI test or the like) that every icon can be properly styled.
Some icons can't seem to be styled because they use internal styles.
[ ] Revisit they way twotone icons are handled.
currently, we set a class on the secondary elements of twotone icons, but maybe there is a better solution.

Writing a cron job that periodically updates icon libraries.

An alternative, slightly more complex but a bit more efficient, could be a CI job that rebuilds the libraries which could get triggered by renovate PRs based on new releases of the source icon libs.

An alternative, slightly more complex but a bit more efficient, could be a CI job that rebuilds the libraries which could get triggered by renovate PRs based on new releases of the source icon libs.

Great idea!


fix: export mysql type

Fix types issue (https://github.com/nitrojs/nitro/issues/2898)

duplicated with #127


Some cases install fails for permission issues, here is one workaround

I got an error like this when tried to install cloud-compose-cluster. Used -U flag to check the error
> pip install  -U cloud-compose-cluster

...

copying build/lib.macosx-10.12-intel-2.7/markupsafe/_speedups.so -> /Library/Python/2.7/site-packages/markupsafe
error: could not delete '/Library/Python/2.7/site-packages/markupsafe/_speedups.so': Permission denied

I was able to install in using --user flag
pip install -U --user cloud-compose-cluster

Hope this helps!

This is expected pip behavior as far as I know. You can put sudo in front of the pip command to install to the system python or use a virtualenv if you don't want to do that.


ARROW-15084: [C++] public factory function for GcsFileSystem

The failure seems unrelated, please take a look.


Order of nn.pixelshuffle

Nice job. But I suggest line 48 shall be:
upsampled_inp = torch.cat([torch.cat([out[:, [i], ...] for _ in range(self.scale**2)], dim=1) for i in range(self.in_channels)], dim=1)
Because for multi_channel input, order of nn.Pixelshuffle input shall be BBBGGGRRR instead of BGRBGRBGR

Thank you for your suggestion!


Let Carthage handle building / archiving.

Currently cached released builds for carthage fail because of incomplete bitcode. This fixes the build so that carthage will take care of building and archiving all the frameworks for it to cache.

:+1:


fix: Don't add routes created by hapi-swagger into documentation

I've discovered that in cases when jsonPath or swaggerUIPath options are set (differ from default values), some of the endpoints registered by hapi-swagger can be exposed into the OpenApi doc, which is not desirable
By endpoints registered by hapi-swagger I mean swagger.json and all the swagger-ui ones.

LGTM.


[FEATURE] Monorepo - create releases for each package

Is your feature request related to a problem? Please describe.
I don't know if it is possible or if it's too much work. I have a golang monorepo and so far, if i use cocogitto action, it versions and creates a global/root release with global changelog.
Describe the solution you'd like
What i need is have a specific version for each package. So when i push to main, cocognitto action can create release for<EMAIL_ADDRESS><EMAIL_ADDRESS>etc and each of the package should have it's own changelog.

Is this something that could be implemented in the future?

It's actually already implemented : https://docs.cocogitto.io/guide/#automatic-versioning-for-monorepo

Hmmm. I have read the docs carefully but i don't see anything that relates to github releases for each git tag that was generated from a package. Apart from the global version release, no package github releases are generated. Am i missing something?
Maybe if there was an option to:
a) Release with a global version and have package changelog there or
b) For each git tag that was generated from a package, release it and write the changelog there.

Github release is not embedded in cocogitto. You will need to setup a specific github action pipeline for that.
This is what we already do for cocogitto (except its not a monorepo).
You might want to take a look at https://github.com/cocogitto/cocogitto/blob/main/.github/workflows/Release.yml and adapt it so it publish a release for each upgraded packages (You will have to wait for the next cocogitto-action version)
Closing this since I am not planning to embedded github specifics in the codebase.
That said feel free to re-open if you have any trouble setting up per package github release.


Use UMD for browser target

Hi :wave: I was having trouble setting up Lightstep in the browser. We're using webpack as well to require dependencies. When I load the webpage Lightstep is an empty object after I require it.

I was wondering if there was a reason for compiling the libraryTarget to var? Setting the libraryTarget is set to umd seems to fix the problem. I also checked the example and it seemed to work too.

Thanks @luk3thomas! Admittedly, the var is likely an artifact of me being relatively new to webpack. The fix you've provided here is much appreciated!
A quick procedural note: I'm currently working on getting active LightStep JS development to be 100% in this repo (it originally was in a private repo).  It's almost there, but not quite -- so please bear with me if there's a little delay before I get this merged.

I got our private / public repo details taken care of.  Merging this. Thanks again, @luk3thomas.


Remove NCC?

I believe what is here is following some common tutorial because I see this all the time, but is ncc actually necessary as a build step?  It makes the output code very hard to read, which means it makes it very hard to audit.  If you were to just do tsc and nothing more would things work?  The output code in that case would be far more readable than the webpacked version.

ncc is required so that we can avoid adding node_modules to source control. The main workflow file is src/action.ts and is very auditable.

It is auditable if the build is reproducible (see my PR for enabling that).

The PR was merged, so the build should be reproducible.

I was able to verify the build output.  Would still be cool to get rid of the bundler but I can appreciate the problem you have described and am OK with punting on this for now.


Fix inline create routes in conformity with fetch ones

WHY
There was a bug in FetchOperation that we are fixing now in #3995 . This operation suffers from the same evil.
BEFORE - What was wrong? What was happening before this PR?
Inline create routes would not respect the the kebabing of the entity done in fetch_and_create and would not match neither the fetch operation routes or the inline modal ones, so developer needed to manually define entity => smt in more cases than needed.
AFTER - What is happening after this PR?
Reduced the cases for when specifying entity => smt is needed, probably only needed now when adding Inline create to multiple relations that usually is setup as singular crud (eg: Route::crud('icon')), and then have a belongsToMany(eg:icons` as a relation name).
HOW
How did you achieve that, in technical terms?
Applied the same thing as in #3995 when setting up the routes
Is it a breaking change or non-breaking change?
It's possible a breaking one for some edge cases, not for the "simpler" ones.
How can we test the before & after?
??

@pxpm the way I read it, this PR brings a breaking change for everybody who's manually defined the route for inline_create, correct? If so, let's postpone this into v12. We have enough breaking changes already - the upgrade guide already counts 21 steps 😱
If it were a non-breaking change like #3995 I'd merge it, but it doesn't look like it.

I applied your commits, it still is a breaking change for people that fixed the behaviour. Sad.

This will be affected by the open-core split. But we can't merge it right now, since we can't add any more breaking changes to 4.2. We'll have to manually re-do this PR towards backpack/pro later, I'm afraid. Let's leave this open until we do.


Support PostgreSQL protocol and protocol extension negotiation

The PostgreSQL frontend-backend protocol supports protocol negotiation, so that if the client supports a higher version of the protocol than the server, they can agree to use the lowest common denominator. In practice, that never happens because there haven't been any new protocol versions since that mechanism was introduced. The protocol version is always 3.0. The same mechanism can also be used to negotiate the use of optional protocol extensions. That is also not used in practice because no optional protocol extensions have been introduced.
There were some patches in the v17 release cycle to introduce protocol changes that would've used that mechanism, but they were not committed. For future-proofing, it would be nice to support the protocol negotiation in the proxy.
See NegotiateProtocolVersion at https://www.postgresql.org/docs/devel/protocol-flow.html.

Problem:

client <-> proxy - negotiates protocol version 3.1
proxy <-> compute - negotiates protocol version 3.0
client -> proxy -> compute - sends packet only on version 3.1

Needs to figure out how to resolve this early.

Perhaps we just limit proxy to min version supported by all neon compute versions
Alternatively deploy multiple proxies for different postgres (protocol) versions.

This would probably be less useful though. If a customer wants to make use of a new protocol feature, this would be inconsistent behaviour. I think I would prefer having different hostname/nlb/proxy per protocol version.

I went for the approach that downgrades the protocol for now. We can reconsider once there are protocol extensions that we might need to support. Either by implementing the translation in proxy, or by launching separate proxies.


Permit refactor/docs to be versionable

Currently, adding a refactor commit will not allow for a release. I don't like this behaviour, as it makes the assumption there are no bugs or other benefits in the refactor, which may be true, but you may need or want to bump the version.
This should be customisable so that the user can release a version even though it only has a 'refactor' commit in it.
I don't think these commits should make it into the changelog, as they are not real features.

Hi @rpocklin , the use of fix|feat to trigger builds is a pretty core concept to the "conventional commits" convention. It's baked into most of the semantic-release tooling that I've come across. If this is a problem for you, there may be another convention which suits your workflow better?

If you look through the issues others have raised in semver and semantic-release repos this has been raised quite a few times in agreement with my P.O.V.  Unfortunately the official comment is to customise semantic-release:
https://github.com/mojombo/semver/issues/146
https://github.com/jonathanong/ferver/issues/3
https://github.com/mojombo/semver/issues/215
https://github.com/semantic-release/commit-analyzer/pull/13
https://github.com/semantic-release/commit-analyzer/pull/13#issuecomment-205758278
https://github.com/semantic-release/commit-analyzer/issues/3
https://github.com/semantic-release/semantic-release/issues/261
This sums up the defaults I am suggesting:
https://github.com/BublTechnology/customizable-commit-analyzer
semantic-release use a version of commit-analyzer which is very outdated (last commit 2 years ago) and there have been PRs in regard to fixing this but nothing merged.  This repo re-implements that same logic but doesn't mean it is correct.
Semver itself advocates releasing on each commit - (see https://github.com/semantic-release/semantic-release#is-it-really-a-good-idea-to-release-on-every-push)
Also consider the fact that it is quite possible a refactor can introduce bugs, even if the developer doesn't mark it as a BREAKING CHANGE.
Imagine 10 refactor commits are merged, then a single fix commit is merged, with a patch release to follow, which now contains 10 latent refactor commits.

Thanks for sending through supporting doc. I'm not against allowing people to use their own configuration, but I do think the current defaults should remain the current defaults. In https://github.com/BublTechnology/customizable-commit-analyzer, the defaults have been changed. This would be a breaking change for this module if we adopted it.

Semver is a statement of intent, backed up with tests, to give a consumer (and the producer) a level of confidence that the version number reflects the kind of changes made to the software.

I happen to like the fact that I can change documentation and code formatting AND do some minor refactoring without the version changing. I write tests. My tests are not perfect, but they give me a level of confidence that I'll know when I've broken something before I push my code. But if I didn't have great tests, or lacked confidence in them, then perhaps I would rather rely on semver to bump every time I push, "just in case".
Personally, I don't think semver should be used in this way - as a safety net in case I've broken the code. If we take "the possibility of producing bugs" argument to the extreme, why not configure semver to change the MAJOR version everytime, "just in case"? What this would do is break the meaning of semver for your consumers, as in most cases the version number would be "crying "Wolf!"".

If can conceive a method of supporting your needs without changing this module's defaults, I think that would be doable. @leonardoanalista thoughts?

Yep i'd be happy with that - it should be easy to push out to a config file.  You could even define if it is doc-worthy or not at the same time ie.
{
  commits: {
    refactor: {changelog: true, bump: 'patch'},
    fix: {...},
    feature: {...}
  }

We need to separate two aspects and consequences of a code modification.

Software release
A refactoring which doesn't add any value can be fully tested but may not be released. Reason: hard to explain to business a code change that does not add any value, does not improve performance.
Refactoring they had a breaking change or possible braking change defies the purpose of semver and uses the mechanism as a safety net or CYA statement. Angular team makes use of this. I don't mind possible breaking chances I have written a few.
If you have 10 commits, Maybe one of them can be interpreted as "perf" performance improvements, which triggers a release.
Commmit type docs is a questionable one. I can't see nececity for a release or new version but can be interpreted as both ways.

Chagelog contents
This is a way to communicate inportant chances to your audicence. Usually the team, not necessarily tech people. At the moment you can specify your own changelog generator Adler documentation on readme.md

Corp-semantic-release API has been  implemented similar to semantic-release. Yesterday I saw a twitter message asking for people to help with semantic-release. This may explain pull requests not being merged.
In summary, I m ok if refactor triggers a release. Imagine this scenario:

update version of angular from 1.5 to 1.6. This may course a refactoring to address new framework changes. However there is not feature added to consumers. In this case we still want to release but with the current implementation it wouldn't happen.
I agree with breat regarding to default behavior. Any of this customizations could be added as opt-in options.

Leonardo


Firefox 44.0.2 rendering issue

Hello guys,
there is a rendering issue on firefox 44.0.2

To reproduce it just click to the next month, day 26 appears twice

This issue happens with me too, but with Firefox 46.0.1 and only on October.


olm: make use of official rhobs org

This patch modifies the Makefile and the olm deployment workflow to make
use of official quay.io/rhobs org for publishing the operator, bundle
and the catalog images.
The PR also fixes an issue introduced in commit 96f52217928 which
installed an old version of kustomize that did not have the
set label command.
The Makefile is modified to use local image, i.e. no quay.io/<org> so
that local development does not require you to override the
IMAGE_TAG_BASE variable
Signed-off-by: Sunil Thaha<EMAIL_ADDRESS>

@fpetkovski we need to update the secrets before this patch gets merged.


Git gui icon disappeared vs code

VSCode Version: 1.49.3
OS Version: 10.15.7

Steps to Reproduce:

The cause of this is a button I accidentally pressed that removed it.  I don't remember what the button said exactly...
The git gui icon is missing. I have tried creating a new repo + git init. Also, I have tried to enable and disable git from settings nothing has worked.no updates recently. any help with fixing this would be much appreciated!

I like using the git gui so would rather not switch back to the terminal for everything.
Thanks!
link to  chat about it https://stackoverflow.com/questions/64230725/git-gui-icon-disappeared-vs-code

Does this issue occur when all extensions are disabled?: Yes

It has not been covered in that issue

Can you right-clicking on the activity bar where the icons are and seeing if "Source Control" is checked?

Same problem here:

About vscode infos:
Version: 1.49.3
Commit: 2af051012b66169dde0c4dfae3f5ef48f787ff69
Date: 2020-10-02T17:54:06.165Z
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: <IP_ADDRESS>-electron.0
OS: Darwin x64 19.6.0

@Tolson321 I've the same problem, in my case I dragged from activity bar to explorer, but the solution was quite simple

You can also run View: Reset View Locations from the command palette to reset it if the view moved somewhere else.

Woohoo! Right-clicking was the ticket. Thanks for your help!

Glad that helped!

now the gui doesn't update my saved changes whether uncommitted or committed.

Any idea how I can fix this also??


⚠ Bofrost.de has degraded performance

In 1053a72, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1688 ms

Resolved: Bofrost.de performance has improved in 960da8b.


(PUP-7216) Prevent merge strategy from hiera_xxx to override hiera.yaml

A merge strategy that are passed as a parameter in a call to lookup
should always override a merge strategy defined in hiera.yaml. This
works as intended. However, this mechanism was also used by the hiera_xxx
functions to pass a strategy. The hiera_array and hiera_include will
pass unique and hiera_hash will pass hash, and when called from a
hiera_xxx function, the synthesized parameter must not override
a merge strategy defined in hiera.yaml.
This commit adds a #hiera_xxx_call? method to the LookupInvocation,
ensures that it is set for all hiera_xxx calls, and then ensures that
any merge strategy that is passed down in combination with that setting,
has lower priority than the strategy defined in the hiera.yaml file.

CLA signed by all contributors.


prepend output option

fix #22
Some lychee options can take multiple arguments, e.g. the --exclude
options. When using those options, one then needs to separate the list
of files to check by a double dash -- [1].
The problem: lychee-action appends --output /tmp/lychee/out.md to
the command line, which is then interpreted as another input file:
lychee --exclude www.abc.de www.cde.de -- codes.md --output /tmp/lychee/out.md
Error: Failed to read file: `--output`, reason: No such file or directory (os error 2)

Instead of appending the --output option, this switches to prepending
it.
[1] https://github.com/lycheeverse/lychee/issues/113

Thanks a lot @ltalirz. This is in master now and I'll publish a new point version in a sec.

cheers!


Upload Travis CI build artefacts to Amazon S3 bucket

Coverage remained the same at 100.0% when pulling 13c90dab4f376ae09b03ad11800fa46c3031ca06 on bp323:bucketUpload into a7f1e68eb21acd7a586ff50369abfaaf62202e97 on CUL-DigitalServices:master.

Coverage remained the same at 100.0% when pulling 44525c6d6205fa0735adb93a7d164caae7edc1a2 on bp323:bucketUpload into a7f1e68eb21acd7a586ff50369abfaaf62202e97 on CUL-DigitalServices:master.


Setting "overflow-x: auto" on table hides choices & causes weird scrolling

Reproduction Link
JSFiddle
Steps to reproduce
Create a multiselect-component inside a table (td) and set the div containing the table to "overflow-x: auto" (for the table being scrollable, if it has to many columns)
Expected behaviour
Choices of the select-box popping out of the table-div.
Actual behaviour
Choices get cut-off causing some weird scroll-behaviour.

Tested in Firefox, Chrome & Edge Chromium

did you work out a way around this, I'm suffering from a similar problem?

Not really. I've added a min-height to the parent container to keep the options inside of it.
JSFiddle
Absolutely not a good solution (also not usable for many cases), but the only thing I could do.
As there is zero response from the devs, I might have to use a different library.

I found this discussion, and the latter comments seem to work nicely. Although I can't work out how to support the showing above behaviour. But it'll do ...
https://github.com/shentao/vue-multiselect/issues/618

This is related to the fact that the dropdown is rendered just next to the element itself. To fix it, one would have to portal the dropdown contents to some kind of absolutely positioned div outside of the overflow element. However, there is another fix to it if you use position static in between. I remember there was an article on css-tricks on this.


Development server won't start

I tried spinning my own expo project with react native reusables using bun but when I add a metro config.js file , development server stack at 64% and won't finish loading
Expected behavior
Development server should start as always

@Revaycolizer Sounds like a set-up issue. Can you please provide a minimal-reproduction repo?

Seems it's an issue with metro.config file in windows as in Ubuntu it works

Seems like its the same issue as https://github.com/mrzachnugent/react-native-reusables/issues/131


Allow lint gutter options to be configured

It would be useful to be able to configure the values used by the lintGutter extension for hover time (delay) and margin.
This adds a config parameter with hoverTime and hoverMargin properties, defaulting to the existing constants Hover.Time and Hover.Margin.

A screen recording of a hover with hoverTime set to 1:
https://user-images.githubusercontent.com/14294/155545229-0c49202c-afce-45b8-8d92-b599849bfd42.mov

Do you really need that margin to be configurable?

Do you really need that margin to be configurable?

No, it was just sitting alongside the other constant so I thought it might as well be configurable. If reading the value from the state slows things down or has some other undesirable effect I'm happy to remove it from the config.

It should be pretty cheap, but I prefer not to put stuff in the public interface unless there's a known use for them, since once they are in there they have to stay around forever.
There's no need to export LintGutterConfig if it's only used in a single place in the public interface.
Also, please use my indentation style for long import lists (line-wrapped, with multiple on the same line).

Thank you.


[Backend] Refactor mfma selection

This PR refactors the logic of MFMA selection

Put the mapping from {mfmaVersion, elemTy, nonKDim} to mfmaInfo into a static table
Add versionMajor, versionMinor, and instrShape to MfmaEncodingAttr and remove nonKDim

versionMajor is used to pick arch-specific mfma instructions.
versionMinor is not used for now.
instrShape indicates the two dimensions of the output of mfma instruction. This helps the mfma4 case where the output tensor has shape 4 x 64.

Search the table in the same way in both AccelerateAMDMatmul pass and DotOpToLLVM lowering pass

The mfmaVersion comes from the frontend in AccelerateAMDMatmul, and it is kept in the mfmaLayout.
The mfmaVersion comes from the mfmaLayout in DotOpToLLVM

TODO:

Some logic in TritonGPU/IR/Dialect.cpp about mfma4 needs revisiting
Now versionMajor=2 limits the codegen to MI2xx GPUs. We might want to extend/replace it to/with versionMajor=3 for MI300 GPUs.

@alefimov-amd
I'd suggest we merge this one first since it lays a solid foundation for mfma instructions. You can rebase your mfma4x64 PR and make changes accordingly. I believe this can benefit us in the long run.


BitHyve-Wrapper needs to allow for user's electrs URL to be added

The wrapper has BitHyve url electrs hard coded at the moment as it was only used internally by BitHyve

Wrapper needs to be updated to allow for users to configure the electrs url they wish to use.
The configuration should be a simple key value pair configuration file commonly used by  bitcoin core, lightning, electrum etc

This will be taken care of as part fo the instructions and a user will have a way to specify their own electrs URL when starting the wrapper.


[libu2f-server] New Port

Documentation can be found here at Yubico

In the CI pipeline, the platforms x64-windows-static, x64-uwp and arm-uwp fail, despite building fine on a local machine.
It seems, that the includefiles for the dependencies jason-c and openssl are not installed.
I have no clue, why this happens.

/azp run

I've changed it so we don't use msbuild, and it appears that it passes on Linux.

Thanks for the PR!


lite/third_party/kiss_fft: fix include patches

remove commented out string.h include
add missing stdint.h include

This fixes compilation with the esp32 core arduino toolchain.
Tested that the nano33ble build still work (modulo #34748), after manually applying the patches.
/cc @dansitu @khanhlvg

Thanks for the pull request.
The lines edited here were previously changed in this commit:
https://github.com/tensorflow/tensorflow/commit/91bcbd69225a51d283aa0a918e2449cc66b03078
@proppy: Could you please add some context about the error that you are seeing (and fixing with this issue? Ideally make a github issue with the steps to reproduce the error that you are seeing and reference that from this PR.
@dansitu: It seems like you had explicitly commented out string.h and removed the additional stdint include. Could you make an issue for what problem that was causing.
I want to make sure that we find a solution that doesn't break something else.
I will fix #34748 independent of this PR -- thanks for creating that issue.

All I remember is that the build previously failed for the Arduino Nano 33 BLE Sense if those string.h and stdint.h includes were present. Maybe they were not available in an earlier version of the board support package?
If the build works for that board with these new changes, then the changes look good to me.

@proppy Can you please resolve conflicts? Thanks!

PTAL, rebased

Hi @proppy, it looks like this PR might need to be rebased one more time. Again, apologies for the delay.

@proppy Can you please check advaitjain's comments and keep us posted. Thanks!

It has been 14 days with no activity and the awaiting response label was assigned. Is this PR still valid? Assigning the stalled label. Please comment to reassure me that this is still being worked on.

@proppy Any update on this PR? Please. Thanks!

It has been 14 days with no activity and the awaiting response label was assigned. Is this PR still valid? Assigning the stalled label. Please comment to reassure me that this is still being worked on.

I believe this is handled internally , will close this PR, feel free to reopen.


pull request for e2e test at 12/01/2016 18:56:06

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


dtls listen tcp port

when use gost version 2 like this
./gost -L dtls://:1443/:8388

1443 is listen on TCP port but not UDP port.
when use version 3 , 1443 is UDP port.
doc of  version 2 have nothing about dtls.
Maybe the version 2 need some modification.

dtls is only available in version 3.


Manually run a query

Is there an exposed method of running a query manually? With graphql-server-express queries are automatically executed through the request cycle, but sometimes it would be helpful to run GQL queries from within other parts of the app to get a full, joined, object that GQL produces.

hi @astanciu,
eventually, graphql-server is an network wrapper for graphql core function.
if you don't want to use it over network, you can just run it standalone:
import { graphql } from 'graphql';
import scheme from './scheme';

const query = `{
  me {
    name
  }
}`;

const result = graphql(scheme, query);
console.log(result);

function documentation can be found here

Perfect! Thank you!

you are welcome! :)


Android file...?

How does one override the default file for Android and have it load the result of the webserver?  I've been looking at the source code and can't find an override like in iOS.  Any ideas?

@clintandrewhall I haven't worked with the Android version yet, but I will be and I created a config for Android and iOS. Hope it helps.

I think what he means is that the Android app is still looking for the JS bundle on port 8081. On iOS we can change the port in the AppDelegate.m file, but there doesn't seem to be a corresponding file for Android. I've run a search in the android build folder of a React Native app, and 8081 can't be found anywhere.
If someone knows of a way to change the port of the JS bundle for Android, do tell! I haven't been successful with  adb reverse.

I haven't had the chance to play with RN for Android yet; I should be able to get around to it tonight. I think a good solution might be to change the RN packager to run on a different port, then run the webpack server on port 8081. Then you won't be required to change AppDelegate.m (or the Android equivalent)

An issue open against the React Native Debugger suggests it would be nice to keep configuration in package.json.

@jhabdas that would be superb!

Unfortunately I don't think we can get proper Android support until port 8081 is configurable: https://github.com/facebook/react-native/issues/1429
Because Android looks for the app bundle on port 8081 and /debugger-proxy runs on port 8081, the only way I could think of for react-native-webpack-server to work is to run react-native-webpack-server on port 8081, run the RN packager on another port, and proxy /debugger-proxy requests from react-native-webpack-server to the RN packager.
I spent far too long trying to get node-http-proxy to work for this purpose with no luck :weary:

Looking on this eagerly. Any luck with port-changing. I'm also trying at end , btw

Here's a cheap workaround.
You need an index.android entry in your webpack.config.js.
Then run the RNWS for Android like this:
./node_modules/.bin/react-native-webpack-server start -e index.android -P 9090 -p 9091 -w 9092

This sets the ports of port, packagerPort and webpackPort to respectively 9090, 9091 and 9092. (this can be any port, but 8080, 8081 and 8082 are already used by iOS).
Then fire up an emulator or connect an Android phone through USB (with all the debug settings) and run:
adb reverse tcp:8081 tcp:9090

This maps the port of the server to the default Android port.
There you go, debugging on your Android phone.
(Disclaimer: I haven't tried using the emulator with this yet.)

Slick!
On Tue, Oct 20, 2015 at 10:15 AM Richard de Wit<EMAIL_ADDRESS>wrote:

Here's a cheap workaround.
You need an index.android entry in your webpack.config.js.
Then run the RNWS for Android like this:
./node_modules/.bin/react-native-webpack-server start -e index.android -P 9090 -p 9091 -w 9092
This sets the ports of port, packagerPort and webpackPort to respectively
9090, 9091 and 9092. (this can be any port, but 8080, 8081 and 8082 are
already used by iOS).
Then fire up an emulator or connect an Android phone through USB (with all
the debug settings) and run:
adb reverse tcp:8081 tcp:9090
This maps the port of the server to the default Android port.
There you go, debugging on your Android phone.
(Disclaimer: I haven't tried using the emulator with this yet.)
—
Reply to this email directly or view it on GitHub
https://github.com/mjohnston/react-native-webpack-server/issues/65#issuecomment-149597280
.

Any idea when this will be released? Currently spiking react native and I need to prove my implementation can work on android as well. Also: thanks for creating this as otherwise my implementation wouldn't work at all! :)

Also @richarddewit I tried your suggestion but couldn't get it working on the emulator. Has anyone been successful getting it working on a emulator or am I doing something wrong?

Okay guys, here's a quick hack to get you rolling.  Edit your package.json to have this in the scripts block:
  "scripts": {
    "bundle": "react-native-webpack-server bundle",
    "start": "react-native-webpack-server start",
    "start-android-webpack-server": "react-native-webpack-server start -e index.android -P 9090 -p 9091 -w 9092",
    "install-app-to-android-device": "cd android && ./gradlew installDebug",
    "setup-reverse-tcp-for-android-device": "adb reverse tcp:8081 tcp:9090",
    "launch-android-app-on-device": "cd android && adb shell am start -n com.\"$npm_package_name\"/.MainActivity",
    "android": "npm run-script setup-reverse-tcp-for-android-device && npm run-script install-app-to-android-device && npm run-script launch-android-app-on-device && echo \"Please Reload JS on the app from the menu after the webpack server starts below\" && npm run-script start-android-webpack-server"
  },

Then simply run from command line: npm run-script android.  The only issue now is that you have to hit Reload JS from your Android device, not sure how to trigger that with a command.  I basically went through runAndroid.js here https://github.com/facebook/react-native/blob/7e53ee1095ac956887dd6a20d19a403096472660/private-cli/src/runAndroid/runAndroid.js and just pieced all the commands together.  Otherwise when you would run react-native run-android it'd simply use port 8080, which doesn't work.
Note that in runAndroid.js it parses AndroidManifest.xml, and in our case we should have our global app name for Android/iOS defined in package.json, so we can simply used the exposed environment variable npm_package_name in our scripts block of package.json as defined in the environment automatically here https://docs.npmjs.com/misc/scripts#environment.

Added some basic android support in #115. Can some of you try out branch android? Unfortunately no debugger support yet, but the bundle should run fine just on the device

@elliottsj Can you merge with the 0.12-hmr branch?

@niftylettuce Yep, rn-0.12-hmr is now rebased on master

@elliottsj So thisrn-0.12-hmr now supports Debug in Chrome and Hot Reloading on Android?

@niftylettuce Chrome debugger should continue to work using iOS, but not yet for Android. No hot reload yet for Android either. Since RN is still hard-coded to port 8081 in several places, I've tried running RNWS on port 8081 and using node-http-proxy to proxy the websocket executor to the RN packager, but no luck so far. I'm interested to see if anyone else has a solution for this...


Remove unwanted node selection in Edit Report Menu

https://bugzilla.redhat.com/show_bug.cgi?id=1384518
Cloud Intel -> Reports -> Edit Report Menus -> select any group
At first load Reports tree should have no node selected to match right side that says Please select a node from the tree to edit..
Before:

Top Level node cannot be selected.
After:

Top Level node can be selected.
@miq-bot add_label ui, bug

Euwe Backport details:
$ git log -1
commit 6a8313a94f05b1f0c98d1ab9e52ecc7707d4c93b
Author: Martin Povolny<EMAIL_ADDRESS>Date:   Thu Oct 20 15:17:55 2016 +0200

    Merge pull request #12051 from ZitaNemeckova/bz1384518

    Remove unwanted node selection in Edit Report Menu
    (cherry picked from commit 0c65195d3712f29cc2e72381c338d7b1e00c1441)

    https://bugzilla.redhat.com/show_bug.cgi?id=1384518

@simaishi Please clone https://bugzilla.redhat.com/show_bug.cgi?id=1384518 for Euwe

Euwe BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1388676


Provide a 'contribution-guide' for this project

I'm currently contributing for the first time to this project, and as a non-Powershell expert, it would be nice to have some guidance available in the form of documentation.
This guide could describe what steps you need to take for certain topics:

How to create a new module
How to create a new script (create a ps1 file, make the required modifications in the psd1 and psm1 files, .... )
How to create a unit test
How to run the unit-tests  (I'm currently struggling on this step for instance, when running Invoke-Pester -Path <file>, I'm always faced with the error 'Module  is not a Script module>'.

How contributors with more privileges are able to release/prerelease the project


Emmanuel Elorm Delanyo Module 1

WS2_M1E1_Submission.docx

Thank you for your successful submission to the practice exercise! Please be sure to fill out the post-Module survey.


(MCO-762) Add 'no-batch-files' option to install.rb

This cherry-picks https://github.com/puppetlabs/marionette-collective/pull/379 and https://github.com/puppetlabs/marionette-collective/pull/380 to stable.

CLA signed by all contributors.

👍


Avoid hanging at exit when using CLONE_VM on Glibc <2.24

Fixes #455, ping @jmellorcrummey and @mwkrentel. IMO 2.24 is old enough we could get away with just dropping support, if not though this PR provides a hacky fix.
There is a bug in older Glibc (https://sourceware.org/bugzilla/show_bug.cgi?id=18862) where using CLONE_VM instead of CLONE_THREAD causes the Glibc wrapper to reset its internal pthread state in the parent process. This wreaks havoc with all things pthread, but most noticably it stops the pthread_kill in libmonitor's shootdown from functioning (and libmonitor doesn't pay attention enough to the returned error codes).
As a sort of hack, it turns out the reset happens after the body passed to clone, so killing the child via a signal instead of returning dodges the issue. At least, it seems to work on 2.17.
This also adds an auditor-export for sigaction (to reset the signal disposition for a faster signal-death). In the fake-auditor case there isn't a "default" function to use since sigaction is wrapped by libmonitor, which in turn doesn't provide a monitor_real_sigaction. Caveat emptor.

Simple reproducer for the GDB bug:
$ cat x.c
#define _GNU_SOURCE
#include <sched.h>
#include <sys/wait.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <unistd.h>

int body(void* _) {
  struct timespec ts = {2, 0};
  while(nanosleep(&ts, &ts));
  return 0;
}

int main() {
  void* stack = malloc(16*2*1024);
  int child = clone(body, stack+(16*1024), SIGCHLD | CLONE_VM, NULL);
  printf("Waiting for child: %d\n", child);
  waitpid(child, NULL, __WALL);
  printf("Child waited for\n");
  return 0;
}
$ gcc x.c -g
$ gdb ./a.out
...
(gdb) b x.c:17
Breakpoint 1 at 0x11da: file x.c, line 17.
(gdb) b x.c:19
Breakpoint 2 at 0x1221: file x.c, line 19.
(gdb) r
Starting program: /tmp/a.out

Breakpoint 1, main () at x.c:17
17	  int child = clone(body, stack+(16*1024), SIGCHLD | CLONE_VM, NULL);
(gdb) c
Continuing.
[Detaching after fork from child process 298576]
Waiting for child: 298576
Child waited for
[Inferior 1 (process 298566) exited normally]
(gdb)

Weirdly enough forcing GDB to step slowly through the clone syscall makes it work again:
(gdb) catch syscall clone
Catchpoint 3 (syscall 'clone' [56])
(gdb) r
Starting program: /tmp/a.out

Breakpoint 1, main () at x.c:17
17	  int child = clone(body, stack+(16*1024), SIGCHLD | CLONE_VM, NULL);
(gdb) c
Continuing.

Catchpoint 3 (call to syscall clone), clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:78
78	../sysdeps/unix/sysv/linux/x86_64/clone.S: No such file or directory.
(gdb) c
Continuing.
[Detaching after fork from child process 298916]

Catchpoint 3 (returned from syscall clone), clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:78
78	in ../sysdeps/unix/sysv/linux/x86_64/clone.S
(gdb) c
Continuing.
Waiting for child: 298916

Breakpoint 2, main () at x.c:19
19	  waitpid(child, NULL, __WALL);
(gdb) c
Continuing.
Child waited for
[Inferior 1 (process 298897) exited normally]
(gdb)

Updated with the "backup plan," new patch description below. Rebased on https://github.com/HPCToolkit/hpctoolkit/pull/457 to prevent conflicts during the merge.
The fix here is to remove CLONE_VM, which as a side effect removes the parent's tracking for the Fnbounds process. Although there is a "shutdown" message that could be sent to close Fnbounds, since sending the message may block indefinitely this is not used to signal a shutdown (unchanged from the original). In the worst case scenario of an Fnbounds hung between queries, the application will exit without concern even though Fnbounds has not yet (previously it would waitpid for it to exit). Caveat emptor.
Since this bug only affects the parent, the child and grandchild share a memory space. Neither use pthreads and both exit quickly (and through different paths) so it should be fine.
Note that this will re-raise the slowdowns observed with large memory spaces. Caveat emptor.

Note: although it may be a little sloppy to ignore the return code for pthread_kill(),
it doesn't really matter.  In either case, monitor will be unable to signal the thread
to run code in the thread.  So, you'll still necessarily get some message that means
"can't connect to some threads" and you'll still miss the fini_thread callback.
I've never liked the need for signals for this case.  My plan for monitor NG, if it ever
happens, is not to call fini_thread for this case, instead just tell hpcrun that the process
is ending and let hpcrun deal with it.  For example, some threads will write out other
threads data, but not have this strong need to do everything from the same thread.

This (and related clone issues) would make great candidates for regression tests.


Miner is broken on app startup.

Any function inside Miner is broken if Chain.clear_state() was not called before.
Travis tests are passing because the state of one test interferes with other tests.
How to trigger the bug:
Method 1)
mix test test/aecore_miner_test.exs

Method 2)
In a new iex session run:
Miner.candidate()

Demonstration:
Interactive Elixir (1.6.4) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> Miner.candidate()
** (UndefinedFunctionError) function nil.header/0 is undefined or private
    nil.header()
    (aecore) lib/aecore/miner/worker.ex:218: Aecore.Miner.Worker.candidate/0
iex(1)> Chain.clear_state()
:ok
iex(2)> Miner.candidate()
%Aecore.Chain.Block{
  header: %Aecore.Chain.Header{
    height: 1,
    miner: <<99, 210, 199, 107, 44, 114, 135, 138, 43, 48, 39, 239, 201, 52,
      238, 172, 44, 135, 64, 118, 56, 31, 255, 129, 135, 65, 209, 160, 156, 83,
      39, 219>>,
    nonce: 0,
    pow_evidence: nil,
    prev_hash: <<21, 156, 171, 146, 198, 198, 172, 36, 173, 41, 235, 64, 240,
      130, 201, 45, 239, 9, 239, 128, 104, 104, 27, 44, 209, 61, 193, 163, 120,
      145, 215, 212>>,
    root_hash: <<7, 3, 205, 135, 51, 13, 113, 21, 34, 145, 226, 126, 34, 201,
      253, 37, 151, 38, 2, 213, 125, 237, 97, 14, 164, 140, 50, 187, 148, 206,
      49, 106>>,
    target: 553713663,
    time:<PHONE_NUMBER>120,
    txs_hash: <<0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
      0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0>>,
    version: 14
  },
  txs: []
}
iex(3)>

It seams that issue is triggered by function Persistance.delete_all_blocks(). Persistance works properly outside tests, but aecore_miner_test.exs calls that function and any subsequent runs error.
To fully solve this issue and anything similar we should do following:

Assure tests are properly cleaning the node (create a proper way for clearing node between tests)
Create test for above mentioned new way of clearning nodes
Create some test that creates Persistence data and checks consistency of everything after loading.


Bug when using the slideToClickedSlide prop

This is a (multiple allowed):

[x] bug

[ ] enhancement

[ ] feature-discussion (RFC)

Swiper Version: Swiper/4.0.7/js/swiper.min.js

Platform/Target and Browser Versions: macOs, Chrome

Live Link or JSFiddle/Codepen or website with isssue: https://corpusnaturals.com/collections/natural-deoderant

Hello, I've been trying to debug a small issue on my product swiper.  I'm losing one slide every 1-2 loops when clicking through the slides.  The bug is not present when dragging through the slides.
What you did
Initialized product swiper with the following code:
carousel.swiper = new Swiper(".block-carousel__mainswiper", {       speed: 400,       slidesPerView: 2,       centeredSlides: true,       loop: true,       slideToClickedSlide: true,       navigation: {         nextEl: ".swiper-button-next",         prevEl: ".swiper-button-prev"       },       on: {         slideChange: function() {           if (carousel.swiper) {             carousel.swiperHeader.slideTo(carousel.swiper.realIndex + 1);             landing.updateHistory();             setTimeout(landing.updateActiveProduct, 405);           }         }       },       keyboard: {         enabled: true,         onlyInViewport: true       },       resistance: false,       followFinger: $("html").hasClass("no-touchevents") ? true : false     });
Expected Behavior
The product slider should loop infinitely without dropping any slides in the process.
Actual Behavior
Once per 1-2 loop revolutions following the "Cedar Flora" slide, the following slide is not present in the dom.  This is only happening when clicking through the slides, not able to replicate when dragging the slides.

Solved by disabling slideToClickedSlide and adding event listeners for clicks on prev/next, then manually firing the slide method.


Introduction to matplotlib

Link: https://github.com/UofTCoders/studyGroup/blob/gh-pages/lessons/PlottinginPythonwithMatplotlib/lesson.md
Author: @ricardoharripaul
Video: none
Description: This lesson will introduce users to basic plotting in python as well as basic graphs with research quality figures.

Link is broken 🔗


When using query with Composite data source, can we have meta data in results (like which data source the record came from)

I've been learning stix2 here, and, for example if I run a search on a bunch of collections for a specific filter, I may want to understand the id and title of the specific collection that result came from. I am not sure if it's my newness to stix2 that is causing this, but the only way I could see to do this is to break up the collections I want to search into single collection data sources and search each individually. If I get a result, I tag on the collection and id onto that result.
Is there a way to access this data as part of the results without having to do. the looping myself?

Hi @JohnOmernik, you're right; there's currently no way to get that metadata without doing the looping yourself. Part of the reason for this is to maintain consistency with the other datastore backends that do not have a "collection" concept.


[2.0][EC2] Add T3 instance type for AWS EC2 node template

Rancher versions:
rancher/rancher: v2.0.8
Type/provider of hosts: AWS EC2
Steps to Reproduce:

Add new node template
Select AWS EC2 as driver
Enter credentials
Select vpc & subnet
Select security group
In instance type, EC2 T3 instance types are unavailable in the list.

The same here with rancher 1.6

Amazon has no API to get the instance types, so they have to be manually added every time.

By the way, are you also going to add T3 instance type on Rancher version 1.6.x ?

@rsilvestre - I just put in a separate issue to address this.  You can track here -  #15502

Need to add r5 and r5d too, {large, xlarge, 2xlarge, 4xlarge, 12xlarge, 24xlarge}.  They're not generally available but some people have access.  https://www.ec2instances.info

Version - 2.1 master 9/12
r5 and r5d listed but I don't have access to that size.  But I can verify they are there and selectable.  they are passed and returned by API.
Verified fixed.

Hi @tfiduccia, nice job. When can we expect to have in it available on rancher/server image on docherhub ?


Create a new demo: Kubecon NA2023

We should have a video - pointed to in the repo.
And instructions for how to run this demo yourself.
Demo should show:

The world without bpfd

Unable to do xdp multi-attach
Unable to do tc multi-attach
Having to create operators and boilerplate for your own bpf-enabled application on k8s

The world with bpfd

Can do all of the above
Dev experience is better

Done in https://sched.co/1R2wG!!
Demo can be found in https://github.com/bpfd-dev/bpfd/tree/kubecon-demo-2023


Added Discord Invite Link

Fixes  #4 & #5
Proposed Changes

Added Discord Invite Link to Readme
Changed owner and repo name to be dynamic

Screenshots

Great collaboration, thank you all 💥


Add gateway deployment terraform to staging

I'm currently using staging to demo Firezone to potential customers and it'd be helpful to have the latest gateway fixes deployed on merges to main.

Fixed in #3298


[Bug]: The ui is little inconsistent on dashboard/career

Contact Details
<EMAIL_ADDRESS>What happened?
The sidebar is little inconsistent the area should be more scrollable it is not showing challenges properly

In other browser its is not showing more content

What browsers are you seeing the problem on?
Others
Relevant log output
No response
Are you interested in contributing?

[X] I'd like to work on this issue

Code of Conduct

[X] I have used the search function to check if an issue already exists
[X] I agree to follow this project's Code of Conduct

Which program are you contributing in?
gssoc

duplicate #763


HP ClickPad scrolling makes VSCode get stuck for 2-5 seconds

Issue Type: Bug
I am using VScode version 1.22.2 on my HP ProBook 440 G4. This laptop has clickpad with factory installed drivers and touch related software. Whenever, I try to scroll up or down in VSCode windows, using the click pad two finger gesture, VSCode gets stuck for 2-5 secs.
VS Code version: Code 1.22.2 (3aeede733d9a3098f7b4bdc1f66b63b0f48c1ef9, 2018-04-12T16:38:45.278Z)
OS version: Windows_NT x64 10.0.16299

System Info

Item
Value

CPUs
Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz (4 x 2400)

Memory (System)
7.43GB (2.08GB free)

Process Argv
d:\Program Files\Microsoft VS Code\Code.exe D:\demo\mydemo

Screen Reader
no

VM
0%

Extensions (9)

Extension
Author (truncated)
Version

dart-code
Dar
2.12.1

vscode-eslint
dba
1.4.8

vsc-material-theme
Equ
2.0.1

prettier-vscode
esb
1.3.1

diff-tool
jin
0.0.1

debugger-for-chrome
msj
4.3.0

vetur
oct
0.11.7

vscode-icons
rob
7.23.0

open-in-browser
tec
1.1.0

(2 theme extensions excluded)

Duplicate of https://github.com/Microsoft/vscode/issues/13612


Error with iptables when brining up one connection

/etc/load_balance.pl DSL
iptables v1.6.0: Couldn't load target `MARK-DSL':No such file or directory
This also happens when I bring up a different connection
/etc/load_balance.pl LTE
iptables v1.6.0: Couldn't load target `MARK-DSL':No such file or directory
Nevertheless load balancing is working fine. What would cause this?

Could you post (or email me) your configuration file? This shouldn't be happening.