superlogin with couchdb

Hi, I am new to the superlogin. Please forgive me if what I did is not make any sense to you.
I am wondering what is the proper way to allow a new user to register itself in couchdb/_users.

Provide the admin:password in the env.sh file. This works, but I have seen a few issues.

when I used REST API to do a post operation with http://localhost:3000/auth/login
with a registered user
{
"username": "joesmith",
"password": "bigsecret",
}
_users will start to have multiple record with the same user names. This is expected because superlogin is using the admin:password to access couchDB and is able to create multiple records.

The above leads me to believe that I don't need to give admin:password in the env.sh file, but as soon as I remove the admin:password in env.sh, I got the following response when trying to register a new user.
{
"error": "Validation failed",
"validationErrors": {},
"status": 400
}

Superlogin needs access to the CouchDB _users database, and that database should not be accessible to every user. As such the Superlogin API needs admin access to couchdb to do it's thing.
If you are concerned about keeping the admin password in the settings file, then one approach I've used is to create a user in couchdb specifically for superlogin. That way it doesn't have to be a full couchdb user and can have a massive random long password, something nobody could guess or remember.
I've also stored the password in an external file and included that file in the settings file. That way my password is never committed to any git repo. While storing passwords in these files can be a security risk, the settings file should never be publicly accessible so it's probably fine.
I hope this help address your concern.

Thank you. Good suggestion.
I realized that the _users is for session. It appears that Superlogin has used a different couchdb database for user info and password. It took me a while to realize that.
VictorL
Sent from my iPhone

On Sep 13, 2017, at 1:30 PM, Martin Fraser<EMAIL_ADDRESS>wrote:
Superlogin needs access to the CouchDB _users database, and that database should not be accessible to every user. As such the Superlogin API needs admin access to couchdb to do it's thing.
If you are concerned about keeping the admin password in the settings file, then one approach I've used is to create a user in couchdb specifically for superlogin. That way it doesn't have to be a full couchdb user and can have a massive random long password, something nobody could guess or remember.
I've also stored the password in an external file and included that file in the settings file. That way my password is never committed to any git repo. While storing passwords in these files can be a security risk, the settings file should never be publicly accessible so it's probably fine.
I hope this help address your concern.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

It could be created new document via anonymous only on _users db.

@planflux - In a related concern, it seems that the sessions in _users are not cleaned up (deleted) when the session is removed.  It also appears that if the user does not logout and the session expires, the CouchDB access is still allowed.  The CouchDB access through the _users session is only revoked if the user session in sl-users is removed through a logout or other means ( superlogin.removeExpiredKeys() ).
It seems like a problem if the CouchDB _user session "expires:" property is really not checked when a session token and password are used to access the user CouchDB database(s).  In my testing as long as the sl-users session still exists in the session object, you can still access the CouchDB with the session token and password EVEN if the "expires" property has um... expired.
So currently the CouchDB _user session will always authenticate as long as the sl-user corresponding session key exists session property exists, and it does not otherwise check to see if it is expired.  It seems like if the session is expired then the CouchDB _user session should not authenticate the access.
It seems like the "expires" property should also be checked to authenticate a CouchDB database request.
Anybody have any comments on this?

To further my comments above, I did see why the failed session logout still allows the dbURL to authenticate. It is because the user db permissions still contains the referenced _users user, it is only when that user db permissions member user is deleted that the session becomes invalid.  So while the _users session user is not deleted, in a normal superlogin logout or removeExpiredKeys, the permissions member user on the per user db IS deleted and that is what is controlling access to the user db through the session.
To further complicate things, if all users are removed from the user db then it becomes public.  I tried @Onnogeorg suggestion in this issue #174, if you add disable anonymous access by setting  require_valid_user = true  in the  local.ini  configuration file, then even with no users in the userdb it should not allow access, but that DOES NOT work.  So I tried @saip92 suggestion on #174 where he suggests

I think the easiest fix would be to add a role 'user:<user_id>' to each of the private databases on register.

and that does solve the problem, so I would propose adding the role to the userdb permissions when a session user is added, and of course never deleting it.  I tested this solution and it does work for the userdb becoming public issue where the require_valid_user = true did not work.
So the question remains now should or should not the user session that gets added to _users be deleted with the user is removed from the userdb?  I think it should but maybe there is a reason to leave it there?
Also, what is the best way to honor the expired 00

I have started to ponder @saip92 's idea in #174 of adding the 'user:<user_id>' to each of the private databases on register.  Now I wonder if that was implemented, then there really would be no need to add each "session" _user to the private database and there would also be no need to manage the _security document of the private database after the user registers.  The only requirement at that point would be to make sure you cleanup each "session" user in _users (which currently doesn't happen at all).
This would seem to be a more efficient implementation and just as secure because as I understand only an admin could add a role, thus making 'user:<user_id>' secure from tampering from the outside?  The biggest change is to move the management of user "session" from within the each private database's _security document out to the CouchDB _user document and IMO that should already be managed as part of the logout and removeExpiredKeys apis.  Then simply 'user:<user_id>' to each of the private databases on register, and seems like you would have a much tighter implementation overall?

UPDATE: I figured out why the _users session user docs were not being deleted on the session logout, see issue #186.  The problem is the CouchDB 2.0 (and possibly earlier versions) has a bug that causes allDocs called with an array of keys to fail on each key when running against the _users db.
This still leaves the security issue wide open and it is not solved with CouchDB 2.1, nor do I think it will ever be solved by CouchDB.  It is very clear that if no members are defined the database is public, so as @saip92 suggested in #174, you could add the existing member role of 'user:<user_id>' during the initial creation of the private db.  That will work, but if for any reason a _users session is not deleted, that session will still have access to the private db because the member role would match with 'user:<user_id>'.  I am now considering maybe adding a dummy user as maybe a better approach, the loophole being how to avoid a clash with an actual user name.  Now if you use superlogin exclusively then that is not a big problem because its _users session user names are hashed so in that case what I have tested is adding a Members -> Users -> Username to each private db such as:
DO-NOT-DELETE-FORCE-SECURE
As long as the user "DO-NOT-DELETE-FORCE-SECURE" never exists in the _users db then the private dbs will never become public due to having no members (Users and/or Roles) defined.  Basically this is the same idea as @saip92 mentioned in #174, but I think it may be more secure because by adding a role of 'user:<user_id>' you have more possibility that a _users session doc may exist versus a single _users session doc with the _id "org.couchdb.user:DO-NOT-DELETE-FORCE-SECURE" . In fact super login could be modified to insert the user "org.couchdb.user:DO-NOT-DELETE-FORCE-SECURE" into _users via the config, and I think it is no less secure than having an admin user and password.  It might also be possible to change the salt value so that the "org.couchdb.user:DO-NOT-DELETE-FORCE-SECURE" could never be authenticated since it is only there to ensure that no private dbs will ever become public.
What do you all (maybe not many of you) think about this idea?  The superlogin community seems to be either very happy with how things are working or quite a small group?  I suppose there are more cloudant users vs CouchDB, so maybe that has a better implementation compared to CouchDB?  All comments are welcome and I guess I sort of hijacked this issue, but only because it had to do with superlogin and CouchDB.  May need to have @planflux close this issue so I can make a new one?

@clariontools I think the idea that you have presented here is pretty neat. It solves the issue of private DBs from becoming public and also stops previous session credentials from being used. (this essentially breaks the logout all feature allowing someone with stolen session credentials to access private DBs)
Along with these improvements, I believe making sure _users session documents are removed as well is necessary for maximum security. While private data is secured, those orphan session credentials can still be used to mess with public data and/or be used to impersonate another user. (Despite having require_valid_user = true since those orphan credentials are still valid for CouchDB authentication)
If with CouchDB 2.1 that has been solved, then I guess there is nothing to worry but it wouldn't be a bad idea to catch such an error in the future and have another method to secure things (say something like a CRON job that flushes out orphan session credentials)

@saip92 - I am 100% sure CouchDB 2.1 fixes the bug with keys=[] on allDocs and I have already done a lot of testing on that so it is a must for superlogin users.  Unfortunately, there are bugs in the new Fauxton that comes with CouchDB 2.1, specifically you lose the visual of the _security doc even though it is still there, but it makes it more difficult to test.
I think a CRON job or interval on the server.js that calls superlogin.removeExpiredKeys() would be a good addition, but that does not require any changes to superlogin because it already works.
Another thing you could do (with CouchDB 2.1 fix) is call logoutAll and it will remove all existing sessions for the user.  Also, you could use logoutOthers maybe right after a successful login to make sure any orphan sessions are removed.
BTW, see my #187 issue and test it out if you have a chance to confirm. Thanks.

@clariontools That sounds great. As for the _security doc, I checked in the docker version of v2.1.0 and I can still see the Permissions view with a special UI (like in v2.0.0 or maybe I misunderstood you? 😛)
It would be best to catch such security risks before hand. A CRON job might be overkill I guess and unnecessary but probably a simple .catch() block at user.js#L1166 would do the trick.
But IMHO for issues like this, a Unit Test which could be used to certify Superlogin against a specific version of CouchDB is the way to go.
Also, you mentioned

use logoutOthers maybe right after a successful login to make sure any orphan sessions are removed

Though this gets the job done, it might not be the way to go for most use cases as applications might want to keep active sessions across multiple devices/browsers.

After reviewing the config example it looks like there is a way to setup default Admins and Members _security doc for user dbs.  Now that I think about it maybe just adding the default admin user as a user on the private db's through the config would be just as good (or maybe better) than adding a special user named "DO-NOT-DELETE-FORCE-SECURE".  I don't see any drawback to this because if you admin user is not secure then you have bigger troubles.
So the resolution would be to use the config feature to set the default _security doc for CouchDB per user dbs and add the admin user name to the config.  Will have to test this idea to make sure it works but it sounds reasonable.

@saip92 -

As for the _security doc, I checked in the docker version of v2.1.0 and I can still see the Permissions view with a special UI (like in v2.0.0 or maybe I misunderstood you?

I am saying using the Fauxton that comes with the apache/couchdb docker version 2.1.0.  That is if you use the Fauxton that comes with the docker container, it has a bug that has been fixed not too long ago.  The problem is when you go into the Fauxton permissions view none of the existing permissions from the _security doc show up in the web view.  You can still use curl or postman to view the _security doc but not from the Fauxton UI unless you have the very latest from the git repo which is not in the docker image.

@saip92 - When you say "special UI" are you talking Fauxton, or do you have something else that you use?  If there is something better, please do tell :1st_place_medal:

@saip92

Though this gets the job done, it might not be the way to go for most use cases as applications might want to keep active sessions across multiple devices/browsers.

Totally agree with you here, it would depend on the use case.

But IMHO for issues like this, a Unit Test which could be used to certify Superlogin against a specific version of CouchDB is the way to go.

For sure, and in the case of the keys=[] on allDocs, it is going to fail on CouchDB 2.0 and could fail on all previous releases for that matter, but will succeed with CouchDB 2.1. Would be a good test and a great addition to the README.md warning of the consequences of not removing the _users sessions.  I am a bit interested to see if that was a CouchDB 2.0 specific thing or has been there for a while?  The superlogin code was doing the right thing so makes you think it did work at some point during the development.

It would be best to catch such security risks before hand. A CRON job might be overkill I guess and unnecessary but probably a simple .catch() block at user.js#L1166 would do the trick.

The catch would be an improvement and would catch some fringe cases or where the CouchDB is down or unreachable, but it would not catch the situation where a user just closes the browser or closes a mobile app, in that case the logout would most certainly never occur at all and the session would remain active until expired.

The problem is when you go into the Fauxton permissions view none of the existing permissions from the _security doc show up in the web view.

I can see the users/roles as in the _security document. Maybe just a browser refresh would do?

When you say "special UI" are you talking Fauxton, or do you have something else that you use? If there is something better, please do tell

Not really 😄. I meant the simple UI in fauxton for adding/removing Admins/Members Users/Roles instead of directly dealing with the document.

but it would not catch the situation where a user just closes the browser or closes a mobile app, in that case the logout would most certainly never occur at all and the session would remain active until expired.

The catch block would be to notify/workaround issues with clearing the keys. If such a block would have existed, we would have had some workaround which would've cleared the sessions or at least a console message reporting the problem when using CouchDB 2.0.
Even with the fix in CouchDB 2.1.0, it would still be good to know of any such failures due to another bug in the future that would leave orphan sessions left out.

@saip92

I can see the users/roles as in the _security document. Maybe just a browser refresh would do?

It is a known bug that has been fixed in Fauxton and will be part of the CouchDB 2.1.1 release.  Based on the issues over at the apache/couchdb repo, it may also have something to do with recent Chrome updates as one commenter mentioned it worked in Firefox.  I tried in Chrome and Safari on macOS and it doesn't work for me as reported by others referenced in the apache/couchdb repo issue.
Also, just to compare the version of Fauxton I am using vs. what you have could you do a view source from your browser when Fauxton is up and check the version, you can find it towards the bottom of the page source, I am showing Fauxton Release : 2017-08-04T17:05:44.904Z.

The catch block would be to notify/workaround issues with clearing the keys.

I am not sure about a .catch block here because seems like much of the superlogin code resolves promises to resolve(false) when failed instead of using reject(error).  Maybe with the design of superlogin it would be better to add the values to the all(promises).then something like  .then(function(values) { at that point I think you would have to iterate through the values array which is the results from all the promises pushed above, and if the second one "removeKeys" returns false then it indicates that the toDelete array contained no valid Keys in the CouchDB _users doc.  Not sure what is returned with call to couchAuthDB.bulkDocs(toDelete)?  Also, you could have a false returned if all the CouchDB _users sessions are already marked as _deleted = true, so just detecting false is not good enough.  Bottom line is at the moment, the removeKeys for CouchDB can fail with the CouchDB bug, but it is a soft failure, there is no way to determine with CouchDB 2.0 (maybe earlier versions too) whether or not the _user session key exists because using keys=[] with allDocs doesn't error, it just indicates that that keys were not found.  In the case of Couch 2.0 the code would have to be changed to do a single key="session-key-value" with allDocs, and that would require code changes that would make the function clunky with multiple GET calls for each session.  Of course it is not a problem with a single session logout and I already tested that with CouchDB 2.0 and it works fine.  Maybe a better approach would be to query the CouchDB version at startup and console log known issues to the console and be done with it?  Do you know if this issue existed in CouchDB versions prior to 2.0 as well?

Tried to test the defaultSecurityRoles to set the security document default in the config as per the example the config example and as Murphy's Law is always in force, but true to the nature of the property's name (defaultSecurityRoles), this only allows you to add a "Role" to the Admins or Members property, in otherwords, you CANNOT add the "names" property.
Ok, so strategy change, I tested by adding to the config:
    defaultDBs: {
      private: ['supertest']
    },
    defaultSecurityRoles: {
      members: ["admin"]
    }
  },

Get a TypeError: memberRoles.forEach is not a function, so that needs to be fixed at line 81 in couchdb.js and also the same thing for adminRoles on line 75 so change is from:
        memberRoles.forEach(function(role) {
to:
        Array.from(memberRoles).forEach(function(role) {
Yeah, great that fixes that problem, and testing shows that the results seem to protect the user private dbs from ever becoming public.  So with this fix I still need to look at a fix for logout on expired sessions, because it does not delete the session if it is expired.  I recall some talk about a fix for that problem here and I was under the impression it was fixed.  I do see two emits when the session is expired, so maybe it deletes the local expired session then does a second logout with no active session, just a guess in hopes that someone remembers this issue before I start debugging it.

@saip92 - In regards to the idea of calling logoutAll on logout and logoutOthers after a successful login, you rightly pointed out a use case where this would not be desirable.

Though this gets the job done, it might not be the way to go for most use cases as applications might want to keep active sessions across multiple devices/browsers.

I noticed that the ip is saved with the session, I don't see it is used on the logoutAll or logoutOthers, but it seems like that by including the ip, you could allow for that use case by passing an option that would only logout sessions if the ip in the session matched the ip of the logoutAll or logoutOthers call?  If this were implemented you could have different options for different use cases:

Only call logout and it will only delete the active session (as is no changes required).
Call logoutAll or logoutOthers with a flag "filterIP = true" and it will use the current session ip and logout All or Others that have a matching ip in the stored session(s) (requires changes to superlogin).
Call logoutAll or logoutOthers as works now (as is no changes required).

In addition to this adding an interval to server.js that calls removeExpiredKeys() will ensure that there are minimal chances for the _users sessions to become flooded with orphaned session users.  Of course care would be needed to chose the most appropriate session expiration length.
Another feature that doesn't exist is to run a period cleanup on the CouchDB _users looking at the "expires" property where the date/time has expired but the key does not exist in the superlogin local store.  That case should be rare unless you are using CouchDB 2.0 (and maybe earlier) since these _users sessions are never removed due to the CouchDB bug I mentioned (fixed in CouchDB 2.1.0).

For anyone actually reading this, here is a quick update on this issue:

So with this fix I still need to look at a fix for logout on expired sessions, because it (logout) does not delete the session if it is expired.

I started debugging this and suddenly realized that after upgrading from CouchDB 2.0 to CouchDB 2.1, the problem has disappeared.  I haven't tracked down where if failed, but it is likely a similar problem with keys=[] hitting _users/_all_docs .  Most likely there was a failure causing a promise reject.  I do recall that the console would show two logout events (with CouchDB 2.0) first was expired, second was logout, that was on the client EMIT side using superlogin-client.  Now it strangely just emits a refresh when I do a logout with an expired session.  I suppose the code may first refresh the token, then logout, strange, but anything is possible :smile: .
So far it appears that almost all the problems I have experienced all point back to CouchDB 2.0, most likely things work with CouchDB 1.6 and as I mentioned CouchDB 2.1 addresses the things I found that do not work properly in CouchDB 2.0.  So far I recommend anyone using superlogin to steer clear of CouchDB 2.0, it is just not a good match.

@planflux - I think this issue can be closed now (by you since no one else is paying attention here), especially in regards to your questin:

_users will start to have multiple record with the same user names. This is expected because superlogin is using the admin:password to access couchDB and is able to create multiple records.

This is not expected and I have covered all the reasons why this happens (ad nauseam) above :smile_cat: .


Removed preview from title to reflect current status

@JSeb225 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Moving this to the internal repo


Cannot start GUI apps (e.g. xeyes) after official setup instructions

Windows build number:
22000.0
Your Distribution version:
20.04
Your WSL versions:
  NAME            STATE           VERSION
* Ubuntu-20.04    Running         2

Steps to reproduce:

Update current WSL version as per official instructions.
Update Nvidia drivers (NVIDIA GeForce RTX 3080 Laptop GPU, veresion 522.25)
Install gedit (sudo apt install gedit)
Run gedit (gedit) and see nothing happening
Run xeyes (xeyes) and see nothing happening

However i could narrow down the bug.
I noticed this is more likely due to the fact the value of the DISPLAY variable is not :0 but W.X.Y.Z:0 where W.X.Y.Z is the IP as specified by nameserver in /etc/resolv.conf
I could have both gedit and xeyes  work by setting the DISPLAY variable in the spawn shell:
DISPLAY=:0 gedit

DISPLAY=:0 xeyes

IMPORTANT: on the same laptop, a fresh install of Ubuntu 22.04 from the Microsoft Store (not Ubuntu 20.04 which is the version to which the current issue applies to), both gedit and xeyes are working fine. In that case, the value of DISPLAY is already :0 at OS startup.
The main question to solve this issue is then likely to be: how to set the DISPLAY variable back to :0 at startup, instead of W.X.Y.Z (where W.X.Y.Z is the value of nameserver in /etc/resolv.conf)
WSL logs:
Before running gedit and xeyes with DISPLAY manually set to :0
pulseaudio.log
stderr.log
weston.log
WslLogs-2022-10-18_13-15-04.zip
After running gedit and xeyes with DISPLAY manually set to :0
pulseaudio.log
stderr.log
weston.log
WSL dumps:
No response
Expected behavior:
To work as in the Ubuntu 22.04 WSL release tested on the same laptop
Actual behavior:
Terminal hangs when running gedit or xeyes.

Check this: https://github.com/microsoft/wslg/wiki/Diagnosing-"cannot-open-display"-type-issues-with-WSLg#display-environment-variable

"The main question to solve this issue is then likely to be: how to set the DISPLAY variable back to :0 at startup, instead of W.X.Y.Z (where W.X.Y.Z is the value of nameserver in /etc/resolv.conf)" check your ~/.bashrc or a file in /etc/profile.d that is setting the variable


Align with NOMAD docs

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
2 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.03%) to 78.434%

Files with Coverage Reduction
New Missed Lines
%

pynxtools/dataconverter/validation.py
1
68.2%

pynxtools/dataconverter/helpers.py
1
79.21%

Totals

Change from base Build<PHONE_NUMBER>:
-0.03%

Covered Lines:
2815

Relevant Lines:
3589

💛  - Coveralls

LGTM. I'm however not sure if we want to keep the vanilla NOMAD logo. It looks a bit like that this is the central documentation for NOMAD. This might confuse people and it might be good if we had a small pynxtools below or beside it or so. That way it would be clear that it belongs to nomad but is actually a different documentation.
Also it always confuses me that clicking on the logo brings me to the official nomad page. I'm used to landing on the entry page of the site I'm currently at. But it's the same for NOMAD itself so it's no real issue arising from this PR.

100% agree on both points. I guess the idea with the vanilla NOMAD logo is that it all points back to NOMAD, but pynx is in principle also standalone. Let's just keep it for now, I saw some discussion in discord about the particular UX when clicking on the button, so maybe this will be changed anyway.


ci(renovate): don't automerge minor updates

:tada: This PR is included in version 0.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Display issues with disabled selects in 1.8.x

Hello!
I'm getting some graphical issues (and perhaps more?) after upgrading to 1.8.x. See image & source below. Seems to be a width issue and it only appears when disabled.

<select
	type="select"
	class="bootstrap-select form-control"
	label="Label here"
	multiple=""
	data-actions-box="true"
	data-live-search="true"
	disabled=""
	data-selected-text-format="count>3"
	tabindex="-98">
</select>

What's your browser/OS?

I had this issue in both Chrome & Safari:
Chrome:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.80 Safari/537.36

Safari:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/601.3.9 (KHTML, like Gecko) Version/9.0.2 Safari/601.3.9

Microsoft Edge 25.10586.0.0 on Windows 10 -  has same problem.
Firefox v42.0, v43.0 on Windows 10 -  has same problem.


Deedle: 1.2.0 -> 1.2.5

Deedle was outdated and the build was failing.
This probably needs backporting to 18.09 (#45960)

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg  build dotnetPackages.Deedle

Success on x86_64-linux (full log)
Attempted: dotnetPackages.Deedle
Partial log (click to expand)
'package/services/metadata/core-properties' -> '/nix/store/qpbjfj3gvf82yq6hsjcxfhmkrpmbz4zs-Deedle-1.2.5/lib/dotnet/Deedle/package/services/metadata/core-properties'
'package/services/metadata/core-properties/07a4c2792ac349408c5fcc8906c6bac5.psmdcp' -> '/nix/store/qpbjfj3gvf82yq6hsjcxfhmkrpmbz4zs-Deedle-1.2.5/lib/dotnet/Deedle/package/services/metadata/core-properties/07a4c2792ac349408c5fcc8906c6bac5.psmdcp'
/nix/store/qpbjfj3gvf82yq6hsjcxfhmkrpmbz4zs-Deedle-1.2.5 /build
/build
glibPreFixupPhase
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/qpbjfj3gvf82yq6hsjcxfhmkrpmbz4zs-Deedle-1.2.5
patching script interpreter paths in /nix/store/qpbjfj3gvf82yq6hsjcxfhmkrpmbz4zs-Deedle-1.2.5
checking for references to /build in /nix/store/qpbjfj3gvf82yq6hsjcxfhmkrpmbz4zs-Deedle-1.2.5...
/nix/store/qpbjfj3gvf82yq6hsjcxfhmkrpmbz4zs-Deedle-1.2.5

Success on x86_64-darwin (full log)
Attempted: dotnetPackages.Deedle
Partial log (click to expand)
'package/services' -> '/nix/store/zdzbn2gzf21djk72zcz0c17kp2lbbnxq-Deedle-1.2.5/lib/dotnet/Deedle/package/services'
'package/services/metadata' -> '/nix/store/zdzbn2gzf21djk72zcz0c17kp2lbbnxq-Deedle-1.2.5/lib/dotnet/Deedle/package/services/metadata'
'package/services/metadata/core-properties' -> '/nix/store/zdzbn2gzf21djk72zcz0c17kp2lbbnxq-Deedle-1.2.5/lib/dotnet/Deedle/package/services/metadata/core-properties'
'package/services/metadata/core-properties/07a4c2792ac349408c5fcc8906c6bac5.psmdcp' -> '/nix/store/zdzbn2gzf21djk72zcz0c17kp2lbbnxq-Deedle-1.2.5/lib/dotnet/Deedle/package/services/metadata/core-properties/07a4c2792ac349408c5fcc8906c6bac5.psmdcp'
/nix/store/zdzbn2gzf21djk72zcz0c17kp2lbbnxq-Deedle-1.2.5 /private/tmp/nix-build-Deedle-1.2.5.drv-0
/private/tmp/nix-build-Deedle-1.2.5.drv-0
glibPreFixupPhase
post-installation fixup
patching script interpreter paths in /nix/store/zdzbn2gzf21djk72zcz0c17kp2lbbnxq-Deedle-1.2.5
/nix/store/zdzbn2gzf21djk72zcz0c17kp2lbbnxq-Deedle-1.2.5

No attempt on aarch64-linux (full log)
The following builds were skipped because they don't evaluate on aarch64-linux: dotnetPackages.Deedle
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowBroken = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowBroken = true; }
to ~/.config/nixpkgs/config.nix.

This seems to download a prebuilt binary (same with Paket earlier). It would be preferable to build from source.

But it's better than a failing build, so let's merge anyway :smile:

@xeji, indeed. For Deedle specifically, it didn't have the 1.2.5 tag on Github :/ 1.2.4 was released 3 years ago :( I guess it is maintained poorly.


[ICS02] Implement IBC client recovery mechanisms

Problem Statement
If a client gets frozen or expired it can no longer be updated, the associated connection(s) and channel(s) will also stop working and funds in the channels will be permanently locked and not transferrable.
ibc-rs needs a mechanism by which frozen IBC clients can be recovered. This functionality has been implemented in ibc-go as part of ADR 026. We'll need to implement similar functionality in ibc-rs in order to maintain feature parity.
### Tasks
- [ ] https://github.com/cosmos/ibc-rs/issues/1112
- [ ] https://github.com/cosmos/ibc-rs/issues/1110
- [ ] https://github.com/cosmos/ibc-rs/issues/1111
- [ ] https://github.com/informalsystems/basecoin-rs/issues/173

All the tasks are finished. Does that make this tracking issue finished too?

I think @seanchen1991 is addressing the final aspect of this feature in https://github.com/informalsystems/basecoin-rs/issues/173 to ensure its functionality. Once that's completed, we can consider closing this issue.

@seanchen1991 we can close this now, right?


[FLINK-14004][runtime] Define SourceReaderOperator to verify the integration with StreamOneInputProcessor

What is the purpose of the change
We already refactored the task input and output in runtime stack for considering the requirements of FLIP-27. In order to further verify that the new source could work well with the unified StreamOneInputProcessor in mailbox model, we define the SourceReaderOperator as task input and implement a unit test for passing through the whole process.
Brief change log

Define AbstractDataOutput as the base class for both source output and network output.
Refactor the previous processes based on AbstractDataOutput.
Define SourceReaderOperator base class.
Define SourceReaderStreamTask to generate the source input and output for StreamOneInputProcessor.

Verifying this change

Added unit test in SourceReaderStreamTaskTest for verifying that the source reader operator could be integrated well with StreamOneInputProcessor.

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

Thanks for this kind notification @StephanEwen !
I agree with your point. The final version of SourceReader should be given by FLIP-27, not by runtime side. The motivation of this PR is just an initial retry to verify the previous runtime refactoring tasks (#9478 #9483) which could integrate well with the future SourceReader. Then we could take it easy to merge previous PRs.
This PR would be rebased again to only focus on runtime modifications after FLIP-27 is voted and SourceReader is merged by source api stack.

Sorry for missing the following comments. I agree with the general above points.
On runtime side it does not care about the specific SourceReader interface. The runtime only interacts with source operator via #emitNext and #available methods atm. As for how the source operator further interacts with the internal source reader, the runtime does not need to understand it.
We can ignore the SourceReader related details in this PR. The possible meaningful point in this PR is that I try to pass through whether the runtime proposed DataOutput argument via operator#emitNext can satisfy well for the future SourceReader. So I construct a unit test for verifying it.

I agree with @StephanEwen

I think in that case there should be a placeholder interface in flink-runtime that is used, instead of a preliminary version of SourceReader. That placeholder gets refactored/replaced by the proper source reader then.
That placeholder should also have only the necessary methods, nothing about splits, start, etc

With defining this place holder interface, I think we could work on this PR. We might need to reconsider regarding the splits if we want also to follow up with runtime support for stateful SourceReader in some next PR.

I had a chat with @StephanEwen and a proposal to unblock this is to avoid defining SourceReader interface here. We can just implement the SourceReaderOperator class, as a for example a stateful/stateless infinite/finite source of integers. We could integrate it with the runtime and it would be generating the integers and emitting them directly to the DataOutput. Later, someone implementing a final SourceReader interface would just reimplement SourceReaderOperator to use SourceReader interface.
More specifically, we could just drop the SourceReader interface from this PR, embed the logic of TestingFiniteSourceReader inside the SourceReaderOperator and that should be it.
The following would be to implement state snapshotting in this SourceReaderOperator (to test our integration with stateful readers).

Thanks for the further confirmation and pushing forward this work.
I agree with the conclusion that we could only touch SourceReaderOperator in this PR and not care about the interactive details between SourceReaderOperator and SourceReader.
In detail I think it is better to only give an abstract SourceReaderOperator to provide emitNext and isAvailable methods for runtime call, and implement this operator only in unit tests to verify the whole process ATM. Then after FLIP-27 ready, it could implement the former SourceReaderOperator with SourceReader together.
I already updated the codes based on the above confirmation.

@flinkbot run travis

Thanks for the review @pnowojski and I fixed the above nit comments.
The travis failed because of known fragile Kafka010ProducerITCase, so ignore it to merge.


Throw errors during JavaScript initialisation if key HTML elements are missing

What
Update our JavaScript components requiring specific HTML elements to be present so they throw a MissingElementError (extending GOVUKFrontendError) rather than silently fail.
The missing element may be:

a single descendant (for ex. the Character Count's field)
multiple descendants (for ex. the Accordion's sections)
an external element (for ex. the Skip Link's target)

Affected components

Accordion – The sections of the accordion
Accordion – Header in the section
Accordion – <span> header
Accordion – Heading
Accordion - Toggle icon or text
Character Count – The input/textarea
Character Count – The textarea description
Checkboxes – The <input> elements
Exit this page – The button
Header – Menu
Header – Menu button
Radios – The <input> elements
Skip link – The linked element
Tabs – The tabs (<a>)
Tabs – The tablist and their items
Tabs – The tab panel associated to a tab

Why
This is part of our work to have our components throw rather than silently return during initialisation.
Who needs to work on this
Developers
Who needs to review this
Developers
Done when

[ ] Review the list of affected components for completeness
[ ] Components have been updated to throw errors

Let's divide this issue into smaller ones, in order of complexity:

Skip Link
Exit this page
Header
Radios & Checkboxes
Character Count
Tabs
Accordion
Review any loose ends (keep this issue)

From a discussion on slack:
We may want to look at removing the element param from the ElementError and just tell the error what's missing or invalid. We're using it like a boolean, and often just pass in null.

Maybe it's a sign that we need to have the ElementError just accept a generic string message and move the formatting to separate helper functions rather than pass that boolean-ish first param: missingElementMessage and missingOrMistypedElementMessage.
I'd like to propose something like the following (the passing of the componentName being a parallel concern as it affects multiple errors, we can always add in an extra options parameter to the constructor anyway or with a componentErrorMessage function to wrap other message).
class ElementError extends Error {
  name = 'ElementError'
}

function missingElementMessage(identifier) {
  return `${identifier} is missing`
}

// Two little updates here:
// - identifier as first param to keep in line with the `missingElementMessage
//
function missingOrMistypedElementMessage(identifier, {value, expectedType = HTMLElement.name}) {
  if (!value) return missingElementMessage(identifier)

  return `${identifier} is not of the type ${expectedType}`
}

throw new ElementError(missingElementMessage('button'));
throw new ElementError(missingOrMistypedElementMessage('input', {value: $input});

Depends on how we want to word things for 4072, and is an internal refactoring so could wait if necessary.


torchvision version cannot be updated

I have installed ffcv with python 3.8, pytorch 1.8.1 and cuda 10.1.
conda create -y -n ffcv python=3.8 cupy pkg-config compilers libjpeg-turbo opencv pytorch=1.8.1 torchvision cudatoolkit=10.1 numba -c pytorch -c conda-forge
However it installs a very old version of torchvision 0.2.2. I need atleast 0.9.1. However it is not being updated and if I try to create an environment with this specified version, the environment doesn't get created.

Okay it worked for me. I did installation in steps.

created a new environment with python=3.8
conda install pytorch=1.8.1 torchvision=0.9.1 cudatoolkit=10.1 -c pytorch
conda install cupy pkg-config compilers libjpeg-turbo -c conda-forge
pip install opencv-python (installing it with conda was causing issues)
pip install ffcv
pip install -r requirements.txt


[Op][FX] Add relax.clip Op and support MobileNetV2 Importing

This PR enables importing MobileNetV2 from PyTorch FX, which including the following changes:

Add relax.clip Op, with PrimValue support
Support torch.clamp and torch.ReLU6 in PyTorch FX frontend
Support torch.nn.functional.adaptive_avg_pool2d in PyTorch frontend

cc @MasterJH5574 @spectrometerHBH

Thanks @Hzfengsy. Would you mind sending

the BlockBuilder fix and tests
the clip op
the TOPI fix
to tlc or mainline correspondingly? That would be super helpful.


supporting kind information to auto-complete for LSP like output

Parse the additional info for autocompletion, so that pop-up window can display the detail as help and Kind info like Function, struct, property, macro, method etc similar to LSP. The enhanced omnicompletion is inspired from coq.thirdparty omnicompletion.
Autocompletion after the fix.

Prior to fix:

I've done a hacky little thing in the cmp format function to improve omnifunc a bit,
before:

after:

format = function(entry, vim_item)
  if entry.source.name == 'omni' then
    if entry.completion_item.documentation == nil then
      entry.completion_item.documentation = vim_item.menu
      vim_item.menu = nil
    end
    vim_item.kind = 'Ω'
    vim_item.kind_hl_group = 'CmpItemKindProperty'
  else
    -- set vim_item.kind to an lsp related icon depending on vim_item.kind
  end

  return vim_item
end

I think this feature can be useful for treesitter omnifunc completion (try :PreviewQuery). It requires some rebase and fix applied, such as #6 (01f0f66).  @akh2008 Would you want to work on rebasing and wraping it up? I can help and provide some reviews.


docker ERROR:asyncio:Task exception was never retrieved

docker run -it -p 10200:10200 -v ./data:/data rhasspy/wyoming-piper --voice en-us-lessac-low

INFO:__main__:Downloading en-us-lessac-low to /data
INFO:__main__:Ready
ERROR:asyncio:Task exception was never retrieved
future: <Task finished name='Task-6' coro=<AsyncEventHandler.run() done, defined at /usr/local/lib/python3.9/dist-packages/wyoming/server.py:26> exception=JSONDecodeError('Expecting value: line 1 column 1 (char 0)')>
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/dist-packages/wyoming/server.py", line 28, in run
    event = await async_read_event(self.reader)
  File "/usr/local/lib/python3.9/dist-packages/wyoming/event.py", line 48, in async_read_event
    event_dict = json.loads(json_line)
  File "/usr/lib/python3.9/json/__init__.py", line 346, in loads
    return _default_decoder.decode(s)
  File "/usr/lib/python3.9/json/decoder.py", line 337, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib/python3.9/json/decoder.py", line 355, in raw_decode
    raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

Please try again with the latest Docker image and let me know if the issue persists.


Extend AnnotationExcluder to catch fully qualified annotations

Currently AnnotationExcluder is not handling usages of fully qualified annotations (eg. @dagger.Module). This is causing the failure reported in #2360.
I'm extending it to catch both simple and fully qualified annotations.
Fixes #2360

Codecov Report

Merging #2361 into master will increase coverage by 0.29%.
The diff coverage is 46.15%.

@@             Coverage Diff              @@
##             master    #2361      +/-   ##
============================================
+ Coverage     82.53%   82.82%   +0.29%
- Complexity     2141     2163      +22
============================================
  Files           349      350       +1
  Lines          6057     6061       +4
  Branches       1110     1112       +2
============================================
+ Hits           4999     5020      +21
+ Misses          479      469      -10
+ Partials        579      572       -7

Impacted Files
Coverage Δ
Complexity Δ

...gitlab/arturbosch/detekt/api/AnnotationExcluder.kt
50% <46.15%> (+27.77%)
6 <5> (+1)
:arrow_up:

...ab/arturbosch/detekt/cli/runners/ElementPrinter.kt
96.42% <0%> (ø)
11% <0%> (?)

...lin/io/gitlab/arturbosch/detekt/core/KtCompiler.kt
96.15% <0%> (+7.69%)
9% <0%> (+3%)
:arrow_up:

...tlin/io/gitlab/arturbosch/detekt/cli/ReportPath.kt
100% <0%> (+16.66%)
1% <0%> (ø)
:arrow_down:

...io/gitlab/arturbosch/detekt/core/KtTreeCompiler.kt
69.23% <0%> (+19.23%)
12% <0%> (+3%)
:arrow_up:

...gitlab/arturbosch/detekt/cli/runners/AstPrinter.kt
100% <0%> (+22.85%)
4% <0%> (+3%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1af1e34...457c620. Read the comment docs.

Don't really know why UnusedPrivateClassSpec > does not report (companion-)object/named-dot references is failing only for Java8 on Travis 🧐

It's failing because the code snippet doesn't compile. We only compile them in Travis Java8 (performance reasons). You can test it with: ./gradlew :detekt-rules:test -Pcompile-test-snippets=true

Thanks for the clarification. Still, UnusedPrivateClassSpec is unrelated to my change 🧐

I think that for really fix this issue we need type solving but this is better that we have for sure.

Yeah agree.

Oh, yes, I didn't noticed that. It's strange, master is passing. Can you rebase your branch with the current master? I think that'll solve the problem

I think that'll solve the problem

Nope is still failing :/

@cortinico I had the same problem in #2350.
I just haven’t had the time so far to look into it.
On jdk8 we additionally compile the provided code snippets in detekt’s unit tests through Jsr223 in order to validate it, because there were problems with invalid Kotlin code in the past. That’s the reason why this PR only fails on this single build agent.
I suspect this error is because of one of the following reasons:

Using 8 compile engines for compiling around +1000 test snippets is not enough anymore.
The error mentions something about coroutines. There might be problems with the previously introduced coroutine ruleset test cases.

@cortinico btw thanks for your fast fixes. You helped us out multiple times. Thanks for that! 🙂


Hello Reffy - Give Reffy a face

This adds a representation of Reffy as a brave worm wearing a construction helmet. Image courtesy of Clementine :)
Using the GIF version in the README in the interest of size (70KB vs. 218KB). Also added 1024x1024 versions for use in presentations or the like.

I switched to indexed colors mode using gimp fwiw

OK, playing around, I manage to get even better results (slightly better quality and smaller size) with pngquant. I'll update the PR and drop the GIF.


refactor certroatation controller using sdk-go

Describe the enhancement
moved the certrotation controller to sdk-go https://github.com/open-cluster-management-io/sdk-go/pull/53
so need to refactor certrotation controller using sdk-go.

done


Update plugin folder name to lighthouse-plugin-pub-ads-audits.

Is this blocking plugin integration or a issue about convention? Some more background on the PR description would be great

Is this blocking plugin integration or a issue about convention? Some more background on the PR description would be great

This is not blocking. Just a quick fix I wanted to get in to complete the name change.

Time for some bikeshedding? 🚲🏚   😃
I kinda miss "adspeed" as it communicated a lot.

"audits" I think is superfluous as this is a lighthouse plugin and "audits" is kind of implied.
"pub" or "publisher" makes sense from a google POV, but is it a common term from the publisher POV?

The naming usecases i'm thinking of are... 1) someone is googling the name of this plugin that they heard about.. 2) they are selecting its checkbox in DevTools.
What about just "Google Ads" .. lighthouse-plugin-google-ads ?
Or if you don't want Google in there, then... 'Ad publishing' ?

@paulirish pub/publisher is indeed a common industry term, and something that web content producers who monetize their sites with ads will understand.
We wanted to name it "Publisher Ads" broadly (instead of Google), because we want to encourage other ad tech vendors to contribute audits and best practices of their own.
"Ad publishing" doesn't really work, but publishers don't publish ads, they publish content.
"AdSpeed" was a bit more exciting and memorable, but "Publisher Ads Audits" is more descriptive and doesn't have any branding conflicts.

Bikeshedding is totally warranted here. We don't want yet another project or folder renaming and it's important to set the right precedent for future plugins
Some notes about naming

"Audits" came when we needed a more descriptive name. "Publisher Ads Lighthouse Plugin" isn't super clear for users who are unfamiliar with Lighthouse but "Publisher Ads Audits for Lighthouse" immediately indicates that it audits your site. That said, I complete agree that "audits" is superfluous in this context
In addition to the reasons Rob mentioned, we dropped "speed" because some audits are not speed related, e.g. audits about ad placement.
We're trying to avoid being Google-focused long term. In a world with stack packs, we can genericize most audits and offer google-specific guidance in the stack pack.
Google Ads is a specific product (FKA AdWords), but the audits are focused on sellside products, Google Ad Manager and AdSense.
"Publisher" is meant to clarify that the audits are focused on sites and not creatives. We've discussed building audits for creatives, which would be "Advertiser/Marketer Ads Audits".

With the name publisher ads we're probably targeting people who are in charge of advertising inside publisher companies or know about the ecosystem. Maybe we should look into that direction. I'm not super good with names but what if we look more in the area of lighthouse-plugin-adserver-integration or lighthouse-plugin-ssp-integration

We're providing recommendations that address ad server tagging code, as
well as SSP, exchange, and DSP tags. I think using the generic "ads" makes
the most sense.
On Tue, May 21, 2019 at 7:20 PM Ward Peeters<EMAIL_ADDRESS>wrote:

With the name publisher ads we're probably targeting people who are in
charge of advertising inside publisher companies or know about the
ecosystem. Maybe we should look into that direction. I'm not super good
with names but what if we look more in the area of
lighthouse-plugin-adserver-integration or
lighthouse-plugin-ssp-integration
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/googleads/pub-ads-lighthouse-plugin/pull/60?email_source=notifications&email_token=AFJWH2Z7TB3ZRU6HJXK354TPWR7SRA5CNFSM4HOE5VA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV5ORIQ#issuecomment-494594210,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFJWH2YIEQLGKN4N4U42OK3PWR7SRANCNFSM4HOE5VAQ
.

Thanks everyone for the context. Super useful.
I realized I'm thinking of a few places this "name" is used, so let's enumerate them:

Name of this project, shown in the readme
The repository name
The name of the npm package
The string shown to users in DevTools, etc where they can include this plugin
What people search for to find this (probably a mix of the above)

For the DevTools checkbox, it seems like "Publisher Ads" is right.
Given that, I'd think the npm package name would be lighthouse-plugin-publisher-ads.
And as far as project name, "Publisher Ads (Audits) for Lighthouse" seems groovy. 😎
So wdyt about 1) lighthouse-plugin-publisher-ads for folder/package.json name and 2) doing a s/pub/publisher/ on the repo name?

@paulirish All that SGTM :slightly_smiling_face: will wait for agreement from @robhazan and @thebengeu before making the changes

The names "Publisher Ads Audits for Lighthouse" and "Publisher Ads Lighthouse Plugin" are both fine with me.

One way of thinking about this is that we're referring to 2 things:

The implementation: Lighthouse plugin
What the implementation (plugin) provides: Audits.

So everything that @paulirish proposed SGTM, with the addition that I think the project repo name, since it's the implementation, could be "Publisher Ads Lighthouse Plugin", for consistency.
For docs/links outside of this repo, I think it would be more descriptive to use "audits", e.g. "enable the Publisher Ads audits under Lighthouse's Community Plugins section", "using the Publisher Ads Audits for Lighthouse", etc.

SGTM


API Doctor doesn't understand odata casting in the URL

Sometimes API Producers will use odata casts in the HTTP URL. For example:
POST /sites/{site-id}/pages/{page-id}/microsoft.graph.sitePage/canvasLayout/verticalSection
This is valid but API Doctor fails saying that “microsoft.graph.{resource}” is not a defined navigation property.
We had this issue in PR: https://github.com/microsoftgraph/microsoft-graph-docs/pull/20977/files
To unblock the author and publish we changes to blocktype: ignored temporarily, but we need to fix this in API Doctor so we can properly generate snippets for these examples.

@millicentachieng

Could you kindly consider adding suppressions to bypass the error? Unless we encounter additional instances of this issue, we will not prioritize addressing it at this time.


Couldn't find theme

I tried running go run main.go but always get an error:
2019/01/20 20:44:53 Creating /tmp/go-build123402307/b001/exe/content/data  ``2019/01/20`` 20:44:53 Creating /tmp/go-build123402307/b001/exe/content/themes
2019/01/20 20:44:53 Creating /tmp/go-build123402307/b001/exe/content/images
2019/01/20 20:44:53 Creating /tmp/go-build123402307/b001/exe/content/https
2019/01/20 20:44:53 Creating /tmp/go-build123402307/b001/exe/content/plugins
2019/01/20 20:44:53 Creating /tmp/go-build123402307/b001/exe/content/pages
2019/01/20 20:44:53 Warning: couldn't load /tmp/go-build123402307/b001/exe/config.json, creating new config file.
2019/01/20 20:44:56 Error: Couldn't compile templates:Couldn't find a theme to use in /tmp/go- build123402307/b001/exe/content/themes
exit status 1
I checked and found the default theme "promenade" present in the content/themes folder, yet it still doesn't work
I found a similar issue: #100, but it didn't solve my problem

You could go build to get the binary, and then run it.


panic when trying to diagnose a service with unreconciled ingress

What
I get a go panic dump when I tried to use kn-diag to diagnose a service which is failing with "IngressNotConfigured: Ingress has not yet been reconciled". This is the dump:
➜  kn-plugin-diag git:(main) ✗ ./kn-diag service hello
Failed to load the status.conditions for kingress hello, <nil>
Resource Type                              | Name                                  | Created At              | Status.Condition
panic: strings: negative Repeat count

goroutine 1 [running]:
strings.Repeat(0x22d44b8, 0x1, 0xffffffffffffffdb, 0xc000221740, 0x2b)
	/usr/local/Cellar/go/1.16.3/libexec/src/strings/strings.go:529 +0x5e5
knative.dev/kn-plugin-diag/pkg/utils.(*PrintableTable).PrintDump(0xc000198380, 0xc00000ff01, 0x0, 0x0, 0xc000198380)
	/Users/maximilien/github/knative-sandbox/src/github/knative-sandbox/kn-plugin-diag/pkg/utils/table.go:111 +0x897
knative.dev/kn-plugin-diag/pkg/utils.(*PrintableTable).Print(0xc000198380)
	/Users/maximilien/github/knative-sandbox/src/github/knative-sandbox/kn-plugin-diag/pkg/utils/table.go:146 +0x34
knative.dev/kn-plugin-diag/pkg/command/diagnose.dumpToTables(0xc000113e00, 0x0, 0x0, 0x0, 0x0)
	/Users/maximilien/github/knative-sandbox/src/github/knative-sandbox/kn-plugin-diag/pkg/command/diagnose/service.go:92 +0x1d7
knative.dev/kn-plugin-diag/pkg/command/diagnose.NewServiceCmd.func2(0xc0004d2500, 0xc000218b40, 0x1, 0x1, 0x0, 0x0)
	/Users/maximilien/github/knative-sandbox/src/github/knative-sandbox/kn-plugin-diag/pkg/command/diagnose/service.go:61 +0x129
github.com/spf13/cobra.(*Command).execute(0xc0004d2500, 0xc000218b10, 0x1, 0x1, 0xc0004d2500, 0xc000218b10)
	/Users/maximilien/github/knative-sandbox/src/github/knative-sandbox/kn-plugin-diag/vendor/github.com/spf13/cobra/command.go:852 +0x472
github.com/spf13/cobra.(*Command).ExecuteC(0xc0004d2000, 0xc0000dff60, 0x1, 0x1)
	/Users/maximilien/github/knative-sandbox/src/github/knative-sandbox/kn-plugin-diag/vendor/github.com/spf13/cobra/command.go:960 +0x375
github.com/spf13/cobra.(*Command).Execute(...)
	/Users/maximilien/github/knative-sandbox/src/github/knative-sandbox/kn-plugin-diag/vendor/github.com/spf13/cobra/command.go:897
main.main()
	/Users/maximilien/github/knative-sandbox/src/github/knative-sandbox/kn-plugin-diag/cmd/main.go:41 +0x105

How
./kn-diag service hello

when service hello is failing with:
./kn service list                                      Michaels-MacBook-Pro.local: Wed May 12 15:24:49 2021

NAME     URL                                 LATEST          AGE     CONDITIONS   READY     REASON
hello    http://hello.default.example.com    hello-qgjrq-1   98d     1 OK / 3     Unknown   IngressNotConfigured : Ingr
ess has not yet been reconciled.

Expected
In the best case scenario, since this is a "diagnostic" plugin I would expect to have some diagnostic details on why the service is failing.
In the worst case scenario, I'd expect a message telling me the service is failing and more than "IngressNotConfigured : Ingr
ess has not yet been reconciled."
And in NO CASES a panic. That's a bug.
/kind bug

yes,  @maximilien   I will check further and fix it.

Fixed. Thanks @cdlliuy


Getting started

Hello,
This isn't really an issue as much as it is a request in getting help with using BLE made easy.  I'm some what new to app development and new to Kotlin.
Background
I'm currently working on a project where I want to control LED lights via ble.  My first step is to do a simple toggle the lights on and off.  I'm using HM-10 BLE module to receive signals and an arduino uno to control the signals to the lights.  I've used the dabble app to test my HM-10 and arduino uno code and have successfully seen that the lights turn on.  Now I would like to build my own app to control the lights from my phone.
What I'm Seeing
I've imported ble-made-easy into android studio and made sure there are no errors.  When I test the app (via wireless debugging) on my device I only see main activity (screen title says "AndroidEasyBLE").  No list view or text views or buttons.
Do I need to do anything in the main activity to inflate the fragments and bind correctly?  Is there an example I can run out of the box, where I can scan, and connect to a BLE device?
Thank you very much!
Swarandeep Singh

Hello there, thank you for writting the issue!
Well, I've realised with your issue that the example in master is not so good for new comers... Therefore I'll make some small changes to better demonstrate the library by just cloning the repository.

What version of Android are you using?

Hello,
It says Android Studio Arctic Fox | 2020 3.1 patch 2
runtime version 11.0.10...
Thanks,
Swarandeep Singh
On Thu, Nov 4, 2021 at 2:24 PM Leandro SQ @.***> wrote:

What version of Android are you using?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/LeandroSQ/android-ble-made-easy/issues/6#issuecomment-961389554,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AVGTOJG4R7PT64QEXBVLET3UKLTXLANCNFSM5HL6DHSQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

I've noticed that the library is not working properly on Android 11, since there were many updates regarding Bluetooth in this Android version.
I'm currently working on the android 11 support and it will be available ASAP.

I've committed on the branch feature/demo the fix for that.
Would you mind to try it and give feedback?

After I follow steps 1 - 4, I try to run the app on my device and I get the following error:
Could not find com.github.LeandroSQ:android-ble-made-easy:null.
Required by:
project :app
Search in build.gradle files
Once I removed the dependency, the example app worked great and I was able to connect to my HM-10 module.
When I go to incorporate the library into an app I'm currently building, I do the following:
1.) download/clone this git branch to a location on my desktop (https://github.com/LeandroSQ/android-ble-made-easy.git)
2a.) Copy the folder into my lib directory in Android Studio IDE for my project
2b.) add as library
3.) follow your steps 1 - 4 for installing
Then Can I simply copy you adapter and view directories from the example into my app directories?  Or am I over simplifying it?

Since you were cloning the repository and using the example App provided within it, you shouldn't have to add the implementation at the build.gradle files, that would be only if you are trying to embed the library into your application.
Since it worked with your peripheral with the latest changes, I'll be doing some more testing and a new version should be released soon.
And then you only will need to follow the install steps at the README.md.
You can import the library on your project, but it would be so much pain for something that will be available for you by just adding one line to your gradle file.
I'm working on the library to release this ASAP.
Thank you for contributing to the project, I really appreciate it.

I've submitted a pull request to master.
Could you try now follow the steps at the README.md for importing the version v1.5.0?

First Off, I want to say thank you for working with me.
I tried going through the new install steps and I'm getting sync & build failures.  I started a new project and just went through the Install steps, with one modification.
In my project I don't have an all projects attributes in my project build.gradle.  So, when I add:
allprojects {
repositories {
maven { url 'https://jitpack.io' }
}
}
I get the following error:
_A problem occurred evaluating root project 'BLEMadeEasy_tut3'.

Build was configured to prefer settings repositories over project repositories but repository 'maven' was added by build file 'build.gradle'_

Modification: add maven { url 'https://jitpack.io' } to buildscript -> repositories element.
Then I'm able to sync successfully.  I'm guessing its just the way I have my project and IDE configured.
Then add the dependency into my app build.gradle file and sync successfully.  However, when I got to run the project from there with nothing else done to the default "new project" code i.e. new project out of the box.  I get the following error:
7: Task failed with an exception.

What went wrong:
Execution failed for task ':app:mergeDebugNativeLibs'.

Could not resolve all files for configuration ':app:debugRuntimeClasspath'.
Could not find com.github.LeandroSQ:android-ble-made-easy:v1.5.0.
Searched in the following locations:
- https://dl.google.com/dl/android/maven2/com/github/LeandroSQ/android-ble-made-easy/v1.5.0/android-ble-made-easy-v1.5.0.pom
- https://repo.maven.apache.org/maven2/com/github/LeandroSQ/android-ble-made-easy/v1.5.0/android-ble-made-easy-v1.5.0.pom
- https://jcenter.bintray.com/com/github/LeandroSQ/android-ble-made-easy/v1.5.0/android-ble-made-easy-v1.5.0.pom
Required by:
project :app_

_...
Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/7.0.2/userguide/command_line_interface.html#sec:command_line_warnings
BUILD FAILED in 710ms
17 actionable tasks: 7 executed, 10 up-to-date_
Please let me know if I'm missing something blatantly obvious?
Thanks,
Swarandeep Singh

Do you have a "settings.gradle" file at the root of your project?
If so... Ignore the step to add "maven { url 'https://jitpack.io' }" into your project build.gradle
Instead try opening the settings.gradle file and making sure that the start of the file looks like this:
import org.gradle.api.initialization.resolve.RepositoriesMode

dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)

    repositories {
        google()
        mavenCentral()
        maven {
            url "https://www.jitpack.io"
        }
    }
}

The deprecated gradle error has gone away. But I'm still getting this error:
`7: Task failed with an exception.

What went wrong:
Execution failed for task ':app:mergeDebugNativeLibs'.

Could not resolve all files for configuration ':app:debugRuntimeClasspath'.
Could not find com.github.LeandroSQ:android-ble-made-easy:v1.5.0.
Searched in the following locations:
- https://dl.google.com/dl/android/maven2/com/github/LeandroSQ/android-ble-made-easy/v1.5.0/android-ble-made-easy-v1.5.0.pom
- https://repo.maven.apache.org/maven2/com/github/LeandroSQ/android-ble-made-easy/v1.5.0/android-ble-made-easy-v1.5.0.pom
- https://www.jitpack.io/com/github/LeandroSQ/android-ble-made-easy/v1.5.0/android-ble-made-easy-v1.5.0.pom
Required by:
project :app`

When I click on those location I get a 404 error.  Is it possible that there is something amiss in the GitHub repository setup or the syntax for the dependency?

It seems that Jitpack was building the library with Java version 1.8...
I've changed to Java 11, and published v1.5.1... Still testing though

I've created a new project to simulate your problem.
After creating it the steps I've done were:

Add implementation 'com.github.LeandroSQ:android-ble-made-easy:v1.5.1' to App build.gradle
Add maven { url 'https://jitpack.io' } inside buildscript -> repositories to Project build.gradle
Add maven { url 'https://jitpack.io' } inside dependencyResolutionManagement -> repositories to settings.gradle
Gradle sync

And done!
I'm able to use the library normally.

Success!  It finally built and I can actually instantiate var ble : BLE  now!  I don't know if that is the correct use but I'm ready to start learning!  Thank you so much!!!

Happy to help


⚠ Bofrost.at has degraded performance

In 803c63e, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 943 ms

Resolved: Bofrost.at performance has improved in d9c2bb3.


bouncycastle 1.57 jar takes 5-10 seconds longer to load in Tomcat than 1.56 jar

We have noticed that the bouncycastle 1.57 jar takes 5-10 seconds longer to load in Tomcat (version 8.0.45) than the 1.56 jar did.  Is this expected?  I don't see anything in the 1.57 release notes that provides any obvious explanation.
Thanks,
Steve

Could you clarify if you mean just the BC provider or the new BCJSSE provider or both? Historically such startup delays have had to do either with generating DH parameters, or initialising RNGs (e.g. in VMs).

See this from 1.57 release notes:

The default parameter sizes for DH and DSA are now 2048. If you have been relying on key pair generation without passing in parameters generated keys will now be larger.

I think that was increased from 1024, so perhaps you (or tomcat, or JSSE or ...) are now generating fresh 2048 bits DH parameters at startup, and BC looks for so-called safe primes, which is expensive.

We are using the following BC jars: bcprov-jdk15on-1.57.jar, bcpkix-jdk15on-1.57.jar, bc-fips-1.0.0.jar.
I did see that statement in the release notes, however we do not generate SSH keys at runtime in our servlet.  We generate them at installation time.  Also, the additional delay we see in Tomcat occurs before our servlet even starts executing.  It occurs at jar-load-time, according to jstack.

Yes, that sounds a lot like parameter generation. Are you able to trigger a stack dump when it's half way through initialising? You'll probably find someone (not necessarily you) is generating a key pair using the BC provider.

By the way. I just noticed you listed bc-fips as well as bcprov. They don't play well together, even slightly.

I see the following stack trace frequently during Tomcat startup:
"localhost-startStop-1" #14 daemon prio=5 os_prio=0 tid=0x00007f92ac002000 nid=0x255a runnable [0x00007f92ec2a7000]
java.lang.Thread.State: RUNNABLE
at java.util.Vector.(Vector.java:148)
at sun.security.util.DerInputStream.readVector(DerInputStream.java:420)
at sun.security.util.DerInputStream.getSequence(DerInputStream.java:332)
at sun.security.provider.DSA.engineVerify(DSA.java:273)
at sun.security.provider.DSA.engineVerify(DSA.java:244)
at java.security.Signature$Delegate.engineVerify(Signature.java:1219)
at java.security.Signature.verify(Signature.java:652)
at sun.security.pkcs.SignerInfo.verify(SignerInfo.java:447)
at sun.security.pkcs.PKCS7.verify(PKCS7.java:579)
at sun.security.pkcs.PKCS7.verify(PKCS7.java:596)
at sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:292)
at sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:268)
at java.util.jar.JarVerifier.processEntry(JarVerifier.java:316)
at java.util.jar.JarVerifier.update(JarVerifier.java:228)
at java.util.jar.JarFile.initializeVerifier(JarFile.java:383)
at java.util.jar.JarFile.getInputStream(JarFile.java:450)
- locked <0x00000000fb8def30> (a sun.net.www.protocol.jar.URLJarFile)
at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:162)
at java.net.URL.openStream(URL.java:1045)
at org.apache.catalina.loader.WebappClassLoaderBase.findLoadedResource(WebappClassLoaderBase.java:2737)
at org.apache.catalina.loader.WebappClassLoaderBase.getResourceAsStream(WebappClassLoaderBase.java:1123)
at org.apache.catalina.startup.ContextConfig.populateJavaClassCache(ContextConfig.java:2207)
at org.apache.catalina.startup.ContextConfig.populateJavaClassCache(ContextConfig.java:2197)
at org.apache.catalina.startup.ContextConfig.checkHandlesTypes(ContextConfig.java:2102)
at org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2054)
at org.apache.catalina.startup.ContextConfig.processAnnotationsJar(ContextConfig.java:1999)
at org.apache.catalina.startup.ContextConfig.processAnnotationsUrl(ContextConfig.java:1969)
at org.apache.catalina.startup.ContextConfig.processAnnotations(ContextConfig.java:1923)
at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1166)
at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:783)
- locked <0x00000000e3101cc0> (a org.apache.catalina.startup.ContextConfig)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:307)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:95)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5213)
- locked <0x00000000e3101950> (a org.apache.catalina.core.StandardContext)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
- locked <0x00000000e3101950> (a org.apache.catalina.core.StandardContext)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:753)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:729)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717)
at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:621)
at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1835)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
It seems to be doing digital signature verification of the JAR files Tomcat is trying to use.  Does that use the BC library underneath?
Regarding FIPS mode, when our servlet starts up we call CryptoServicesRegistrar.setApprovedOnlyMode and pass in either true or false depending on the setting of a global property that the user choses at installation time when he deploys our servlet+Tomcat.  So during any given execution of our servlet, we are either using FIPS mode or non-FIPS mode, not a mixture of both.

Hmm. Alright that's not BC code... One other thing has changed though, both in the VM and BC that might be connected with this - there are now two JCE signing certificates, one use SHA-1, the other using SHA-256, so this increases the number of message digests calculated. It shouldn't affect the signatures though as the effect is to add 2 DSA signature valuations rather than one.
So it looks like the JVM class loaders are constantly re-evaluating the signatures... With your situation the only jars you should need are bcpkix-fips and bc-fips. bcprov and bc-fips contain classes in the same packages, a class loader can only load one of them successfully. It may be that the jars are being repeatedly loaded in lower level classloaders as a higher level one is no longer able to share them.

We finally got around to removing the unnecessary jars and trying this again.  It doesn't seem to help with the startup time however unfortunately.

I wonder what it's doing. You could try removing the signatures from the non-provider jar to see if that makes any difference. If it doesn't it would mean the effort is concentrated on the provider jar only and it probably points to the difference between using SHA-256 to SHA-1.

Appears to be inactive. Having said that, I'm wondering if this might have been an RNG issue as well. Closing for now.


Gaudi fix hl_qual tests

Issues Resolved by this Pull Request
Some hl_qual tests are failing because of a missing libraries and obsolete parameters
Fixes #
Remove deprecated variable and add required library
Suggested Reviewers
@abhishek-sa1 @priti-parate

Can one of the admins verify this patch?


Problem parsing  XML with single or multiple elements

Take the following for example:
<foo>
    <bar>
         <item></item>
   <bar>
   <bar>
         <item></item>
         <item></item>
   </bar>
</foo>

You have to make a choice to either parse as a single item or an array [item]. Both options are not available.

This is an interesting issue. I might have an idea on how to solve it.
Until the next release you can map the following example XML:
<foo>
    <bar>
        <item>1</item>
    </bar>
    <bar>
        <item>2</item>
        <item>3</item>
    </bar>
</foo>

Using this trick:
class Foo: XMLMappable {
    var nodeName: String!

    var bar: [Bar]?

    required init(map: XMLMap) {

    }

    func mapping(map: XMLMap) {
        bar <- map["bar"]
    }
}

class Bar: XMLMappable {
    var nodeName: String!

    var items: [Int]?
    private var item: Int?

    required init(map: XMLMap) {

    }

    func mapping(map: XMLMap) {
        items <- map["item"]
        item <- map["item"]
        if let singleItem = item {
            items = [singleItem]
        }
    }
}

It isn't pretty but will do the job.

Cheers! This worked.


fix(issue): Fix crash due to undefined navigation params

Question
Response

Version?
v1.4.0

Devices tested?
iPhone 6, iOS 11.0 simulator

Bug fix?
yes

New feature?
no

Includes tests?
no

All Tests pass?
yes

Related ticket?
#201

Description

From #332, we can learn that this.props.navigation.state.params.issue is not available when visiting from notifications. The safer variable is this.props.issue.
By scanning similar codes, I found another crash and fixed. If visiting an issue without push permissions, you can invoke an action sheet from the top right corner and select Open in Browser, then the app will also crash.

Coverage remained the same at 39.861% when pulling 01da9378db06301699760bb7d35b8912fc1ecfc3 on chinesedfan:fix_201 into 14532ce689d7eda9eb5d7f98ad9d402b31753447 on gitpoint:master.


unix,stream: fix shutdown hang

While normally, users will likely typically call uv_close in their
uv_shutdown callback, some callers (notable nodejs) do not. This can
result in libuv keeping the loop active, even though there are no
outstanding reqs left to handle.
This bug was added in 80f2f826bf90b84e659321c0b7fd8af419acb85e, where
the premise of that commit was simply incorrect, as demonstrated by the
added test. (@bnoordhuis)
Refs: https://github.com/libuv/libuv/issues/3202#issuecomment-874961223
CI: https://ci.nodejs.org/job/libuv-test-commit/2178/ + https://ci.nodejs.org/job/libuv-test-commit-windows-cmake/371/
CI+node: ~~https://ci.nodejs.org/view/libuv/job/libuv-in-node/186/~~ https://ci.nodejs.org/view/libuv/job/libuv-in-node/187/

bump

bump

"stopping a handle" in libuv means roughly "to stop reading a handle". There is therefore never a time that a pending write means you can't stop reading a handle–it just isn't how libuv defines this.

I was thinking more on the case mentioned originally where ther

The case mentioned in the original commit cannot happen, since there is never a case where a pending write needs to force the loop to continue reading from the handle. The bit here does not control whether the loop exits, it controls whether it is waiting for reads from the handle, but those reads will never happen, since the user stopped the handle. Which is fortunate, because otherwise there would be a massive bug there–note the wording there ("force libuv to continue reading from the handle if there are incomplete writes")–and things would have needed a major redesign.

Thanks a lot for this fix! My team was seeing this multiple times a week when running prettier and webpack on CI.
We were debugging this quite thoroughly through llnode and strace before realizing the latest Node.js 16.x version contained the fix already, and then narrowed it back to this change.

Posting some debugging we did in case it helps others find this PR.
strace showed a hang on epoll_wait that was eventually killed 10 minutes later by CI.
11:27:45 getpid()                       = 16831
11:27:45 epoll_wait(13, [{EPOLLIN, {u32=16, u64=16}}], 1024, -1) = 1
11:27:45 read(16, "\1\0\0\0\0\0\0\0", 1024) = 8
11:27:45 epoll_wait(13, 0x7ffc8bec4fe0, 1024, -1) = -1 EINTR (Interrupted system call)
11:47:39 --- SIGABRT {si_signo=SIGABRT, si_code=SI_USER, si_pid=736, si_uid=1000} ---
11:47:39 +++ killed by SIGABRT (core dumped) +++

Debugging core dumps in llnode showed the following thread stacktrace dumps:
(llnode) bt all
* thread #1, name = 'node', stop reason = signal SIGABRT
  * frame #0: 0x00007fcc850c7a47 libc.so.6`epoll_wait + 87
    frame #1: 0x0000000001348150 node`uv__io_poll(loop=0x0000000002c9aac0, timeout=-1) at linux-core.c:309
    frame #2: 0x0000000001335e4f node`uv_run(loop=0x0000000002c9aac0, mode=UV_RUN_DEFAULT) at core.c:381
    frame #3: 0x0000000000a4b665 node`node::NodeMainInstance::Run() + 581
    frame #4: 0x00000000009da5a8 node`node::Start(int, char**) + 664
    frame #5: 0x00007fcc84fc7bf7 libc.so.6`__libc_start_main + 231
    frame #6: 0x0000000000979215 node`_start + 41
  thread #2, stop reason = signal 0
    frame #0: 0x00007fcc853a4ad3 libpthread.so.0`__pthread_cond_wait + 579
    frame #1: 0x00000000013445b9 node`uv_cond_wait(cond=<unavailable>, mutex=<unavailable>) at thread.c:782
    frame #2: 0x0000000000a75f14 node`node::(anonymous namespace)::PlatformWorkerThread(void*) + 196
    frame #3: 0x00007fcc8539e6db libpthread.so.0`start_thread + 219
    frame #4: 0x00007fcc850c771f libc.so.6`clone + 63
  thread #3, stop reason = signal 0
    frame #0: 0x00007fcc853a4ad3 libpthread.so.0`__pthread_cond_wait + 579
    frame #1: 0x00000000013445b9 node`uv_cond_wait(cond=<unavailable>, mutex=<unavailable>) at thread.c:782
    frame #2: 0x0000000000a75f14 node`node::(anonymous namespace)::PlatformWorkerThread(void*) + 196
    frame #3: 0x00007fcc8539e6db libpthread.so.0`start_thread + 219
    frame #4: 0x00007fcc850c771f libc.so.6`clone + 63
  thread #4, stop reason = signal 0
    frame #0: 0x00007fcc853a4ad3 libpthread.so.0`__pthread_cond_wait + 579
    frame #1: 0x00000000013445b9 node`uv_cond_wait(cond=<unavailable>, mutex=<unavailable>) at thread.c:782
    frame #2: 0x0000000000a75f14 node`node::(anonymous namespace)::PlatformWorkerThread(void*) + 196
    frame #3: 0x00007fcc8539e6db libpthread.so.0`start_thread + 219
    frame #4: 0x00007fcc850c771f libc.so.6`clone + 63
  thread #5, stop reason = signal 0
    frame #0: 0x00007fcc853a4ad3 libpthread.so.0`__pthread_cond_wait + 579
    frame #1: 0x00000000013445b9 node`uv_cond_wait(cond=<unavailable>, mutex=<unavailable>) at thread.c:782
    frame #2: 0x00000000013309ee node`worker(arg=<unavailable>) at threadpool.c:76
    frame #3: 0x00007fcc8539e6db libpthread.so.0`start_thread + 219
    frame #4: 0x00007fcc850c771f libc.so.6`clone + 63
  thread #6, stop reason = signal 0
    frame #0: 0x00007fcc853a4ad3 libpthread.so.0`__pthread_cond_wait + 579
    frame #1: 0x00000000013445b9 node`uv_cond_wait(cond=<unavailable>, mutex=<unavailable>) at thread.c:782
    frame #2: 0x0000000000a75f14 node`node::(anonymous namespace)::PlatformWorkerThread(void*) + 196
    frame #3: 0x00007fcc8539e6db libpthread.so.0`start_thread + 219
    frame #4: 0x00007fcc850c771f libc.so.6`clone + 63
  thread #7, stop reason = signal 0
    frame #0: 0x00007fcc853a77c6 libpthread.so.0`do_futex_wait.constprop.1 + 54
    frame #1: 0x00007fcc853a78b8 libpthread.so.0`__new_sem_wait_slow.constprop.0 + 152
    frame #2: 0x0000000001344392 node`uv_sem_wait at thread.c:626
    frame #3: 0x0000000001344380 node`uv_sem_wait(sem=0x0000000002c93be0) at thread.c:682
    frame #4: 0x0000000000b00d25 node`node::inspector::(anonymous namespace)::StartIoThreadMain(void*) + 53
    frame #5: 0x00007fcc8539e6db libpthread.so.0`start_thread + 219
    frame #6: 0x00007fcc850c771f libc.so.6`clone + 63
  thread #8, stop reason = signal 0
    frame #0: 0x00007fcc853a4ad3 libpthread.so.0`__pthread_cond_wait + 579
    frame #1: 0x00000000013445b9 node`uv_cond_wait(cond=<unavailable>, mutex=<unavailable>) at thread.c:782
    frame #2: 0x00000000013309ee node`worker(arg=<unavailable>) at threadpool.c:76
    frame #3: 0x00007fcc8539e6db libpthread.so.0`start_thread + 219
    frame #4: 0x00007fcc850c771f libc.so.6`clone + 63
  thread #9, stop reason = signal 0
    frame #0: 0x00007fcc850c7a47 libc.so.6`epoll_wait + 87
    frame #1: 0x0000000001348150 node`uv__io_poll(loop=0x0000000003172888, timeout=-1) at linux-core.c:309
    frame #2: 0x0000000001335e4f node`uv_run(loop=0x0000000003172888, mode=UV_RUN_DEFAULT) at core.c:381
    frame #3: 0x0000000000a7a178 node`node::WorkerThreadsTaskRunner::DelayedTaskScheduler::Start()::'lambda'(void*)::_FUN(void*) + 120
    frame #4: 0x00007fcc8539e6db libpthread.so.0`start_thread + 219
    frame #5: 0x00007fcc850c771f libc.so.6`clone + 63
  thread #10, stop reason = signal 0
    frame #0: 0x00007fcc853a4ad3 libpthread.so.0`__pthread_cond_wait + 579
    frame #1: 0x00000000013445b9 node`uv_cond_wait(cond=<unavailable>, mutex=<unavailable>) at thread.c:782
    frame #2: 0x00000000013309ee node`worker(arg=<unavailable>) at threadpool.c:76
    frame #3: 0x00007fcc8539e6db libpthread.so.0`start_thread + 219
    frame #4: 0x00007fcc850c771f libc.so.6`clone + 63
  thread #11, stop reason = signal 0
    frame #0: 0x00007fcc853a4ad3 libpthread.so.0`__pthread_cond_wait + 579
    frame #1: 0x00000000013445b9 node`uv_cond_wait(cond=<unavailable>, mutex=<unavailable>) at thread.c:782
    frame #2: 0x00000000013309ee node`worker(arg=<unavailable>) at threadpool.c:76
    frame #3: 0x00007fcc8539e6db libpthread.so.0`start_thread + 219
    frame #4: 0x00007fcc850c771f libc.so.6`clone + 63
(llnode)


TestIndexSortSortedNumericDocValuesRangeQuery.testCountBoundary failure

Description
Found this test failing in Lucene-Check-9.x - Build # 4239.
Steps to repro:
gradlew test --tests TestIndexSortSortedNumericDocValuesRangeQuery.testCountBoundary -Dtests.seed=A11A06AE642497F1 -Dtests.multiplier=2 -Dtests.locale=en-KE -Dtests.timezone=Singapore -Dtests.asserts=true -Dtests.file.encoding=UTF-8

I've been able to repro this failure in both branch_9x as well as main. This is what I found with a debugger -
It seems that in this test seed, the missing document (created here), goes into a separate leaf. Then for that leaf context, the IteratorAndCount has count = -1, taking the flow to the fallback query.
And since the document does not have a points value, the fallback query gets PointValues == null, leading it to return a 0 here.
I'm not very familiar with this part of Lucene, but I guess it is likely for the missing document to land in a leaf of its own. Would it help if the missing doc had a points value but for a different field?
Gradle command to reproduce
gradlew test --tests TestIndexSortSortedNumericDocValuesRangeQuery.testCountBoundary -Dtests.seed=A11A06AE642497F1 -Dtests.multiplier=2 -Dtests.locale=en-KE -Dtests.timezone=Singapore -Dtests.asserts=true -Dtests.file.encoding=UTF-8

Wait.. I think the assert should simply be on total no. of documents, not documents per leaf. Something like:
    int count = 0;
    for (LeafReaderContext context : searcher.getLeafContexts()) {
      count += weight.count(context);
    }
    assertEquals(2, count);

This passes on my workspace. I'll raise a PR.


X11 rewrite

A new X11 backend was written from scratch to improve performance and maintainability.

I'm quiet frustrated after going through this. This is kind of terrible, but I can't see any other way around it.

Yeah, no surprise so many are excited about Wayland. (Although I actually don't know how the clipboard is handled in Wayland.) It is annoying but this PR is a huge improvement on the previous implementation. The previous was shameful but this is something that I am proud of, given the weird design of X.


⚠ Bofrost.at has degraded performance

In 0280201, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1103 ms

Resolved: Bofrost.at performance has improved in 93eef09 after 9 minutes.


SystemLayerImplSelect: fix Request/ClearCallbackOnPendingXXX() for…

…dispatch case, clean transport
Problem
For CHIP_SYSTEM_CONFIG_USE_DISPATCH (Darwin) case, Request/ClearCallbackOnPendingXXX() were not working (no loop calling select to evaluate watches).
But still, these methods were called in TCP and UDP endpoint implementations, despite dispatch-specific extra code for the same purpose in the endpoints.
Change overview
This changeset now moves all CHIP_SYSTEM_CONFIG_USE_DISPATCH specific socket watching code into SystemLayerImplSelect, by making Request/ClearCallbackOnPendingXXX() actually working with dispatch.
The issue surfaced in my (a bit exotic) use case when I needed to get callbacks for events on a plain socket not wrapped as TCPEndPoint.
Doing this, I realized Request/ClearCallbackOnPendingXXX() were non-functional due to the missing select main loop.
Fixing this revealed the similar dispatch code in the endpoints that was needed to get those events handled despite Request/ClearCallbackOnPendingXXX() not working. That dispatch specific endpoint code now became redundant (delivering events twice), so had to be removed.
Testing

manually regression tested with bridge-example running on darwin (hence using dispatch), showing no difference when being run with and w/o these changes applied - except for Request/ClearCallbackOnPendingXXX() not working without the changes.

I am aware that this might be a too deep intervention and too limited testing for coming from a CHIP newbie like me (not newbie in code deep diving, though), but I think it cleans up an inconsistency in the IP endpoints, and maybe can be of use after review by CHIP experts...

@vivien-apple

@plan44 Could you look into the test failures, please?

Fast tracking platform changes

@plan44 Can you please fix the issue in https://github.com/project-chip/connectedhomeip/pull/21135#pullrequestreview-1051517126

@bzbarsky-apple Turns out to be much more difficult than I thought...
I tried to fix and test the issue you pointed out. I tried several variants, but did not get TCPtest from src/transport/raw/tests producing reliable results (random crash/success/failure on every invocation). It does so in original form (where it does not bother to set up a dispatch queue at all) and also when I patched NetworkTestHelpers.cpp to install a dispatch queue.
All other tests are fine (run on macOS).
First I just made sure suspend/resume remains balanced in SystemLayerImplSelect as you suggested.
Then, suspecting problems with calling dispatch_suspend from within a callback (TCPtest does that), stopped using suspend/resume at all, but just using the flags to decide about calling back or not.
This is as near as I could get to the original semantics where Request/ClearCallback just change flags - only the first RequestCallback installs the dispatch source.
As I do not want to trigger the whole PR machinery with this WIP, this is on a separate branch in my fork for now:
https://github.com/plan44/connectedhomeip/tree/PR/fix_socket_event_watching_WIP
The failures in TCPtest seem more like a test artifact than a real problem to me, but I definitely don't understand the stack well enough yet to be sure.

@plan44 When running the unit tests, there is no dispatch queue (long story).  So the ChipLogError(DeviceLayer, "RequestCallbackOnPendingRead with no dispatch queue installed: callback will not work"); bit from the WIP might be the issue there.
Basically, when there is no dispatch queue that code is supposed to fall back on the non-dispatch "just do sockets" code....

When running the unit tests, there is no dispatch queue (long story)
I can imagine ;-) Trying to debug I realized that the PlatformManager would be needed to properly set it up, firing up half of the stack for a test that should be simple.

Basically, when there is no dispatch queue that code is supposed to fall back on the non-dispatch "just do sockets" code....

Ok, thanks. That helped me to understand the problem: In my previous attempt I intentionally only set the flag when the source could actually be installed. This broke the select()-based DriveIO() fallback.
The new version now just always sets the flag, and then tries to install the source, but when no dispatch is available it just outputs the warning. In non-test cases, the warning should definitely never appear, in tests it may, depending on the setup (and I changed the wording to make that clear).
See new PR #21349

I realized that the PlatformManager would be needed to properly set it up

Yep, and then the rabbit hole gets deep.  :)  #21349 looks great, thank you!


Guardians of the rift !kc stopped updating

Describe the bug
3 days ago my !kc gotr (guardians of the rift) killcount in the chatbox stopped updating, it's stuck at 201 no matter what i do.
please see the screenshot i've attached
it's not really game breaking, but it would mean the world to me if you could help me out here,
Kind regards
Environment (please complete the following information):

OS: Windows
RuneLite version: [1.8.17]
Launcher version: ?

This should already be fixed in 9bd36db0c9f0e42adaab9a3b546adcdc8a72cc0f. Getting any further completions will update your saved kill count.


May make more sense to import the BackendEntrypoint directly

Is your feature request related to a problem? Please describe.
Currently it is not clear what import eratos_xarray actually does in the code. If a user forgets to import it, it will obviously fail with an error as xarray is unable to find the eratos engine. However when working in Jupyter Notebooks I found that if I try to import eratos_xarray after already calling xr.open_dataset it will still fail. This is because xarray internally caches all engines once it tries to open a dataset, and importing eratos_xarray does not actually update this list. However if we import the EratosBackendEntrypoint directly it works.
The following code reproduces the issue -
import xarray as xr
from eratos.creds import AccessTokenCreds
import os
eratos_id = os.environ['ERATOS_KEY']
eratos_secret = os.environ['ERATOS_SECRET']

ecreds = AccessTokenCreds(
  eratos_id,
  eratos_secret)

ern = "ern:e-pn.io:resource:eratos.blocks.silo.maxtemperature"
# does not work
print("Trying with no import")
try:
    ds = xr.open_dataset(ern, engine='eratos', eratos_auth=ecreds)
except Exception as e:
    print(e)

import eratos_xarray
print("Trying with eratos_xarray imported")
# does not work
try:
    ds = xr.open_dataset(ern, engine='eratos', eratos_auth=ecreds)
except Exception as e:
    print(e)

print("Trying with engine class")
from eratos_xarray.backend.eratos_ import EratosBackendEntrypoint
ds = xr.open_dataset(ern, engine=EratosBackendEntrypoint, eratos_auth=ecreds)
print(ds)

Describe the solution you'd like
We should recommend people to import EratosBackendEntrypoint (perhaps make edits to the __init__.py and add an __init__.py to backend so it can be imported directly). It makes it a bit more clear what eratos_xarray actually does and avoids the obscure issue I had above.

Importing the backend via import without specifying the engine is a pretty common pattern however I do think the documentation could be clearer.
see rasterio for example
https://corteva.github.io/rioxarray/stable/getting_started/getting_started.html
https://corteva.github.io/rioxarray/stable/examples/reproject.html
I think a better alternative might be to support also support an explicit alternative such as eratos_xarray.open_dataset(...) if that is preferred
e.g.
import eratos_xarray # for the extension to load
import xarray as xr
ern = ...
creds = ... etc
eratos_xarray.open_dataset(ern, eratos_auth=creds) #   for a more explicit implementation
xr.open_dataset(ern, eratos_auth=creds) #  identical to line above with backend loaded

From the xarray documentation it also seems that you can 'register' the backend by adding a couple lines in the build file.
[tool.poetry.plugins."xarray.backends"]
eratos = "eratos_xarray.backend.eratos_:EratosBackendEntrypoint"

This makes it so that the eratos backend is always available even without the import eratos_xarray line. Perhaps this is another solution?

@steven-eratos, if you can demonstrate the use of the EratosBackendEntrypoint and it improves the user experience I could review the PR. Judging by this guide it doesn't seem too involved.

@aidanjgriffiths , I've made a PR to add the feature here.


If throttling happens, rendering won't act correctly (speed for entities).

Bevy version
0.6.1
https://github.com/norlock/sparticles-bevy/tree/bug-more-particles
8c6bf7559b3ec8fc1a7ad3a378ef62427408b7ca
Operating system & version
I use Arch on Wayland.
What you did
In main.rs  there is a field I changed:
particles_per_emission: 200,
If you change from 20 particles_per_emission to 200 you can see it will start to drastically increase in speed.
I use delta in transform, and turned off all animations / forces to turn off external factors.
What you expected to happen
That it won't drastically speed up if it starts to throttle but stay in range of its actual speed. I can understand if it stutters but not to speed up.
What actually happened
It will start to speed up.
Additional information

8c6bf7559b3ec8fc1a7ad3a378ef62427408b7ca (bug-more-particles branch)

I think you intended to link to one of your repos here? I'm having a hard time understanding what you're trying to report.

8c6bf7559b3ec8fc1a7ad3a378ef62427408b7ca isn't an object in my local clone of bevy's repository, and neither GitHub nor Google give any results for commits with that hash.
Additionally, the string particles_per_emission never appears in the bevy respository, and "bug-more-particles" bevy also gives no results.

I added my repository I forgot, but what I'm trying to explain is that somewhere if it starts to throttle (by changing particles to 200), the movement speeds up. Maybe I'm too inexperienced with gamedev and not really grasping what is causing it. I thought the delta I added in the transform system would mitigate the changes in frame performance and that it shouldn't visually appear to speed up (in this case movement of particles).

So, questions for help with specific problems belong in Discussions. I'm going to convert this to a discussion. If you can identify a clear bug in Bevy's code with a minimal reproduction, please feel free to file a new issue.


could you add support for context menu and dnd?

really need this function

The extension is designed so that any configuration may be used JsTree.
You simply set the parameters and get what you want!


ROX-15334: Use non-blocking locks in Postgres upserts

Description
Straight forward, plus a metric for ProcessAggregator
Checklist

[ ] Investigated and inspected CI test results
[ ] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.
Testing Performed
Will check CI logs to see if any new conflicts are added

/test

/test gke-postgres-scale-tests

/retest