new-acct curl returned with 52

Suddenly found one of my CentOS 6 boxes had failed to renew certificates.
Long story short after testing various things I updated to latest dehydrated just for good measure, have tested with both normal and test API servers and continue to get this error:
Problem connecting to server (post for https://acme-staging-v02.api.letsencrypt.org/acme/new-acct; curl returned with 52)
Cleared accounts and certs etc etc and cannot get past this.
Debugging in Bash:
++++ curl -A 'dehydrated/0.6.5 curl/7.19.7' -s -w '%{http_code}' -o /tmp/dehydrated-vsit5B https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce -I
+++ statuscode=200
Then
+++curl -A 'dehydrated/0.6.5 curl/7.19.7' -s -w '%{http_code}' -o /tmp/dehydrated-Cjkjac https://acme-staging-v02.api.letsencrypt.org/acme/new-acct -D /tmp/dehydrated-MDnYMO -H 'Content-Type: application/jose+json' -d '{"protected": "ey........."}"
++ statuscode=100
++ curlret=52
As far as I am aware nothing had changed on the server or anywhere else.
Config is really simple - just custom WellKnown that is accessible, CA and Accept Terms
I have several other near identical boxes in several locations and none of them are experiencing this. I did wonder if it had any relationship to 684 but from the bash debug it looks like it gets past the new-nonce URL.
Completely perplexed so any advice gratefully received.

Does this box have the same network configuration as your other boxes?
From the fact that curl actually saw a "100 Continue" message and after that no more content (52: Empty reply from server) I'm assuming that somehow the connections gets interrupted at that point, which I often observe on connections with mismatching MTUs, misconfigured firewalls or IPs conflicting between hosts.
I'm closing this as this is definitively not a dehydrated bug. Still interested in what's going on here.

Thanks for looking...

Does this box have the same network configuration as your other boxes?

Essentially yes - I have one that, bar the internal & external IPs, is identical AFAIAA.
Proxmox hosted Server (->  pi-hole DNS) -> Endian -> wide world
Endian port forwards 80 & 443 to the box which only has an internal IP.
Proxmox has no firewalling enabled. Server itself has iptables disabled (had been enabled but stopped for testing)

From the fact that curl actually saw a "100 Continue" message and after that no more content (52: Empty reply from server) I'm assuming that somehow the connections gets interrupted at that point, which I often observe on connections with mismatching MTUs, misconfigured firewalls or IPs conflicting between hosts.

That was my understanding too, but try as I might I cannot see where that is happening so was after any help in debugging it.  Been using your script for a long time, and even wrote a package to make it easy to configure/use on our Koozali SME server.

I'm closing this as this is definitively not a dehydrated bug. Still interested in what's going on here.

Indeed. I have no reason to specifically think it is dehydrated, but I have no idea what else it could actually be, and there is no real 'support' forum for dehydrated and associated issues.
This box was using v 0.6.2 and AFAICT had been working perfectly until 15th Dec when the last cert expired, but presumably there was a failure at the renew point that was missed but I am not sure how long ago that was to see what might have changed - presumably around 30 days. I still can't think of anything that would affect it though.
I have tried upgrading to 0.6.5, remove all accounts & certs and start afresh, revert accounts & certs and go back to the v1 server to renew, and still nothing!
V1 gives this on renew:
curl -A 'dehydrated/0.6.5 curl/7.19.7' -s -w '%{http_code}' -o /tmp/dehydrated-vPcGSm https://acme-v01.api.letsencrypt.org/acme/new-authz -D /tmp/dehydrated-tltbGL -H 'Content-Type: application/jose+json
ERROR: Problem connecting to server (post for https://acme-v01.api.letsencrypt.org/acme/new-authz; curl returned with 52)
So basically the same issue with a different endpoint. Very puzzling and no idea what to test.

Mh you should be using acme-v02, I think acme-v01 stopped accepting new registrations, so that might be another issue. But if it doesn't work with a completely fresh installation and it works from a different system on the same network I have absolutely no clue on what's happening here. You could maybe trace it using wireshark, maybe there is something obvious like a tcp reset out of nowhere.

v1 & v2 yes - I am aware of that - I have tried both renewing v1, and creating a new v2 and both failed :-(
OK, I think we might have got it working, and fixed another issue that we had very occasionally on certain sites not always loading correctly - we thought it might have been CDN or other issues and could never pin it down specifically as it was not consistent.
Bit lengthy but it may help others. It is fairly obscure..... and to do with the way that ISPs can handle supposedly 'static' IPs.
I have two static IPs with my ISP.  However, according to them they are really dynamic addresses that are kept for your login. That means the gateways shift because I presume there is some network shenanigans behind the scenes....
So I think when I set some of this up I made some assumptions that then changed without realising.
2 Draytek ADSL routers get the WAN details via DHCP
81.136.x.x gateway <IP_ADDRESS> (PPPoA)
213.123.x.x gateway <IP_ADDRESS> (PPPoE)
Those routers are in a kind of half bridge mode (Draytek 'Active True IP') back to an Endian WAN gateway router.
This replaced an old Draytel 3300 WAN router which if I remember correctly you set to DHCP and it automagically picked up the correct settings from the Draytek ADSL routers. I forget now, but it was never an issue.
But the Endian wanted the IP, gateway, and subnet mask specifically. DHCP only picks up the ADSL routers REAL internal Lan IP address, not the WAN address.
I think what happened was the subnet for each was originally set to <IP_ADDRESS> and the gateway IPs set to 81.136.x.1 and 213.123.x.1 respectively because as you can see above, the gateway for the 213 address is really some internal hack by the ISP and you can't use a subnet mask properly - the IP and gateway are meant to be on the same subnet.
So I swapped the 81.136 address to use a subnet mask of <IP_ADDRESS> to match the current gateway  (I have a feeling this was the original setting given to me like 10 years back when we got the line & IP but the ISP denies all knowledge of it) with the current correct gateway and everything suddenly seems to be OK including dehydrated. Odd that the previous settings work for most stuff, but not all. (I saw the gateway IP change when I test rebooted the ADL Router which is what started me off)
As yet I have no idea what to set as a subnet mask for the 213.123 address.... however, that really only runs VPNs and never seems to have an issue.
I presume a lot of this is internal network juggling with the shortage of IPv4 addresses. But currently the ISP is not offering IPv6.... go figure !!!!!
So the upshot is check your network settings really carefully, especially in these days of lack of IPv4s and ISPs playing crazy games rather than getting on with issuing IPv6 addresses.


Add rx/tx minimum unlit time, adjust minimum lit time

What's this PR do?
This PR adds a 50ms minimum unlit time to the RX/TX flash cycle, and increases the minimum lit time to 100ms.
What are the important parts of the code?
This adds RX_CLEAR_TIMEOUT/TX_CLEAR_TIMEOUT events in redux. This extends the RX_ON/RX_OFF chain to include RX_CLEAR_TIMEOUT.
Is any other information necessary to understand this?
Issue #213 suggested a minimum 25ms unlit time, but in testing 50ms looked a bit cleaner.
What are the relevant tickets?
Closes #213

@2fast2fourier - Thank you for evaluating the time limits and switching to one that appears to look more appropriate.


Add tutorial and API docs for HTTP crawler log submission

What does this PR do?

Adds overview, API and tutorial docs for the "logs from http crawlers" feature.
Some notes:

This is quite a bit of text. It's best to view it with ddev docs serve in your browser.
I'd like to flesh out the API docs some more, I'll do that later in a follow-up.

Motivation

Additional Notes

Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] Changelog entries must be created for modifications to shipped code
[ ] Add the qa/skip-qa label if the PR doesn't need to be tested during QA.
[ ] If you need to backport this PR to another branch, you can add the backport/<branch-name> label to the PR and it will automatically open a backport PR once this one is merged

Created DOCS-8751 for docs review.


Linkcheck CI failures

Currently, the linkchecker is complaining when CI runs. This is because:

The links in the changelog compare nonexistent tags
The CLA at https://www.forms.deshaw.com/ uses a CA which is not widely available

Closing as this has been resolved by fixing the cert. No action needed here.


Ensure that continuation lock is held before calling handler.

Noticed this while debugging a plugin using the ASYNC job support.  My earlier assumption was that all the VC and HttpSM continuations would have same mutex as the NH handler.  So there would be no need to grab the mutex before calling the handler.
For the client vc and the HttpSM, the mutexes are the same and correspond to the nh lock.  However, the server vc if it is reused may have a different mutex than the HttpSM.  So if the event is being processed from the server vc, the HttpSM will not be locked.  So there are cases when HttpSM is being called but not locked.  Most activity on the HttpSM will be from the same thread, so this shouldn't be too bad, but there are cases when other worker threads, etc work on the HttpSM.
During my engine development there were some very odd timings which exposed some crashes due to unlocked HttpSM.

This looks pretty scary and risky change. handleEvent have been ensuring that the event is processed after returning from handleEvent. I'm not sure whether it is by design but this changes the behavior.
I understand that continuations's handleEvent shouldn't be called without the lock and this change ensures it, however I'd suggest that adding a new function (e.g. handleOrScheduleEvent) and use it instead of handleEvent unless the event really need to be processed on the function call.

Here is an example that is controlling the behavior (MUTEX_TRY_LOCK vs SCOPED_MUTEX_LOCK).
https://github.com/apache/trafficserver/blob/52738fb50d5f0af82fcf1992559702c8a174a511/proxy/http2/Http2Stream.cc#L104-L127

I agree that it is a fundamental change, but calling handlers on unlocked HttpSM's is also scarey.  In the example you gave, the mutex is already held, so the change in Continuation::handleEvent will not affect that particular case.
I'll review the code for other cases, but if the assertion is that handleEvent can only be called directly if the mutex is held, then the changes in the Continuation::handlleEvent should be no-ops

It seems much better than the original change but I'm still not so sure.
My point is event processing order. lockAndHandleEvent sounds like handleEvent with a built-in lock acquiring but actually it can just schedule the event and return. It will avoid crashes but it will also allow ATS to keep running strangely because of unexpected event processing order. This is why I suggested the name.
If we just want to ensure that a caller holds a lock for the continuation, we should probably use SCOPED_MUTEX_LOCK instead in lockAndHandleEvent. If we also want a function that TRY to acquire a lock, that should be named like handleOrScheduleEvent I think.

If in fact other threads are doing something on the continuation, doing a blocking lock seems even more dangerous.  The Try and reschedule seems like a safer approach, particularly if we are concentrating on the event loop processing case.

Thinking on that some more and chatting with Alan, I think my origin logic was correct.  In the event process logic the event mutex is locked before calling the event handler and the event lock and the continuation lock are supposed to be the same.
I think the issue I was seeing was a handleEvent called directly from the netvc (readSignalAndUpdate).  The serverVC and HttpSM in the case of session reuse will not have the same mutex.  I am in the midst of something right now, but I will put back my original version.

I pushed the origin back.  If the caller is holding the continuation lock then there is no change in functionality.
If the caller is not holding the continuation lock (and the continuation has a mutex), then the handleEvent may reschedule and return immediately.  This is a change in behavior , true.  But in the original behavior the event handler is being called on the continuation without a lock and with some other thread holding the lock.  This original behavior seems even worse than a potential race condition.

If the caller is holding the continuation lock then there is no change in functionality.

True.

But in the original behavior the event handler is being called on the continuation without a lock and with some other thread holding the lock. This original behavior seems even worse than a potential race condition.

On the case you were seeing, that is probably true.
But again, handleEvent have been ensuring that an event is completely processed on the function call even if it was accidentally called without a lock. It will not be postponed.
So lines following handleEvent can assume that an event handler have already processed the event. Places that require this behavior must do a blocking lock before calling handleEvent, however, similarly, places that don't require this behavior must do a try lock before calling handleEvent. This is the rule, right?
Why don't you put a try-lock outside the handleEvent that causes the issue then?
Guaranteeing holding a lock by doing it inside handleEvent sounds like a good idea, but if we do this, I think we need to provide both the two ways (block or postpone) so that we can choose appropriate one based on what we need at each places.

If you have a mutex associated with the continuation, there is no case where you should be calling the handleEvent without the lock.  I can hunt down the cases that aren't grabbing the lock and do a try lock there, but in that case I would want to put a ink_release cert in handleEvent.  If it very risky and vulnerable to race conditions to be calling the event handler on a continuation without holding its lock.

It seems to be we have agreement that calling handleEvent without locking the continuation's mutex is always incorrect, but there is disagreement in how we should eliminate the bug.
@shinrich's patch proposes that handleEvent itself should ensure we've locked the correct mutex before calling the event handler since, as you all noted, it is never correct to call the handler otherwise. Therefore this prevents the bug in all cases. If the lock cannot be immediately obtained, handleEvent reschedules the event and returns to the caller. This is because doing a blocking lock is more dangerous than not patching the code, and so this is worth changing the behavior this way.
@maskit points out that this patch will change handleEvent from synchronous method to an asynchronous method, and so this is very dangerous since there likely exists code that does not expect handleEvent to return asynchronously. @maskit suggests creating a second method rather than changing handleEvent in this way, or else making it the caller's responsibility to lock.
Hopefully I have understood the discussion correctly :)
Given that we agree the current code is broken, then—writing from the perspective of one who has not exhaustively search the impacted code—I am inclined to agree with @maskit here that changing methods from sync to async seems to break a pretty fundamental and straightforward expectation the callers have had up to now on handleEvent.
If we are going to change handleEvent to be async, then this patch must also exhaustively cover changes to any caller to handleEvent such that it handles the new async behavior. It is not obvious to me without doing this work completely that we would be safe from this new risk.

If we can show that apart from such additions to this patch, there exist no scenarios in which there is a such a risk, would that be acceptable, @maskit ? This would make everything consistent in how it calls handleEvent and what it expects, which I think is the central concern with the patch.

Alternatives so far:

Make handleEvent async, and have it try to get the lock itself.
Keep handleEvent synchronous, and add an ink_release_assert if the lock is not held
Keep handleEvent synchronous, add an ink_release_assert if the lock is not held, and add something like handleEventAsync for the new logic.

@d2r Thank you for clarifying my opinion. That’s exactly what I wanted to say.

If we can show that apart from such additions to this patch, there exist no scenarios in which there is a such a risk, would that be acceptable, @maskit ?

Hmm, yeah, it’s acceptable, if all cases can handle the new async behavior. But if we do so, places that require sync behavior try to acquire a lock twice (outside handleEvent and inside handleEvent). It’s a bit redundant.
I’m on vacation. Don’t expect replies from me next 2 weeks.

I think I'd go with option 3 with the name "dispatchEvent" which does the try lock either calls directly with the lock or dispatches an event if not. I think putting in the ink_release_assert to verify the lock in handleEvent is critical as well - we want to detect that breaking of the contract as early as possible.

Also, acquiring a lock twice is very common in the core - that's precisely why the locks are recursive locks. The second acquisition is very fast because the code checks if the lock is already held by the thread and if so just bumps a counter.

I am good with the consensus.  I've updated the PR again to create a dispatchEvent which attempts to get the lock and reschedules if it cannot.  And it adds an ink_release_assert if there is a lock and it is not held by the current thread on entry to handleEvent.

Updated calls from handleEvent to dispatchEvent in many places in HttpSM that I think were vulnerable to the original issue plus cases of the tests that tweaked the ink_release_assert

I'm going to remove the 7.1.5 Project on this, since going forward, we will need to make a second PR against the 7.1.x for proposed back ports.

Cherry picked to 8.1.0


easy: rename settings to options

rename settings title to options, since settings barely fit the screen
also recolor options to be gray for option text and white for values
rename all occurences in code, settings → options

[done](url)


[20.03] pkgs.varnish: pkgs.varnish63 -> pkgs.varnish60

because pkgs.varnish62 and pkgs.varnish63 are broken (and might need to be removed from 20.03 as not yet ready)
partial backport of https://github.com/NixOS/nixpkgs/pull/82514

@worldofpeace

Am I the only one using varnish ?
Should I take the maintainership on it ?


build and preRender bug

add in line 18:
_toggle,
insert in line 200:
if(_toggle == toggled){     return } _toggle = toggled;
replace in line 312:
 var value = extractValue(this),                 mode = value.split('('),                 $elm = findElement($(this));
to:
             var $elm = findElement($(this)), 				value = extractValue($elm), 				mode = value.split('(');

The information above is used to solve two problems, one is that ColorPicker continues to response to clicking action after it is closed and the other is that  system fails to initialize background color after providing doRender.

Hi @huye ,
thanks for your participation,
Maybe you need to get the newest version. I fixed the continuous click action earlier in line 118:
} else if (_colorPicker.$trigger) {

Your second concern about 'initialize background color after providing doRender'... I don't quite know what the problem is and... extractValue is destined to take a DOMElement and not a jQuery object.
Can you explain your problem more precisely?
Cheers
Peter

Reproduce code:
`

Text

`

have problem with continuous click ealier, the new version has fix the issue.

Hi @huye ,
I think I can see the problem now:
You provide colorPicker to the  and not to the <input ...>. $('.color').colorPicker() is getting your label... This is also the reason why you needed to add doRender: "input" to your options. Doing so, you'll get the input from your renderCallback: function(pick, toggled) callback, but the initial value is still taken  from the  and your label doesn't have a value.
The solution(s) would be: either put an initial value on your label or put the color class to your  <input class="no-alpha border-color color"> or use color picker with another selector as $('.border-color').colorPicker(...)

I hope to be able to trigger the render event when you click on the label.

@huye
What's wrong with the following?

    Text
    <input name="fore" class="no-alpha border-color color" value="#FF0000">

You can click on the label and still be able to open the picker... which also triggers the renderCallback


aurora store is not deleted.

i installed shizuku. i installed the fdroid shizuku privileged plugin from their repository. i authorized the plugin with shizuku. i installed aurora with f-droid, but i installed it with the "install over usb" option. now i want to delete it, i can't. i get an unknown error warning in f-droid. settings, apps, aurora store, uninstall, i try, no reaction. I deleted it with "canta" app, the app uninstall app I authorized shizuku, it looked like it was deleted. but in f-droid it was not deleted and the app but button was active. i tapped on open, it opened. i deleted google play store one with "canta" app. aurora store is not deleted.
xiaomi redmi 12c
Android 14 UP1a
OS hyperos <IP_ADDRESS>
f-droid 1.20.0
aurora store 4.5.1
shizuku 13.5.4
canta 1.4.1

I ran canta with shizuku authorization. wiped with canta. seemed to have a problem. restarted the device. problem was gone. wiped.


README

README
Create a detailed README with links, contributors, APIs used.
Don't forget to include screenshots of live site.

Needs Live URL & Screenshot

Screenshot and LiveURL included.  Cleaned up a few sections


Respect Telegram's throttle requests while generating timelapses

I've been having occasional hiccups when it came to timelapses. I've been getting errors like: Jun 22 23:24:38 fluiddpi python[549]: telegram.error.RetryAfter: Flood control exceeded. Retry in 13.0 seconds so… I decided to add a kinda proper handling of this error instead of the naive implementation I've commited some time ago.
This implementation is sort-of generic and may be transplanted to other parts of code if you wish so (I haven't seen the need so far though). The retryable_notification is almost a decorator as it needs a callable/lambda as an argument and repeatedly tries to execute it until one of the conditions is met. The first argument decides how persistent should this mechanism be: if required is True then it will try sending the message no matter what and in case of a fail will block for the requested number of seconds. if required is False then it may proactively block the request at all if it knows that the required amount of time has not passed yet, but will not block the rest of the code.
As you can see in the screencast below the messages are kinda choppy, but it's close to the best what we can do without actually slowing the timelapse generation.
https://user-images.githubusercontent.com/322405/175297031-3380da45-7cc7-4942-8efd-e1f7d06d4f96.mp4
Hope you like it & have a wonderful day
Paweł

Hey! Thank you for you contribution. It's very cleanly done, and I appreciate your effort.
The problem that we have, is an "ideological" one.
What you do, is you queue the updates, and try to send them "as soon as possible", which can cause a lot of problems down the line. A similar problem already exists in the reverse direction - if the bot was offline, and you send 50 commands to the chat in that time, and the turn the bot back on, it will try and run ALL of them. This is a bigger issue, than one may think.
To the problem you are trying to solve: @nlef had the idea, no to try and send "when it is possible again", but rather if sending is impossible right now, queue everything up, but instead of sending "when possible", to first collapse similar tasks - for example, if you have 10 status updates queued, 9 out of them are useless already, and will be immediately replaced, so there is no reason to send them at all.
If you wish to take on such a big feature, you are more than welcome to, and we will be happy to see your ideas on that topic.
I am leaving this open of course, should you decide, that you want to proceed with it. I think this is a good place to have discussions on that. I will also open a corresponding issue on our project board, to track progress.


make popover work on apple devices

@mariobehling resolves #534 .
demo: https://shubham-padia.github.io/open-event-webapp/speakers.html

Current coverage is 34.52% (diff: 100%)

Merging #896 into development will not change coverage

@@           development       #896   diff @@
=============================================
  Files                7          7
  Lines              979        979
  Methods            125        125
  Messages             0          0
  Branches           151        151
=============================================
  Hits               338        338
  Misses             641        641
  Partials             0          0

Powered by Codecov. Last update fa92c75...ad02899

Thanks.

sorry - just tested this on iPhone 6 - pop-ups are still not working after the fix


add "query()" which generates callback events for each bistable input

untested but should hopefully be close - I will test once I get my workbench setup again in the new house!

All I need to do is add a command handler to the State and Security Monitor firmware so if you send { "queryAll": true } it will set a flag, then in the next processing loop() call input.query() for each MCP and reset the flag.

Tested this on my KNX firmware and it is working nicely. Once you approve I will merge and update the State Monitor and Security Monitor firmware.

Here are the changes to my KNX state monitor firmware (which I will copy to the others if you are happy)... https://github.com/sumnerboy12/OXRS-BJ-StateMonitor-KNX-FW/pull/6


fix: confusing cart migrate message

1. Why is this change necessary?
2. What does this change do, exactly?
3. Describe each step to reproduce the issue or behaviour.
4. Please link to the relevant issues (if any).
5. Checklist

[ ] I have rebased my changes to remove merge conflicts
[ ] I have written tests and verified that they fail without my change
[ ] I have created a changelog file with all necessary information about my changes
[ ] I have written or adjusted the documentation according to my changes
[ ] This change has comments for package types, values, functions, and non-obvious lines of code
[ ] I have read the contribution requirements and fulfil them.

Hello,
thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/issues/NEXT-23515
Please use this issue to track the state of your pull request.

Your PR has been merged and will be synced in a few minutes. Thank you for your contribution 💙 🎉


added blog on user authentication with python

description:

Checklist

Please note that in case of below checklist not updated accordingly, the maintainers have the right to immediately close your pull request.

[x] You created a branch from dev branch.
[x] You PR is raised on dev branch and not onmaster.
[x] Blog follows Blog Guidelines.
[x] You have read the Contribution Guidlines before creating this PR.
[x] Checked for any duplicate blog entry.
[x] Checked for all grammatical errors in the blog.
[x] You have not published the blog content anywhere else on the internet on platforms like medium, dev.to etc.
[x] The content is not copy-pasted from anywhere else on the Internet.

Description of change

Author Details for Blog Post Entry

id: Solomon Esenyi
bio: Python Developer and Technical Writer with a passion for open-source, cryptography, and serverless technologies.
github: LordGhostX
linkedin: solomon-esenyi
twitter: LordGhostX

@puneetsingh24 @pareek-narendra Is there anything I need to do before its reviewed and merged?

Thank you @pareek-narendra
I've made all requested changes


Multitenancy support in CAPOCI

What would you like to be added:
Support Multitenancy in CAPOCI
Why is this needed:
for the current CAPOCI we tested, we created multiple clusters on different Tenancy by using One management cluster:
~  k get clusters -A
NAMESPACE   NAME            PHASE         AGE   VERSION
default     capioke         Provisioned   37h                              (# This one on Tenancy A compartment A1)
default     capoci          Provisioned   13h                              (# This one on Tenancy A compartment A2)
default     simplecluster   Provisioned   13h                        (# This one on Tenancy B compartment B1)
And in the CAPOCI controller log, we found such error info:
~  k logs capoci-controller-manager-6574d4c58-nlxp6 -n cluster-api-provider-oci-system
failed to reconcile VCN for OCICluster default/capioke: Error returned by VirtualNetwork Service. Http Status Code: 404. Error Code: NotAuthorizedOrNotFound. Opc request id: 96b0b9de49c13bd31c62771134e90561/66A16B024E825D025C4E6B533054C281/B8ABA034DB613580462A833F052E3214. Message: Authorization failed or requested resource not found.
The failed reason I guess is the credentials we used for creating simplecluster which cannot be authorized to check other clusters.
And in our env, we don't have instance principals support, we could only leverage user principals.

As per clarification

In my personal opinion Resource Principals work better for this particular use case, why we don't use them instead of plain instance principals?
How the error of not been authorized (as before) has to be handled? (Retry, terminate the operation, etc)

@yimw , for the error you are getting, it seems like you have not provided proper permissions on the network-family resource. But we tested the same and we have found a bug in OCI Service Gateway due to which network creation using CAPOCI is not working. We will update here once that bug is fixed.
@cheherna Resource Principals are not externally visible feature which CAPOCI can use, atleast as per last information I have. When we get an auth error, we go into a exponential backoff and retry mechanism.


URI Parser v2

Remove everything which is deprecated
Symplify URI parsing using RFC3986 regular expression
Make the Parser final
Make protected methods private
small bug fix within the test suite following the switch to RFC3986 regular expression

Question should we bump PHP version requirement to PHP7.1 ?
First benchmark show another performance boots to be validated with blackfire.io @kelunik or @trowski

Not sure whether requiring PHP 7.1 is warranted. What's the benefit except for one private constant over it being public?

@kelunik I'll be merging and bumping to the new version next unless there's still some blockers here :thinking: . And also PHP7.0 support is dropped since last time we spoke it went in EOL mode :smile:

I won't have time to review, sorry. But sounds good. 👍

There is indeed a clear performance boost:
Before: https://blackfire.io/profiles/54c03b2b-46c8-4d9b-a6d1-7b3ffd4d5b13/graph
After: https://blackfire.io/profiles/ce6edc6d-d7f5-48cb-8225-5026f7738cd2/graph

@tgalopin the namespace are organized to simplify URI packages structure.
So the same structure is/will be used for

URI Components v2 https://github.com/thephpleague/uri-components/tree/master/src
URI Schemes v2 https://github.com/thephpleague/uri-schemes/tree/develop/src

is already used for

URI Query parser v1 <- https://github.com/thephpleague/uri-query-parser/

All the other packages are being deprecated/phase out (3 packages will be removed)
<?php

use League\Uri\Parser\RFC3986;
use League\Uri\Parser\QueryString;
use League\Uri\Uri;
use League\Uri\Component\Query;

The base namespace is reserved for full URI objects, interfaces and Helper classes.
URI Components have their own namespace.
URI parsers have their own namespace too regardless of their package.

The goal is to release all remaining v2 package before june... if I can :smile: . Most of the coding is done only reviewing and align packages remains to be done.


install abapgit, tutorial page

looks like abapgit_install / install_abapgit was removed from the tutorial page?
so the corresponding code can be deleted
https://github.com/abapGit/abapGit/blob/fff8f1b237f43135435b7c98527ca19b5df86042/src/ui/zcl_abapgit_services_abapgit.clas.abap#L28

Seems to have been moved to debug info?
https://github.com/abapGit/abapGit/blob/1e93c1d3d360efbf646ac190aa1d3341700ca12e/src/ui/zcl_abapgit_gui_page_debuginfo.clas.abap#L115-L123

hmm, seems a bit hidden


[PE-D][Tester C] Fitadd command: Format validation for random text after specifying default supported prefixes

Input:

fitadd 1 /arms /something
fitadd 1 /arms abcdefg
fitadd 1 /arms s/ r/ b

Expected: Error message specifying invalid arguments.
Actual: Command succeeds.
Problems: This bug allows users to input fitadd 1 /arms /leg (note the typo of /leg instead of /legs), and it will succeed without any error, while the /legs exercises are not added.
Note the 3rd input too, that the command accepts s/, r/ and b/ prefixes.

Labels: type.FunctionalityBug severity.High
original: shaunlxw/ped#16

This issue is because of the current logic in FitAddCommandParser.java and FitDeleteCommandParser.java.
Currently, there is a check to ensure that the name argument cannot be simultaneously supplied with the default supported prefixes. Apart from that, any other form of prefixes or text is ignored by the parsers.
Unless it violates the feature freeze, the proposed solution is to update the user guide to mention that any other forms of prefixes or text is ignored.

make command fail if any invalid prefix is used?


Fixed typo

Closes https://github.com/fluxcd/kustomize-controller/issues/572

Also the commit name should say what this change does. Please see the here how to write commit messages: https://fluxcd.io/docs/contributing/flux/#format-of-the-commit-message


[FEATURE] Add cancel_after_time_interval to SearchRequest and MsearchRequest

Is your feature request related to a problem?
The cancel_after_time_interval parameter does not exist for search and msearch requests in the Java client.
What solution would you like?
Add cancel_after_time_interval to SearchRequest and MsearchRequest in the Java client.
What alternatives have you considered?
I have not found a workaround.
Do you have any additional context?
Being able to use this parameter is especially useful when using an AWS hosted OpenSearch cluster. Because AWS does not provide a way to set the default cancel_after_time_interval setting for a cluster, there doesn't seem to be any other way to ensure that a request which can't be handled in a reasonable time will be cancelled. We have occasionally encountered outages caused by extremely complicated, long-running search requests bogging down the cluster.
This parameter was missing from the OpenSearch Open API spec for years, and was finally added in June 2024:
https://github.com/opensearch-project/opensearch-api-specification/issues/273
I see there is work underway to generate the Java client code from the Open API specification, which hopefully will eventually provide a solution. But it would be very useful to be able to set this parameter in the interim.
https://github.com/opensearch-project/opensearch-java/pull/366 is the recently merged PR to which I am referring.

The size and complexity of the SearchRequest & query types means it's non-trivial to do the initial generation of them. If you wanted to really dig into it that'd be amazing, but I wouldn't categorise it as a "good first issue" per se. So in the meantime it is significantly easier to just add the parameter to the two request classes by hand (copying something like the scroll parameter).

I got the same issue, will this be released in the next version?

@chanon-onman A fix was just merged (thanks to @urinud) so should currently be available in 2.14.0-SNAPSHOT, I'll look to do a proper release of 2.14.0 early next week

v2.14.0 has been released and includes the fix for this issue


All fields of User-Profile object is Null except the url

For example...
{
  userProfile: {
    fullName: null,
    title: null,
    location: null,
    photo: null,
    description: null,
    url: 'https://www.linkedin.com/in/me/'
  }

Thanks for reporting! This is now fixed in master
Changes: https://github.com/jvandenaardweg/linkedin-profile-scraper/pull/5

Hi everyone!
I'm facing a similar issue and I did check I've got the latest versions from the selectors you pushed in #5 ✔ .
Judging by the logs, it seems that some "View more" buttons are being missed, given tough that such selectors are correct (manually checked them in a Browser)
export const RequestLinkedin = async ({ language }) => {
    try {
        const scraper = new LinkedInProfileScraper({
            sessionCookieValue: process.env.LI_AT_COOKIE_VALUE,
            keepAlive: process.env.NODE_ENV === 'development',
        });

        // Prepare the scraper
        // Loading it in memory
        await scraper.setup();

        const url = getURL({ language });
        const result = await scraper.run(url);

        return result;
    } catch (err) {
        if (err.name === 'SessionExpired') {
            // Do something when the scraper notifies you it's not logged-in anymore
            throw new Error('SessionExpired');
        }
        return;
    }
};

Logs
>  Scraper (setup): Launching puppeteer in the background...
>  Scraper (setup): Puppeteer launched!
>  Scraper (setup page): Blocking the following resources: image, media, font, texttrack, object, beacon, csp_report, imageset
>  Scraper (setup page): Should block scripts from 10366 unwanted hosts to speed up the crawling.
>  Scraper (setup page): Setting session cookie using cookie: undefined
>  Scraper (setup page): Session cookie set!
>  Scraper (setup page): Done!
>  Scraper (checkIfLoggedIn): Checking if we are still logged in...
>  Scraper (blocked script): xhr: dpm.demdex.net: https://dpm.demdex.net/id?d_visid_ver=5.1.1&d_fieldgroup=MC&d_rtbd=json&d_ver=2&d_orgid=14215E3D5995C57C0A495C55%40AdobeOrg&d_nsid=0&ts=1614113026516
>  Scraper (blocked script): xhr: dpm.demdex.net: https://dpm.demdex.net/id?d_visid_ver=5.1.1&d_fieldgroup=AAM&d_rtbd=json&d_ver=2&d_orgid=14215E3D5995C57C0A495C55%40AdobeOrg&d_nsid=0&d_mid=49017425936221650123187014327421593955&ts=1614113026536
>  Scraper (blocked script): xhr: dpm.demdex.net: https://dpm.demdex.net/id?d_visid_ver=5.1.1&d_fieldgroup=AAM&d_rtbd=json&d_ver=2&d_orgid=14215E3D5995C57C0A495C55%40AdobeOrg&d_nsid=0&d_mid=49017425936221650123187014327421593955&d_cid_ic=lnkdidsync%01AX1gF6l-GPXUsEfrGZfopE4VFCzS%26v%3D2%011&d_cid_ic=thirdpartyid%01AX1gF6l-GPXUsEfrGZfopE4VFCzS%26v%3D2%011&d_cid_ic=lnkd_member_id%01AX1gF6l-GPXUsEfrGZfopE4VFCzS%26v%3D2%011&ts=1614113026570
>  Scraper (checkIfLoggedIn): All good. We are still logged in.
>  Scraper (setup): Done!
>  Scraper (setup page): Blocking the following resources: image, media, font, texttrack, object, beacon, csp_report, imageset
>  Scraper (setup page): Should block scripts from 10366 unwanted hosts to speed up the crawling.
>  Scraper (setup page): Setting session cookie using cookie: undefined
>  Scraper (setup page): Session cookie set!
>  Scraper (setup page): Done!
>  Scraper (run)<PHONE_NUMBER>545): Navigating to LinkedIn profile: https://linkedin.com/in/[USER_PROFILE]/en-US
>  Scraper (run)<PHONE_NUMBER>545): LinkedIn profile page loaded!
>  Scraper (run)<PHONE_NUMBER>545): Getting all the LinkedIn profile data by scrolling the page to the bottom, so all the data gets loaded into the page...
>  Scraper (run)<PHONE_NUMBER>545): Parsing data...
>  Scraper (run)<PHONE_NUMBER>545): Expanding all sections by clicking their "See more" buttons
>  Scraper (run)<PHONE_NUMBER>545): Clicking button .pv-profile-section.pv-about-section .lt-line-clamp__more
>  Scraper (run)<PHONE_NUMBER>545): Clicking button .pv-skill-categories-section [data-control-name="skill_details"]
>  Scraper (run)<PHONE_NUMBER>545): Expanding all descriptions by clicking their "See more" buttons
>  Scraper (run)<PHONE_NUMBER>545): Clicking button .lt-line-clamp__more[href="#"]:not(.lt-line-clamp__ellipsis--dummy)
>  Scraper (run)<PHONE_NUMBER>545): Clicking button .lt-line-clamp__more[href="#"]:not(.lt-line-clamp__ellipsis--dummy)
>  Scraper (run)<PHONE_NUMBER>545): Clicking button .lt-line-clamp__more[href="#"]:not(.lt-line-clamp__ellipsis--dummy)
>  Scraper (run)<PHONE_NUMBER>545): Clicking button .lt-line-clamp__more[href="#"]:not(.lt-line-clamp__ellipsis--dummy)
>  Scraper (run)<PHONE_NUMBER>545): Could not find or click see more button selector "JSHandle@node".
So we skip that one.
>  Scraper (run)<PHONE_NUMBER>545): Clicking button .lt-line-clamp__more[href="#"]:not(.lt-line-clamp__ellipsis--dummy)
>  Scraper (run)<PHONE_NUMBER>545): Could not find or click see more button selector "JSHandle@node".
So we skip that one.
>  Scraper (run)<PHONE_NUMBER>545): Parsing profile data...
>  Scraper (run)<PHONE_NUMBER>545): Got user profile data: {"fullName":null,"title":null,"location":null,"photo":null,"description":null,"url":"https://www.linkedin.com/feed/"}
>  Scraper (run)<PHONE_NUMBER>545): Parsing experiences data...
>  Scraper (run)<PHONE_NUMBER>545): Got experiences data: []
>  Scraper (run)<PHONE_NUMBER>545): Parsing education data...
>  Scraper (run)<PHONE_NUMBER>545): Got education data: []
>  Scraper (run)<PHONE_NUMBER>545): Parsing volunteer experience data...
>  Scraper (run)<PHONE_NUMBER>545): Got volunteer experience data: []
>  Scraper (run)<PHONE_NUMBER>545): Parsing skills data...
>  Scraper (run)<PHONE_NUMBER>545): Got skills data: []
>  Scraper (run)<PHONE_NUMBER>545): Done! Returned profile details for: https://linkedin.com/in/[USER_PROFILE]/en-US
>  Scraper (run): Done. Puppeteer is being kept alive in memory.
>  {
>    userProfile: {
>      fullName: null,
>      title: null,
>      location: null,
>      photo: null,
>      description: null,
>      url: 'https://www.linkedin.com/feed/'
>    },
>    experiences: [],
>    education: [],
>    volunteerExperiences: [],
>    skills: []
>  }


Target Frame issues with long time RNG attempts

Hello,
So, I've had issues attempting long time/frame RNGs.  I don't know an exact number for where it seems to give me issues, but, I've had issues with attempts after around 500,000 frames, where, when using the timeline function, and safe frames only, I seem to be unable to land on my seed.
Here's a specific.
using Safe F Only, Shiny Only, attempting Poipole on UM.
3DSRNGTool says on frame 19976314, there is a Shiny 31/31/31/30/30/31.  38 hours of waiting.
NPC Count is 5
When I get close to the frame, I pause to advance slowly to get to my frame.  I notice it is advancing at 5 frames per advancement, but, is on numbers ending in 3 and 8 instead of 4 and 9.  At one point it changes to 2 and 7, and then back to 3 and 8.  I get to my target, and land 1 frame short.
3DSRNGTool should not have given me a result of 19976314 if I can't land on that frame based on the data input when I was setting up the RNG, so i'm trying to figure out if this is something i'm doing wrong (Which, if I can get sub 500,000 frame RNGs to work consistently, I don't see how, but i'm open to there being an issue i'm causing), if this is an issue with the Tool, and issue with my 3DS (launch console), or what.  If there is any more information I can provide, please let me know.

Do you remember your starting frame and did you check if the timeline match before long run?
Can't debug others procedure and according to gbatemp, several days are not a problem.

I unfortunately don't have my starting frame, but I used the Safe F Only with the initial frame with filters disabled, advanced to a frame indicated, then created a Timeline with the correct IVs I was looking for.

Ok, here's some info.  Trying the Timeline calibration.  On the latest release of 3DSRNGTool
Game: Ultra Moon
SEED: 0B438989
Initial Frame: 1963 (Safe F Only)
created timeline.  At less than 3000 frames the Timeline is off by 1 frame.  Example, 3DSRNGTool is telling me 3548, 3552, 3556, 3560, 3564, 3568.
Game is giving me: 3549, 3553, 3557, 3561, 3565, 3569

Did you follow the procedure [here](https://github.com/wwwwwwzx/3DSRNGTool/wiki/Gen7-Timeline-Calibration-(PokeCalcNTR-Only)
Especially Step 1 and Step 7

Try to change the standing position and make NPC count stable.

Hit a frame up to 10,000,000 and timeline is stable for 19 hours without any issue.


Socket.io issue

Hi
http://localhost:52653/socket.io/?userid=pu4059&msgEvent=video-conference-d…mEvent=RTCMultiConnection-Custom-Message&EIO=3&transport=polling&t=LSdUS9b 403 (Forbidden)
Iam getting socket.io not found.
Can any one help me in this..

Usually there is no need to call the url with socket.io as path. Have you tried to use localhost:52653 only? Socket.io should work in background.

same error for me also


Allow the user to select the timezone of the chosen datetime

Describe the solution you'd like
I'd like to allow users to choose the timezone that the datetime is in so they can pick dates easily from other timezones. Timezone aware dates passed to the picker should also render the timezone information.

This should be reopened


Caching interface should be improved

Not everyone wants to type out all the methods they want to cache...
Some people might want to cache the entire static service
Some people might want to cache specific method ttls.

This is high-priority now.
Still TBD (+ I haven't got good sleep for the past few days so this might be worded badly) but this is a high-level overview..
Firstly, a useDefault cache options property will be added. By default, it will be set to false.
This will allow users to:

still have fine-grained control over specific method caching with existing ttls object property
use the default caching object (if Riot has one we'll use that) while still being able to override specific ttls
not make existing users cache random stuffs when upgrading (backwards-compatible pls)

The caching priority will be:

any (method name, ttl in milliseconds) pair in  ttls will override everything else (so for now, just the default ttl object) because it is the most specific way of setting a ttl
any default ttl that has not been overrided

So the cache and ttls properties will function the same. Any specific ttl key-value pair will override the specific key-value pair in the default.
For example...
Let's say the Summoner.by.name() is cached for 1 day by default.
Kayn()({
    cacheOptions: {
        cache: BasicJSCache() or RedisCache or whatever,
        useDefault: true,
        ttls: {
            [METHOD_NAMES.SUMMONER.GET_BY_SUMMONER_NAME]: 3000 //ms
        }
    },
})

Initially, the cache timer for Summoner.by.name would be 1 day (in milliseconds) since useDefault is turned on. However, since we have the ttls property with the specific key-value pair, the cache timer is now 3 seconds (in milliseconds).
Extra
I also want to be able to set the ttl of an entire collection of methods (grouped as in Riot's docs).

How far are you? I'm going to put in some hours today learning RedisCache and figure out how to cache the matches on the server - I'll share the code with the community if I figure it out.

I can probably finish a basic implementation of everything mentioned in the post, along with tests, on Wednesday. It's pretty much just merging objects.
I'll probably also make a small website that allows you to just input TTLs, and it will format the JSON for you automatically.

That's really cool man - I just made my first redis server lol. Thank you for this, btw, you should add your BTC address at the bottom if you're not already too rich xD


Merge Creatable updates from upstream

This PR merges https://github.com/JedWatson/react-select/pull/1207 and https://github.com/JedWatson/react-select/pull/1213 into react-select-plus. Both PRs update the new Creatable feature. The first allows it to be used in conjunction with Async. The latter fixes some bugs, notably one that prevented the same tag from being created multiple times:
Before

After

Published as 1.0.0-rc.1.patch2.


Demo Runs Very High CPU Load

Just tried it in Windows, showing around 20-25% CPU load.

That's fine, it's not really an issue for a demo, it's a while loop calling win32 PeekMsg, there is no no-op so nothing is preventing the while loop from just spinning as fast as possible.
In the Demo you can change trayIcon?.DoMessageLoop(false); to trayIcon?.DoMessageLoop(true); and the call will use win32 GetMessage, which is a no-op wait.
If you are using this in Avalonia, you do not need to call DoMessageLoop at all, luckily, as Avalonia is already running a message loop for you!

`using Avalonia;
using Avalonia.Controls;
using Avalonia.Controls.ApplicationLifetimes;
using Avalonia.Markup.Xaml;
using Avalonia.Threading;
using MonoMac.AppKit;
using MonoMac.Foundation;
using NotificationIconSharp;
using System.ComponentModel;
using System.Runtime.InteropServices;
using Tdvx.Updater.HelperCore.Views;
namespace Tdvx.Updater.HelperCore
{
public class App2 : Application
{
private MainWindowView _mainWindow = null;
private NotificationIcon _notificationIcon = null;
    public override void Initialize()
    {
        AvaloniaXamlLoader.Load(this);
    }

    public override void OnFrameworkInitializationCompleted()
    {
        /// Handle Initializing the NSApplication and setting an appropriate
        /// app delegate override for the app.  This currently uses Avalonia's
        /// MonoMac.NetStandard fork from the old Mono framework, this can be
        /// moved to Native if we ever have issues, but these APIs haven't
        /// changed in 13 years based on monos checkins
        if (RuntimeInformation.IsOSPlatform(OSPlatform.OSX))
        {
            NSApplication.Init();
            NSApplication.SharedApplication.Delegate = new OSXAppDelegate();
        }
        if (ApplicationLifetime is IClassicDesktopStyleApplicationLifetime desktop)
        {

            desktop.MainWindow = new MainWindowView();
        }
        base.OnFrameworkInitializationCompleted();
        if (_notificationIcon == null)
        {
            // Create the notification tray icon, this should be the main thread anyways
            _notificationIcon = new NotificationIcon("path to icon.png/ico");
            _notificationIcon.NotificationIconSelected += Icon_NotificationIconSelected;
        }
    }

    /// <summary>
    /// show and/or create the main window instance if necessary
    /// </summary>
    public void RestoreMainWindow()
    {
        var desktopApplicationLifetime = Current.ApplicationLifetime as IClassicDesktopStyleApplicationLifetime;
        if (_mainWindow == null)
        {
            _mainWindow = new MainWindowView();
            _mainWindow.Closing += MainWindow_Closing;
        }
        if (desktopApplicationLifetime?.MainWindow != _mainWindow)
        {
            desktopApplicationLifetime.MainWindow = _mainWindow;
        }
        _mainWindow.Show();
        _mainWindow.WindowState = WindowState.Normal;
        _mainWindow.BringIntoView();
        _mainWindow.Focus();
        ShowApplicationInstance();
    }

    /// <summary>
    /// Exit the application
    /// </summary>
    public void Exit()
    {
        (Current.ApplicationLifetime as IClassicDesktopStyleApplicationLifetime).Shutdown(0);
    }

    /// <summary>
    /// OSX Helper function used to Hide the dock icon when running as a daemon
    /// </summary>
    public static void HideApplicationInstance()
    {
        if (RuntimeInformation.IsOSPlatform(OSPlatform.OSX))
        {
            NSApplication.SharedApplication.ActivationPolicy = NSApplicationActivationPolicy.Accessory;
        }
    }

    /// <summary>
    /// OSX Helper function used to Show the dock icon when running as a daemon
    /// </summary>
    public static void ShowApplicationInstance()
    {
        if (RuntimeInformation.IsOSPlatform(OSPlatform.OSX))
        {
            NSApplication.SharedApplication.ActivationPolicy = NSApplicationActivationPolicy.Regular;
        }
    }

    private void MainWindow_Closing(object sender, CancelEventArgs e)
    {
        _mainWindow?.Hide();
        _mainWindow = null;
        HideApplicationInstance();
    }

    private void Icon_NotificationIconSelected(NotificationIcon icon)
    {
        Dispatcher.UIThread.Post(() =>
        {
            RestoreMainWindow(); // Restore main window on notification icon click
        });
    }
}

/// <summary>
/// OSX Helper class, overrides Avalonias default AppDelegate to give us more
/// control over a few pieces of behavior allowing us to get away with some
/// stuff in a system daemon that the Avalonia devs didn't anticipate ;-)
/// </summary>
public class OSXAppDelegate : NSApplicationDelegate
{
    public OSXAppDelegate()
    {
        AvaloniaLocator.CurrentMutable.Bind<OSXAppDelegate>().ToConstant(this);
    }

    /// <summary>
    /// Because we are creating our own mac application delegate we are removing / overriding
    /// the one that Avalonia creates. This causes the application to not be handled as it should.
    /// This is the Avalonia Implementation: https://github.com/AvaloniaUI/Avalonia/blob/5a2ef35dacbce0438b66d9f012e5f629045beb3d/native/Avalonia.Native/src/OSX/app.mm
    /// So what we are doing here is re-creating this implementation to mimick their behavior.
    /// </summary>
    /// <param name="notification"></param>
    public override void WillFinishLaunching(NSNotification notification)
    {
        if (NSApplication.SharedApplication.ActivationPolicy != NSApplicationActivationPolicy.Regular)
        {
            foreach (var x in NSRunningApplication.GetRunningApplications(@"com.apple.dock"))
            {
                x.Activate(NSApplicationActivationOptions.ActivateIgnoringOtherWindows);
                break;
            }

            NSApplication.SharedApplication.ActivationPolicy = NSApplicationActivationPolicy.Accessory;
        }
    }

    /// <summary>
    /// Because we are creating our own mac application delegate we are removing / overriding
    /// the one that Avalonia creates. This causes the application to not be handled as it should.
    /// This is the Avalonia Implementation: https://github.com/AvaloniaUI/Avalonia/blob/5a2ef35dacbce0438b66d9f012e5f629045beb3d/native/Avalonia.Native/src/OSX/app.mm
    /// So what we are doing here is re-creating this implementation to mimick their behavior.
    /// </summary>
    /// <param name="notification"></param>
    public override void DidFinishLaunching(NSNotification notification)
    {
        NSRunningApplication.CurrentApplication.Activate(NSApplicationActivationOptions.ActivateIgnoringOtherWindows);
    }
}`

There's some Demo Code attached for an avalonia app, to run it as a Windows Run on Login application, and as an OSX LaunchAgent
If you are running as a LaunchAgent you need the OSXAppDelegate and MonoMac NetStandard nuget (by the avalonia team), this keeps the icon for the avalonia app from always being in the OSX dock.
As you'll notice, there's no need for the message pumping that's eating the CPU for you :D

@seanocali I flipped the wait flag for the runloop in the demo app, you should see less CPU useage.


Corrected a lot of Spelling Mistakes

The Whole documentation contains  a lot of spelling mistakes

I'm sorry these are mostly incorrect. There's no need to capitalize URL portions, and you're changing spelling from US English to British English, which isn't necessary.


Forcibly republish the package with the same version

Is your feature request related to a problem? Please describe.
Let's have a situation that I want to keep my package version in sync with other software. I.e.: my-dto:1.2.3, other-software:1.2.3. The problem following: once I have published the package, I can't easily unpublish it nor forcibly update it. The question is: Is there any way to forcibly republish the package in my private Verdaccio instance with the same version?
Describe the solution you'd like
I want to be able to forcibly update the package which has already been published.
Describe alternatives you've considered
or at least be able to unpublish it quickly and then publish it again, so I don't need to remove entries from the database to erase old package.
Additional context

I stripped fragile data with XXX.
My Verdaccio version: 4.1.0

The package is already published by in my registry under https://npm.XXX.systems/@my-dto

yarn publish --registry=https://npm.XXX.systems
yarn publish v1.17.3
[1/4] Bumping version...
info Current version: 9.4.0
question New version: 9.4.0
[2/4] Logging in...
[3/4] Publishing...
error Couldn't publish package: "https://npm.XXX.systems/@my%2fdto: this package is already present"
info Visit https://yarnpkg.com/en/docs/cli/publish for documentation about this command.

I think this is good to not republish a package. Use test to avoid publishing a package with a wrong version. If you fix, then publish a new version. npm allow to unpublish and republish package in a short amount of time.

Please remember that people use Verdaccio for development. Trying to add a feature to @storybookjs is currently a massive headache - I have spent the last two hours trying to figure out how to get Verdaccio to play nice.
I'm developing locally.  If I write --force, I mean it. Let me publish over versions without having to unpublish.
If you're really scared about this, at least let me specify it in the Verdaccio configuration that force publishes are OK.

what is wrong with npm unpublish ?

what is wrong with npm unpublish ?

npm unpublish would be a 2x step process, which some environments cannot afford, for instance CI or just annoying increase the version manually if you don't use Lerna or something sophisticated .
Also there is a trade off with such command, I refer to the official doc.

If no version is specified, or if all versions are removed then the root package entry is removed from the registry entirely.

Thus, Verdaccio will remove the whole package if you had only one version. Thus, npm publish --force becomes handy.
So, referring to then @egel pain, I had also that pain and we have been discussing internally how to achieve it in a safe way and by demand. One of the ideas is introduce the development mode, either via configuration or flag, eg:
$> verdaccio --dev

This is still just an idea and has a lot of tradeoff, for instance uplinks, possibles side effects we need to research first.

A dev mode sounds good.

Is there any progress with the issue?Writing due to bot reminder.

@egel it's on the queue, but no progress yet. Sorry for the bot, should not be trigger if is already scheduled for dev.

+1 to @Qix-
We use verdaccio for E2E tests. If add a uplink to the package, it won't allow me to publish even once into the locally running verdaccio instance, even though it does not contain any versions of the package. Because of the uplink it hits the uplink and downloads the version of the package and returns error saying can't publish over existing version. I would expect verdaccio to not hit the uplink in which case it would allow me to publish.

@haquezameer same issue here. Have you found a workaround?

@kachkaev Yes. So I actually separated my verdaccio configs into two separate configs: verdaccio-publish.yaml and verdaccio-install.yaml.
I only add the uplinks config in verdaccio-install.yaml and do not add any uplinks in verdaccio-publish.yaml. This prevents verdaccio from connecting to the uplink when publishing and allows me to publish to the local registry. Then while installing I start verdaccio with verdaccio-install.yaml.

I'm interested in the same mechanism.
I'm wondering: when republishing with the same version, wouln't this cause a lockfile checksum violation when re-installing the package? I don't know exactly what npm/yarn/etc.. do when the checksum does not match, but I expect them to abort the installation.

npm unpublish --force and then republish seems to work?


With ganache-cli and mainnet-fork got 'Method eth_maxPriorityFeePerGas not supported.' error

With Ganache CLI v6.12.2 and mainnet-fork got error :
 'Method eth_maxPriorityFeePerGas not supported.'
on make_trade() call.

You need to use Ganache CLI v7, as v6 doesn't support EIP-1559 transactions.


Add Procfile

For Heroku deployment.
https://devcenter.heroku.com/articles/deploying-go#the-procfile
I think for this app, it'd be:
web: gomfweb

Fixed in https://github.com/willnorris/gomfweb


Fix: correct close button color in IE11

Jira
http://vjira2:8080/browse/BDS-1698
Summary
Fixes the color of the modal's close button in IE11.
Details
Updated the theme logic in JS to apply to close button and used that to determine whether the button should be light or dark.
How to test
Run this fix in Drupal and test the video modal on this page. Use IE11 and make sure the close button is displaying the correct color. https://staging-www.pega.com/products/crm-applications

@mikemai2awesome, looks like you need to update the jest snapshots to get the tests to pass.


Use React Native from node_modules

It wasn't probably a desired behaviour. Since maven contains outdated React, that's why it was throwing that the DeviceEventEmitter is not there etc. After changing it to use the node_modules one, it works again and all classes that are available in the currently installed React are working.

PS. That fixes the master breaking with RCTNativeAppEventEmitter class is not found.


JavaScript

This is my JavaScript that I did for the project, I also centered the "Theme" buttons

I forgot to mention that the cursor now has an explosion effect when you click the mouse.


Allow Storage Host Configuration with Property

resolves #91
Sadly restrictToAnnotatedClass is not yet available (higher quarkus version?), if the global nature is a problem we could use QuarkusTestResources. But imo it's fine.
Google is a bit incosistent about the naming.

Client Library
Configure Endpoint

Datastore
setHost(hostport)

Firestore
setHost(hostport)

Spanner
setEmulatorHost(hostport)

Pub/Sub
setChannelProvider with forTarget(hostport) / setEndpoint(endpoint)

Bigtable
setChannelProvider with forTarget(hostport) / setEndpoint(endpoint)

So for datastore I now went with quarkus.google.cloud.storage.host-override, similar to quarkus.sqs.endpoint-override.
Any feedback appreciated.

Thanks for the PR, I'll try to review it soon.

Sadly restrictToAnnotatedClass is not yet available (higher quarkus version?), if the global nature is a problem we could use QuarkusTestResources. But imo it's fine.

I'll plan to upgrade to Quarkus 1.13 soon, I can do it today so you can rebase on the latest version to use it.

@PeterUlb I updated to Quarkus 1.13, you should be able to use restrictToAnnotatedClass  now

@all-contributors please add @PeterUlb for code


Error on example

I guess there's an error on SimpleBlocDelegate test on the example: https://github.com/brianegan/flutter_architecture_samples/blob/master/bloc_library/test/blocs/simple_bloc_delegate_test.dart
The onEvent test is refering to the delegate.onError

Thanks, fixed!


MUC Invite

Hi, I am struggling to find out how to use the muc invite functionality. directInvite works but I can only invite one user. How do I use the client.invite functionality to be able to invite more than one user at once. Also, what happens if the room is public, how to invite the roster (or how do they discover the newly added room). I see opts in the documentation but I dont know which ones to use. Of course I will document this after I am finished and make a pull request
Thanks in advance

ok, so opts should be an array containing the list of users you want to invite.
like this:
var opts =[{to="username<EMAIL_ADDRESS>client.invite(room,opts)
Hope this helps you.

I know its too late but this could be useful for others. Working for me.
var opts =[{to<EMAIL_ADDRESS><EMAIL_ADDRESS>client.invite(room, opts)

It's working but it just sends the invitation. Is there any way to auto join multiple members in the room OR how to handle invitation from other users?


[SPARK-11779][DOCS] Fix reference to deprecated MESOS_NATIVE_LIBRARY

MESOS_NATIVE_LIBRARY was renamed in favor of MESOS_NATIVE_JAVA_LIBRARY. This commit fixes the reference in the documentation.

Can one of the admins verify this patch?

That's correct as of the version supported in Spark 1.5?

Test build #2076 has started for PR 9768 at commit 82a261d.

Test build #2076 has finished for PR 9768 at commit 82a261d.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

@srowen : its deprecated in mesos since 0.19 (still supported though) (https://github.com/apache/mesos/commit/5c174df1a9a81e52f6a82b5986b0a337921ed1a8), Spark 1.5 supports 0.21.1, seems fine to me :)

Merged to master/1.6


Avoid unnecessary String computation during build operation creation

(Display) names might only be needed later (or not at all). They could be derived from context instead of being computed up-front.
Related: #1688

I'm pretty sure the display name is always needed. The moment you create a build operation, you know it is going to be executed. And when it is executed, it will get logged on the console, captured by build scans etc.

I started the discussion here (as both issues are strongly connected):
https://github.com/gradle/gradle/issues/1688#issuecomment-292194496
Closing this one.


Xcode 15 Warning

Hello.
Thank you for PromiseKit.
Fix #1323.

Thank you for your continued assistance.


Create a release

Hi! Just found this and gave it a spin. It indeed works for the (limited) use case I have atm, and want to package it as a build2 package. Though for this it sure would be better if there is a release tag I can rely on.
Thanks!

Hi! I can create an arbitrary release like v0.1 from the current sources - would that be enough?

Absolutely!

Done: https://github.com/mikekazakov/pstld/releases/tag/0.1.0

FYI I've publish it as a build2 package now: https://queue.cppget.org/pstld?q=pstld

Great, thanks!


User Guide authentication recommendations

Description
This is my last ditch effort at getting some consistency around user definitions in before release.
Checklist:

[X] Securely signed commits
[X] Component(s) with PHPdocs
n/a Unit testing, with >80% coverage
[X] User guide updated
[X] Conforms to style guide

I'm ok with this approach. :)


feat: Removes the Multiple Line Charts

SUMMARY
This PR removes the Multiple Line Charts.

Removes the legacy chart code and unregisters the plugin.
Removes old plugin references throughout the codebase
Updates unit tests
Updates E2E tests
Updates the example dashboards
Updates translation files

The Multiple Line Charts description says that it's deprecated and people should use the Mixed chart instead. The problem is that Multiple Line Charts allows you to select 2 charts which may reference different datasets while Mixed Chart only allows 1 dataset. This means that to compare values from different datasets using a Mixed chart you would need to create another dataset combining the source datasets. Given that this chart is marked as deprecated for a long time, a migration would required significant effort, and its adoption is pretty low, we decided to remove it. If someone still has this chart and tries to access it, the following screen will be displayed:

AFTER SCREENSHOT

TESTING INSTRUCTIONS
1 - Make sure all Multiple Line Charts were removed
2 - Make sure Multiple Line Charts is not available anymore in the viz picker
ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

@michael-s-molina from a UX perspective if a user is presented with this message there's no real clear way forward, i.e., they're not able to see what the legacy chart looks like and thus can't easily recreate it in a different form.
Rather than simply deleting the chart type, would it be preferable to provide a toast which states that this chart type is deprecated and will be removed in Superset 4.0. Additionally the toast should mention that the chart must be manually migrated.

Rather than simply deleting the chart type, would it be preferable to provide a toast which states that this chart type is deprecated and will be removed in Superset 4.0. Additionally the toast should mention that the chart must be manually migrated.

@john-bodley This chart type was marked as deprecated in a previous major version and people had more than a year to migrate from it. It's related to a 2.0 -> 3.0 cycle as opposed to 3.0 -> 4.0.


Packaged version with electron-packager version 12.x fails to start

With latest versions app fails to start because missing node modules.
DEBUG=electron-packager
electron-packager . --asar
Packaging app for platform darwin x64 using electron v2.0.0
Wrote new app to /Users/vassilev/Projects/inkspace/Wacom Inkspace App-darwin-x64
Package is created successfully but when app is started there is exception. This exception is available only after packaging. I have added 'ansi-regex' in dependencies, but then 'code-point-at' is missing and so on for may be 7-8 modules more. Package with 11.2.0 do not have problems and missing packages. I'm using lates npm and electron. if you need my package.json I can include it.
module.js:485 Uncaught Error: Cannot find module 'ansi-regex'
at Module._resolveFilename (module.js:485)
at Function.Module._resolveFilename (/Applications/Wacom Inkspace App.app/Contents/Resources/electron.asar/common/reset-search-paths.js:35)
at Function.Module._load (module.js:437)
at Module.require (module.js:513)
at require (internal/module.js:11)
at Object. (/Applications/Wacom Inkspace App.app/Contents/Resources/app.asar/node_modules/strip-ansi/index.js:2)
at Object. Module._compile @ module.js:569
Module._extensions..js @ module.js:580
Module.load @ module.js:503
tryModuleLoad @ module.js:466
Module._load @ module.js:458
Module.require @ module.js:513
require @ internal/module.js:11
(anonymous) @ /Applications/Wacom Inkspace App.app/Contents/Resources/app.asar/node_modules/usb/usb.js:1
(anonymous) @ /Applications/Wacom Inkspace App.app/Contents/Resources/app.asar/node_modules/usb/usb.js:408
Module._compile @ module.js:569
Module._extensions..js @ module.js:580
Module.load @ module.js:503
tryModuleLoad @ module.js:466
Module._load @ module.js:458
Module.require @ module.js:513
require @ internal/module.js:11
(anonymous) @ bufferPsdWriter.ts:3
webpack_require @ manifest.js:55
(anonymous) @ bufferPsdWriter.ts:3
webpack_require @ manifest.js:55
module.exports.Object.defineProperty.value @ bufferPsdWriter.ts:3
webpack_require @ manifest.js:55
webpackJsonpCallback @ manifest.js:26
(anonymous) @ main.js:2

Output from packager:
electron-packager .. --overwrite --asar --ignore="app-scripts|test" --icon=../app-icon/mac/app.icns --out=../../out
electron-packager Electron Packager 12.0.2 +0ms
electron-packager Node v8.4.0 +1ms
electron-packager Host Operating system: darwin (x64) +0ms
electron-packager Packager Options: {"_":[".."],"deref-symlinks":true,"derefSymlinks":true,"download":{"strictSSL":true},"prune":true,"overwrite":true,"asar":true,"ignore":"app-scripts|test","icon":"../app-icon/mac/app.icns","out":"../../out","dir":"..","protocols":[]} +0ms
electron-packager Target Platforms: darwin +0ms
electron-packager Target Architectures: x64 +0ms
electron-packager Inferring application name from productName in /Users/vassilev/Projects/mate-desktop/package.json +0ms
electron-packager Inferring appVersion from version in /Users/vassilev/Projects/mate-desktop/package.json +3ms
electron-packager Inferring target Electron version from electron in /Users/vassilev/Projects/mate-desktop/package.json +10ms
electron-packager Application name: Wacom Inkspace App +28ms
electron-packager Target Electron version: 2.0.0 +0ms
electron-packager Ignored path regular expressions: [ 'app-scripts|test',
'/\.git($|/)',
'/node_modules/\.bin($|/)',
'\.o(bj)?$' ] +0ms
electron-packager Downloading Electron with options {"strictSSL":true,"platform":"darwin","arch":"x64","version":"2.0.0"} +0ms
Packaging app for platform darwin x64 using electron v2.0.0
electron-packager Creating /var/folders/wd/kpjczcbd28q_sbq6njl38zrw0000gn/T/electron-packager/darwin-x64-template +2s
electron-packager Extracting /Users/vassilev/.electron/electron-v2.0.0-darwin-x64.zip to /var/folders/wd/kpjczcbd28q_sbq6njl38zrw0000gn/T/electron-packager/darwin-x64-template +0ms
electron-packager Initializing app in /var/folders/wd/kpjczcbd28q_sbq6njl38zrw0000gn/T/electron-packager/darwin-x64/Wacom Inkspace App-darwin-x64 from /var/folders/wd/kpjczcbd28q_sbq6njl38zrw0000gn/T/electron-packager/darwin-x64-template template +0ms
electron-packager Ignored paths based on the out param: [ '/Users/vassilev/Projects/out' ] +4s
electron-packager Running asar with the options {} +4m
electron-packager Copying icon "../app-icon/mac/app.icns" to app's Resources as "electron.icns" +0ms
electron-packager Renaming Electron to Wacom Inkspace App in /var/folders/wd/kpjczcbd28q_sbq6njl38zrw0000gn/T/electron-packager/darwin-x64/Wacom Inkspace App-darwin-x64/Electron.app/Contents/MacOS +7s
electron-packager Renaming Electron Helper to Wacom Inkspace App Helper in /var/folders/wd/kpjczcbd28q_sbq6njl38zrw0000gn/T/electron-packager/darwin-x64/Wacom Inkspace App-darwin-x64/Electron.app/Contents/Frameworks/Electron Helper.app/Contents/MacOS +1ms
electron-packager Renaming Electron Helper EH to Wacom Inkspace App Helper EH in /var/folders/wd/kpjczcbd28q_sbq6njl38zrw0000gn/T/electron-packager/darwin-x64/Wacom Inkspace App-darwin-x64/Electron.app/Contents/Frameworks/Electron Helper EH.app/Contents/MacOS +1ms
electron-packager Renaming Electron Helper NP to Wacom Inkspace App Helper NP in /var/folders/wd/kpjczcbd28q_sbq6njl38zrw0000gn/T/electron-packager/darwin-x64/Wacom Inkspace App-darwin-x64/Electron.app/Contents/Frameworks/Electron Helper NP.app/Contents/MacOS +0ms
electron-packager Renaming Electron Helper.app to Wacom Inkspace App Helper.app in /var/folders/wd/kpjczcbd28q_sbq6njl38zrw0000gn/T/electron-packager/darwin-x64/Wacom Inkspace App-darwin-x64/Electron.app/Contents/Frameworks +1ms
electron-packager Renaming Electron Helper EH.app to Wacom Inkspace App Helper EH.app in /var/folders/wd/kpjczcbd28q_sbq6njl38zrw0000gn/T/electron-packager/darwin-x64/Wacom Inkspace App-darwin-x64/Electron.app/Contents/Frameworks +0ms
electron-packager Renaming Electron Helper NP.app to Wacom Inkspace App Helper NP.app in /var/folders/wd/kpjczcbd28q_sbq6njl38zrw0000gn/T/electron-packager/darwin-x64/Wacom Inkspace App-darwin-x64/Electron.app/Contents/Frameworks +0ms
electron-packager Moving /var/folders/wd/kpjczcbd28q_sbq6njl38zrw0000gn/T/electron-packager/darwin-x64/Wacom Inkspace App-darwin-x64 to ../../out/Wacom Inkspace App-darwin-x64 +2ms
Wrote new app to ../../out/Wacom Inkspace App-darwin-x64

I just ran into a similar issue with. In my case the new pruning method removes a folder in a module that contains only a package.json file. I don't know if this is the same problem as the OP but the resulting error in both cases is that a require fails, because the packaged app is missing a module. I guess this is a galactus issue?

I have created test scenario.
get  electron-quick-start
edit render.js
const usb = require("usb");
let list = usb.getDeviceList();
console.log(list)
update package.json
"devDependencies": {
"babel-core": "^6.26.3",
"babel-loader": "^7.1.4",
"babel-plugin-inline-react-svg": "^0.5.2",
"babel-plugin-transform-remove-strict-mode": "0.0.2",
"babel-preset-env": "^1.7.0",
"babel-preset-react": "^6.24.1",
"babel-preset-react-optimize": "^1.0.1",
"babel-preset-stage-0": "^6.24.1",
"clean-webpack-plugin": "^0.1.19",
"concurrently": "^3.5.1",
"cross-env": "^5.1.5",
"css-loader": "^0.28.11",
"electron": "^2.0.0",
"electron-devtools-installer": "^2.2.4",
"extract-text-webpack-plugin": "^3.0.2",
"file-loader": "^1.1.11",
"html-loader": "^0.5.5",
"ignore-loader": "^0.1.2",
"style-loader": "^0.21.0",
"webpack": "^3.11.0"
},
"dependencies": {
"ag-psd": "^1.2.2",
"glob": "^7.1.2",
"immutable": "^3.8.2",
"jpeg-js": "^0.3.4",
"jwt-js": "^0.5.0",
"pngjs": "^3.3.3",
"prop-types": "^15.6.1",
"rc-slider": "^8.6.1",
"rc-tooltip": "^3.7.2",
"react": "^16.3.2",
"react-dom": "^16.3.2",
"react-intl": "^2.4.0",
"react-intl-redux": "^0.7.0",
"react-list": "^0.8.7",
"react-loader": "^2.4.5",
"react-notification": "^6.8.2",
"react-redux": "^5.0.7",
"react-router": "^4.2.0",
"react-router-dom": "^4.2.2",
"react-router-redux": "^4.0.8",
"react-scrollbar": "^0.5.4",
"react-tabs": "^2.2.2",
"redux": "^4.0.0",
"redux-thunk": "^2.2.0",
"threads": "^0.11.0",
"universal-analytics": "^0.4.16",
"uuid": "^3.2.1"
},
"optionalDependencies": {
"bluetooth-serial-port": "^2.1.6",
"node-bluetooth": "^1.2.2",
"gl": "^4.0.4",
"leveldown": "^1.8.0",
"levelup": "^1.3.9",
"noble": "^1.9.1",
"serialport": "^6.1.1",
"usb": "^1.3.1"
}
electron-packager . --asar

I have created test scenario.

Can we lose some of the dependencies there, I'm down to fix this if it's a bug but I'm not going to go traipsing through 25+ deps to find the one causing the issue.  If anyone can provide a minimal test case (quick-start with one or two extra deps) I'll take a look

OK minified package.json
"devDependencies": {
"electron": "^2.0.0"
},
"optionalDependencies": {
"usb": "^1.3.1"
}

@MarshallOfSound is galactus supposed to remove contents within a (direct) dependency? Because that's what is happening in my case. I have a direct dependency redux-saga; after installing the module there is a ./node_modules/redux-saga/effects/package.json (nothing else in that folder, its main pointing to a different folder); what's more, effects is not automatically loaded if you require just redux-saga (so it would be easy to miss if modules are being trimmed by default). After running electron-compile with prune enabled, redux-saga is included in the target, but the effects folder is missing. Is this something that could be caused by galactus or should I look elsewhere?
Thanks for your awesome work!

@tzvetelin-vassilev usb is a native module, so:

you should be using electron-rebuild if you aren't already
You can't use asar with native modules, so you'll need to either blacklist the module directories (see the asar sub-options for details) or not use asar at all

@inukshuk I'm pretty sure galactus doesn't look for package.json files unless they're in node_modules/name_of_module/package.json. It would help if you also gave a minimal testcase.

Is galactus supposed to trim the contents of modules? To repeat, in my case the required module is redux-saga; this module survives the pruning just fine, but one of its sub-folders is gone. In this specific case, the folder contains a package.json but for all intents and purposes it could be an arbitrary .json file. Again, I'm not talking about a full NPM module that's gone missing, but a single folder in a module. I was under the impression that the prune option is supposed to filter out only development dependencies and does not try to further optimize the contents production dependencies.
Here is my test case:
$ mkdir tmp
$ cd tmp
$ npm init
$ npm i electron electron-packager --save-dev
$ npm i redux-saga
$ $(npm bin)/electron-packager . test --platform=linux

And then:
$ ls -l node_modules/redux-saga/effects/package.json
$ ls -l test-linux-x64/resources/app/node_modules/redux-saga/
And note that the effects folder is missing.

galactus removes entire NPM modules if it is found to not be a production dependency. Of course, I just realized that it is probably a bug in Electron Packager itself. Could you file a separate bug? This is not related to the original issue.

Will do, thanks for taking a look at it!

Given the minimal testcase of the original issue submitter, I'm fairly confident that the answer I gave in https://github.com/electron-userland/electron-packager/issues/844#issuecomment-389582609 is the reason why the package wasn't working, so I'm closing this issue.

I'm not pretty sure that asar arg fix the problem. Under Windows I don't use asar at all because squirrel problem and i have the same issue there. Also under Mac i have removed asar and package test case without any args - now i recieve 'Cannot find process-nextick-args'. node_modules is here and problem also. Of course i'm rebuilding native modules. Without this app is not able to start at all.

I cannot reproduce this with your test scenario plus using electron-rebuild. I can successfully retrieve the USB device list on a packaged Linux Electron app. I can upload the code later today.

Repro steps:
git clone https://github.com/malept/electron-quick-start
cd electron-quick-start
git checkout electron-packager-issue-844
npm install
npm run package
# Run packaged app, varies based on target platform/arch

Well, in fact I'm using script that eliminates need for rebuild. Here it is:
Electron's version.
export npm_config_target=$ELECTRON_VERSION
export npm_config_abi=$ELECTRON_ABI
The architecture of Electron, can be ia32 or x64.
export npm_config_arch=x64
Download headers for Electron.
export npm_config_disturl=https://atom.io/download/atom-shell
Tell node-pre-gyp that we are building for Electron.
export npm_config_runtime=electron
Tell node-pre-gyp to build module from source code.
export npm_config_build_from_source=true
Install all dependencies, and store cache to ~/.electron-gyp.
HOME=~/.electron-gyp npm install

That's fine, but I still can't reproduce your problem.
In order to debug your problem further, we need a minimal testcase to reproduce your problem. Using the electron-quick-start repository as a base, could you please create a minimal Electron app that illustrates the issue you described, upload it to a GitHub repository, and post a link to it here?

This is the minimal testcase as I described.
"devDependencies": {
"electron": "^2.0.1"
},
"optionalDependencies": {
"usb": "^1.3.1"
}
--- render.js
const usb = require("usb");
let list = usb.getDeviceList();
console.log(list)
./install.sh
electron-packager .
electron-packager 12.0.2
Node.js 8.9.3, Chromium 61.0.3163.100, and Electron 2.0.1
'process-nextick-args' module is not found

I don't get that error, on the other hand the non-electron-rebuild script you have doesn't seem to work for me either.

process-nextick-args is dependency of readable-stream.
Please extend render.js with:
--- code --- render.js
const usb = require("usb");
let list = usb.getDeviceList();
console.log(list)
let device = list[0];
device.open();
console.log(device.deviceDescriptor.iSerialNumber)
device.getStringDescriptor(device.deviceDescriptor.iSerialNumber, (error, serial) => {
try {
device.close();
}
catch(error) {
console.warn(error);
}
console.log(serial);

});
--- code --- render.js
Is serial accessible?
With<EMAIL_ADDRESS>packaged content with asar works fine.

In the future, it would help if you used the "syntax highlighting" GitHub Markdown syntax, it's easier to copy/paste your code that way.

Hi @malept ,
I have made installation on windows and linux either.
In both platforms starting of packaged app fails with the same error.
Some suggestions how to proceed?

If you insist on not using electron-rebuild (as I did in my example), I would suggest asking in one of the community forums, as there are more people watching those websites who could possibly help you.

I don't have troubles with electron-rebuild but I really can't make it works. So let's try again:
12.1.0 is latest version of electron-packager with supposed fix I believe. If I'm wrong please correct me. With this steps it should be works:

npm install
electron-rebuild usb
electron-packager .

With this steps I still have the same problems. Where I'm wrong?

Have you tried the repro steps in https://github.com/electron-userland/electron-packager/issues/844#issuecomment-390096316 ?

Yes, with your demo works, but it looks like workaround, not like a solution.
install -> rebuild -> package = this should works
With your demo sequence is:
install -> rebuild -> package (rebuild one more time)
Packaging process looses some dependencies and rebuilt recovers them. It looks creepy.
Real resolution cannot impact such dependency.

It's a solution, not a workaround. The packaging code in the repro steps is essentially how Electron Forge works.

I still don't understand how you neglate the fact that everything works fine before version 12.0.0 of electron-packager. Anyhow Electron Forge now works in different way - fine.
"electron-packager ." executed under command line is not working. Not working for reasons that I still don't understand, but this is command line app and packager.js script proves that could work. 'afterCopy' step is nice but if this rebuilt is really needed could be command line argument or always to happens when electron-packager needs that.

What likely happened is that something in npm prune did something related to your native module. As of version 12, Electron Packager no longer shells out to an external tool to prune devDependencies (nor will that change any time soon, for several reasons).
You are free to continue to use Electron Packager 11.x, if 12 is not working for you. Alternatively, if you can figure out a way to change Electron Packager so that it works with your workflow (without adding a new command line option or reintroducing npm prune), I'd be happy to review a pull request.


Xcode CustomSwift-Debug

Polished fix for build configuration CustomSwift-Debug (used for xcodebuild exclusively).
Was broken since e25c6ec, Tue Jan 9 17:14:44 2018.
See previous:
https://github.com/apple/swift-lldb/pull/842 Unpolished PR
https://github.com/apple/swift-lldb/pull/843 Revert Unpolished PR

@swift-ci test


Fix test for CVE-2019-0225

Fixes #36, the same way https://github.com/apache/jspwiki/commit/3ad9e5e5d9748750d49cc17ade48637dc0effbc6 fixed the broken test originally introduced in https://github.com/apache/jspwiki/commit/88d89d6523802c044cfcb7930cba40d8eeb21da2.

https://github.com/jensdietrich/xshady/pull/37/commits/a24b7a8156535a77bd43ca4d38a4274af9a51318 changes the metadata from the GAV mentioned in the GHSA to agree with pom.xml (which works, and is the same GAV as vul4j used), and that's enough to get shadedetector working. The other direction (changing the pom.xml GAV to agree with the GHSA) would be more ideal, but I couldn't get it to work -- the jspwiki-war artifact is packaged only as a .war file, and getting .war files to work as dependencies in Maven looks complicated.


Chat Window Stops Displaying Messages when NGrok Tunnel Expires

If I don't use the Bot Framework Emulator for a few hours, but it stays open, ngrok tunnel expires when I come back and I see a notification about this.
The chat window is still able to send messages to my localhost bot and even to receive replies, but the replies are not displayed in the chat window. I can see them only in the LOG window, and no errors.
I have to either restart the conversation with same user identity, or restart the app. Reconnecting to the
ngrok tunnel doesn't help.
I'm using v4.2.1

ngrok is bypassed with localhost connections.
@artemious7 - Do you have multiple chat windows open with at least one connecting to a remote bot? Does the "reconnect" button in the notifications panel not work?

You are right, I forgot it's bypassed, but anyway it is somehow related. Or maybe there is some other time out...
I remember having only one chat window.
Reconnect button works. But I didn't have to do that on v3.


PEP 541: transfer ownership of abandoned 'pynini' package

I would like to request to transfer owernship of the name 'pynini' to myself. This project is abandoned since there have been only one alpha release over two years ago and I have repeatedly been unable to contact the apparent maintainer (https://github.com/daffidilly/pynini/issues/1) by filing an issue on GitHub. (Interestingly, this package appeared just weeks after my project of the same name was announced and released.) There is no further contact information for the author.
I wish to use this namespace for my project Pynini (pynini.opengrm.org) which predates the creation of the abandoned package.  An argument might be made that this package is more notable than the abandoned one, since it has a relatively large academic user base, extensive training materials (https://www.oreilly.com/ideas/how-to-get-superior-text-processing-in-python-with-pynini), etc.
I understand that the PEP 541 procedures are just being put together so please direct this request appropriately.
Thanks,
Kyle Gorman
City University of New York / Google

Gentle bump of this issue

Hello @kylebgorman, apologies for the delay in processing this request.
I have emailed @daffidilly requesting to clarify his position in regards to this project. Hopefully we will hear back soon and move forwards with this request.

Gentle ping, any news here?

Hi @kylebgorman, unfortunately I have no news as of yet, the reachability section of PEP 541 states that we need to try at least three times for a maximum period of six weeks since the first contact.
I've written a follow up email and I'm waiting to hear back. Once the six weeks period is over we can move forwards with your request.

@kylebgorman I've attempted contact with the current owner but have not received response thus this project is considered abandoned and we can proceed with the transfer to you.
Could you please confirm your PyPI username?

Yes, it's also kylebgorman: https://pypi.org/user/kylebgorman/
On Sun, Sep 29, 2019 at 11:30 AM Yeray Diaz Diaz<EMAIL_ADDRESS>wrote:

@kylebgorman https://github.com/kylebgorman I've attempted contact with
the current owner but have not received response thus this project is
considered abandoned and we can proceed with the transfer to you.
Could you please confirm your PyPI username?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pypa/warehouse/issues/4756?email_source=notifications&email_token=AABG4OOEXLP53BSUD46I4FLQMDCZDA5CNFSM4FW4GQ52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD73XZOA#issuecomment-536313016,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABG4OL3GKTVZWNTUJFVTTTQMDCZDANCNFSM4FW4GQ5Q
.

Thanks, I will ask an admin to transfer the project to you.

transfer complete.


WHERE fields must be decoded during aggregates

This change ensures that if there are any fields in the WHERE clause of an aggregate that are different from the fields in the SELECT clause, that the cursors also decode those fields. Otherwise WHERE clauses of the form SELECT f(w) FROM x WHERE y=z will return incorrect results

Real fix for #4701

@benbjohnson @corylanou @pauldix

Will cherry-pick this to 0.9.5 when merged to master.

Unrelated build breaks, kicked it.

Fix makes sense.  +1

:+1:


Upgrade xunit dependencies

Fix issue running tests similar to https://github.com/Microsoft/vstest/issues/1220.

Thanks!


Renable golang tests

When we introduced parallelization they were disabled due to a typo.

You're actually fixing this at #6530 😄. I'm surprised they all still pass since they have not run for months. I guess the go ecosystem has not changed a lot recently. Always, I'll close in favor of #6530!

Oh, just saw you canceled the "Merge & Squash" at #6530. We can still introduce this PR first I guess, since it's a separate fix after all. Up to you!


Update enigma2 to 2.0.5

Please update my adapter ioBroker.enigma2 to version 2.0.5.
This pull request was created by https://www.iobroker.dev c0726ff.

2.0.5 created 18.09.2023
335 user
OK


System.InvalidOperationException: The license has expired.

AppDynamics DEXTER Version <IP_ADDRESS>
Ran \core-win\AppDynamics.Dexter.exe --job-file BlackFriday.json
The report completed with the following:
System.InvalidOperationException: The license has expired.
at ?.(Object )
at ?.(Object )
at ?.  (? ,   )
at ?.()
at ?.(Boolean )
at ?.(Object )
at ?.(Object )
at ?.()
at ?.?(? ,   )
at ?.()
at ?.(Boolean )
at ?.(Object )
at ?.(Object )
at ?.()
at ?.(Object , UInt32 )
at ?.(Boolean )
at ?.(Boolean )
at ?.(Object[] , Type[] , Type[] , Object[])
at ?.(Int32 , Type[] , Type[] , Boolean)
at ?.  (? ,   )
at ?.()
at ?.(Boolean )
at ?.(Object )
at ?.(Object )
at ?.()
at ?.(Object , UInt32 )
at ?.(Boolean )
at ?.(Object[] , Type[] , Type[] , Object[])
at ?.(Stream , String , Object[] , Type[], Type[] , Object[] )
at Aspose.Words.License.SetLicense(String licenseName)
at AppDynamics.Dexter.ProcessingSteps.ReportAPMApplicationSummary.Execute(ProgramOptions programOptions, JobConfiguration jobConfiguration) in C:\appdynamics\AppDynamics.DEXTER\src\ProcessingSteps\Report\ReportAPMApplicationSummary.cs:line 55
at AppDynamics.Dexter.JobStepRouter.ExecuteJobThroughSteps(ProgramOptions programOptions) in C:\appdynamics\AppDynamics.DEXTER\src\ProcessingSteps\JobStepRouter.cs:line 189
at AppDynamics.Dexter.Program.RunProgramETL(ProgramOptions programOptions) in C:\appdynamics\AppDynamics.DEXTER\src\Program.cs:line 1037
at AppDynamics.Dexter.Program.RunProgram(ProgramOptions programOptions) in C:\appdynamics\AppDynamics.DEXTER\src\Program.cs:line 74
at AppDynamics.Dexter.Program.<>c.b__2_0(ProgramOptions programOptions) in C:\appdynamics\AppDynamics.DEXTER\src\Program.cs:line 44
at CommandLine.ParserResultExtensions.WithParsed[T](ParserResult1 result, Action1 action)
at AppDynamics.Dexter.Program.Main(String[] args) in C:\appdynamics\AppDynamics.DEXTER\src\Program.cs:line 42
Application execution took 00:00:11.9985934 (11998 ms)
It looks like the Apose.Word license expired on 20191124
https://github.com/Appdynamics/AppDynamics.DEXTER/blob/7f500bcc9f0895abaca38a81db54c1fc3964432b/Aspose.Words.lic#L16
The json I ran is a modified DefaultJob.json, is there something I can modify i the output to get around the expired word license?

Yes. Turn off the report by setting Output\ApplicationSummary=false in the jobparameters.json as described in https://github.com/Appdynamics/AppDynamics.DEXTER/wiki/Restart-Job-From-Specific-Step and restart the process from the place you want. But this is a second to last step so you are not missing much. You can restart from step 150


Login admin interface

🍰 Pullrequest

Implements the login/authenticate mechanism for the new admin interface. Furthermore the wayback is implemented and a convenience mode to disabled auth for development
Issues

includes #1116
includes #1045

Todo

[x] Convenience mode
[x] isAdmin from backend
[x] logout
[x] back2wallet
[ ] verify login (requires #1095 )
[ ] frontend tests

I fixed the test and also checked that logout is dispatched. But I get the following, when clicking on admin interface
message | "Controller class Admin could not be found."
-- | --
url | "/admin/authenticate?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJwdWJLZXkiOiJlMDlhNzk2NTQ1NTM3NTI2YTZkMTFhZjc0OTg1NDFmZjg2MGJkZTg0MzExZTNkYTU4ZjI5Y2NiZWY4MjUzNzQ5IiwiaWF0IjoxNjM3NjY2NjkyLCJleHAiOjE2Mzc2NjcyOTJ9.mfvCZIcd_ub5BSxprLdC3iPUMXO_pWiKfIYlAipfdic"
code | 404
file | "/var/www/cakephp/vendor/cakephp/cakephp/src/Http/ControllerFactory.php"
line | 105

Looks like nginx is not working as expected. On my setup I can access localhost/admin


CASSANDRA-15347 - Add client testing capabilities to in-jvm tests

WRT auto_bootstrap and the parallelForeach on startup, I've added code to partition the instances by their auto_bootstrap setting, starting up the ones set to true first (using forEach), and then doing all of the non-bootstrap instances together in a parallelForEach call. There are current no tests that actually use the non-parallel path, but I've tested it both ways by changing the default in InstanceConfig and it does what it's supposed to do.

Committed with https://github.com/apache/cassandra/commit/d90dc87bd3f8a149d98ccf40b40bf152405fbbec


cant build debug

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':pdfrx:buildCMakeDebug[arm64-v8a]'.
> com.android.ide.common.process.ProcessException: ninja: Entering directory `/home/gohar/.pub-cache/hosted/pub.dev/pdfrx-1.0.88/android/.cxx/Debug/502s4i6n/arm64-v8a'
  [1/2] Building CXX object shared/CMakeFiles/pdfrx.dir/pdfium_interop.cpp.o
  FAILED: shared/CMakeFiles/pdfrx.dir/pdfium_interop.cpp.o
  /home/gohar/Android/Sdk/ndk/25.1.8937393/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ --target=aarch64-none-linux-android21 --sysroot=/home/gohar/Android/Sdk/ndk/25.1.8937393/toolchains/llvm/prebuilt/linux-x86_64/sysroot -DDART_SHARED_LIB -Dpdfrx_EXPORTS -I/home/gohar/.pub-cache/hosted/pub.dev/pdfrx-1.0.88/android/.lib/latest/include -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security   -fno-limit-debug-info  -fPIC -MD -MT shared/CMakeFiles/pdfrx.dir/pdfium_interop.cpp.o -MF shared/CMakeFiles/pdfrx.dir/pdfium_interop.cpp.o.d -o shared/CMakeFiles/pdfrx.dir/pdfium_interop.cpp.o -c /home/gohar/.pub-cache/hosted/pub.dev/pdfrx-1.0.88/src/pdfium_interop.cpp
  In file included from /home/gohar/.pub-cache/hosted/pub.dev/pdfrx-1.0.88/src/pdfium_interop.cpp:2:
  In file included from /snap/flutter/current/usr/include/c++/9/thread:39:
  /snap/flutter/current/usr/include/c++/9/memory:121:25: error: cast from pointer to smaller type 'uintptr_t' (aka 'unsigned int') loses information
    const auto __intptr = reinterpret_cast<uintptr_t>(__ptr);
                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1 error generated.
  ninja: build stopped: subcommand failed.

  C++ build system [build] failed while executing:
      /home/gohar/Android/Sdk/cmake/3.22.1/bin/ninja \
        -C \
        /home/gohar/.pub-cache/hosted/pub.dev/pdfrx-1.0.88/android/.cxx/Debug/502s4i6n/arm64-v8a \
        pdfrx
    from /home/gohar/.pub-cache/hosted/pub.dev/pdfrx-1.0.88/android

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.

BUILD FAILED in 16s
Error: Gradle task assembleDebug failed with exit code 1

Duplicate of #243