GUACAMOLE-197: Implement Support for RADIUS Authentication

This PR adds a RADIUS authentication module, allowing users to authenticate against RADIUS via a variety of protocols.  It includes support for TLS as well as for 2-factor via the radius AccessChallenge packet.  It uses JRadius as the RADIUS implementation.

I think this should be pretty much ready, unless there are any other questions/concerns on this.

OK, without repeating things further, I think it'd be good to go through the codebase and:

Make sure things are commented appropriately. Everything that can be JavaDoc'd should be JavaDoc'd.
Give some extra thought to readability and verifiability. If something ends up with long and complicated logic, it might be better off broken into pieces that are easy to see and understand as correct.
Discover and check the licenses of the bundled dependencies.

Let me know if you need any assistance with the above.

I believe I have comments everywhere necessary for the JavaDoc stuff.
Still looking over and thinking about code that might be better split into its own function.
I believe all of the bundle licenses are updated correctly.

Any further issues/comments, here?

Oh, yeah, still needed help on this one with the bouncycastle library build/dependency issue here...

Any success or pointers with the signed JAR (bouncycastle) issue?  Thanks...

I'll clone your branch and give it a shot.
Anything I should know before I do? Do I need a RADIUS deployment in order to test whether that portion works/fails?

No, you should not need a working RADIUS implementation for the bouncycastle include issue - the behavior I've observed is that as soon as you load Guacamole with the RADIUS extension in the extensions folder, you'll get an error/stracktrace in the log file regarding the signature issues.

What error were you seeing in your case which lead you to believe that the problem was due to the signed classes?
I'm seeing failure to load the radius auth provider class, which is consistent with what you're describing, but there's nothing in the stack trace that screams cryptographic signatures, though I have no explanation at present why this may be happening other than what you've said.
Did things work in your case once the signature-related files were stripped from the .jar?

The error I saw was very generic, too:

Extension "guacamole-auth-radius-0.9.11-incubating.jar" could not be loaded: Authentication provider class not                                                                                found.
09:45:42.268 [localhost-startStop-153] DEBUG o.a.g.extension.ExtensionModule - Unable to load extension.
org.apache.guacamole.GuacamoleException: Authentication provider class not found.

I cannot remember how I stumbled across the error that clued me in to the signed library issue, but somehow I managed to get stumble across an error that led me to a Google search that led me to a page buried three pages into the search that described the error.  I can successfully load the module if, after building it, I do the following:
zip -d extensions/guacamole-auth-radius/target/guacamole-auth-radius-0.9.11-incubating.jar META-INF/BCKEY.SF deleting: META-INF/BCKEY.SF
zip -d extensions/guacamole-auth-radius/target/guacamole-auth-radius-0.9.11-incubating.jar META-INF/BCKEY.DSA deleting: META-INF/BCKEY.DSA
Taking that resulting JAR file and placing it into the extensions directory and then loading the Guacamole WAR file results in a successful load.  So, it looks like those files need to be excluded from the resulting radius JAR file, but I ran into several issues trying to accomplish that with various maven plugins.

It looks like excluding the signature bits is doable using the <excludes>...</excludes> configuration for the maven-dependency-plugin already in use for unpacking dependencies. It accepts a comma-delimited list of patterns to exclude.
BUT (brace yourself):
It doesn't matter.
We can't use JRadius at all. It's dual-licensed GPL/LGPL, both of which are Category X: https://www.apache.org/legal/resolved.html#category-x
If we're going to add official support for RADIUS to Guacamole, we'll need to use a different library; something which is under a license that can be included: https://www.apache.org/legal/resolved.html#category-a
Seems there's much more to be done than just the issue with signatures, though at least we have a good start here in principle.

I did also look into possibly adding support to the extension subsystem for nested .jar files within extensions, which may be an option should it be necessary to add support for signed dependencies (rather than requiring that the signature bits be stripped).
Though the licensing issues with JRadius still mean we don't need to worry about the above until we find a replacement library (which hopefully will not require the same workarounds).

Well, crud.
-Sigh-
The bad news is that JRadius seems to be the most complete library out there.  In fact, really the only open-source Java-based RADIUS client that can be considered complete.  I think the next one, and maybe the only working one, is TinyRadius (MAVEN says it's licensed Apache 2.0).  I started to use this one, but quickly found that it lacks support for anything beyond basic PAP and (maybe) CHAP support.  A very low-end implementation of a RADIUS client.  If you know of others, I'd appreciate it - a MAVEN repository search and Google search don't really turn up much else that I can see.
So, I suppose I can go back and implement with the TinyRadius library with the caveat that it only supports very basic RADIUS implementations, and maybe some instructions on securing PAP-based RADIUS via stunnel.
Would another option be for me to distribute this extension separately from the Guacamole project altogether?  I'm definitely not familiar with all of the ins and outs of Open Source licensing, so I'm not even sure this is feasible given that most of the code in the extension is already licensed under the Apache 2.0 license, but perhaps if that code continues to be licensed under Apache 2.0 and it's just not ASF distributing it it would be okay?  I'm not saying this is a good option, just an option.
The final thing I can think of would be to contact the maintainers of the JRadius library and see if they'd be willing to dual-license it under a license more compatible with ASF/Apache 2.0.  Again, I'm not sure this is even feasible, just throwing it out there as a possible solution.
Crud.

I think the next one, and maybe the only working one, is TinyRadius (MAVEN says it's licensed Apache 2.0).

Unfortunately, it looks like the metadata in Maven Central for that library is just wrong. Going to the TinyRadius project itself, they state LGPL, and LICENSE file in their source agrees:
http://tinyradius.sourceforge.net/
I think we're out of luck with respect to those libraries, but there must be something somewhere ... somehow. It might be worth opening a thread in the incubator general list to see if anyone is aware of a Java library for RADIUS which isn't GPL/LGPL.

Would another option be for me to distribute this extension separately from the Guacamole project altogether?

Sure - nothing stops anyone from doing this. We just can't bundle GPL/LGPL dependencies within the project.
The issue is not that people can't do this in general, but rather that Apache projects can't do this because then the resulting code is under more restrictions than imposed by the Apache license itself.
.....
We actually may not be hosed. Further reading in the ASF legal docs:

... no source code can be from Category X and that any convenience binaries produced may not include such contents.
...
Apache projects cannot distribute any such components within their releases. However, if the component is only needed for optional features, a project can provide the user with instructions on how to obtain and install the non-included work. Optional means that the component is not required for standard use of the product or for the product to achieve a desirable level of quality.

Perhaps we can use JRadius? We simply can't (1) use it in a way which means Guacamole can't work without it and (2) we can't produce convenience binaries for it.
I think maybe we're fine after all...

Unfortunately, it looks like the metadata in Maven Central for that library is just wrong. Going to the TinyRadius project itself, they state LGPL, and LICENSE file in their source agrees...

Well, forget that...

We actually may not be hosed. Further reading in the ASF legal docs...

I saw this clause, but wasn't sure if there was something special regarding Guacamole since it actually is an ASF project.  But, it sounds like maybe we're okay because it is being used as an add-on component for Guacamole, not a core feature, and because we're simply distributing the binary form of it, not actually using any of the (L)GPL-licensed source code?  Are you comfortable moving forward with this, then, or do we need to ask someone else within ASF to get guidance on it?

... it sounds like maybe we're okay because it is being used as an add-on component for Guacamole, not a core feature

I agree.

... and because we're simply distributing the binary form of it, not actually using any of the (L)GPL-licensed source code?

Not quite. From those same legal docs again (emphasis added):

CAN APACHE PROJECTS DISTRIBUTE COMPONENTS UNDER PROHIBITED LICENSES?
Apache projects cannot distribute any such components. This means that no source code can be from Category X and that any convenience binaries produced may not include such contents. As with the previous question on platforms, the component can be relied on if the component's license terms do not affect the Apache product's licensing. For example, using a GPL'ed tool during the build is OK, however including GPL'ed source code is not.

So long as the license doesn't affect the rest of our source, it's OK to produce an optional component which depends on something under one of the prohibited licenses (the "Category X" licenses), but we can't distribute a binary containing that component.
I believe this means that:

It is allowed for us to produce this RADIUS extension for Guacamole, and to include the source code for it in the main codebase, because it is optional and does not bundle the Category X dependencies.
We will not be able to distribute a binary version of the RADIUS extension alongside the other extensions with each release, because such a binary version would indeed bundle the Category X dependency, and would be under more restrictive licensing than the Apache license.
We can document the use of the RADIUS extension as an supported feature of Guacamole, though will need to advise users that they must build the extension themselves.

Are you comfortable moving forward with this, then, or do we need to ask someone else within ASF to get guidance on it?

I'm comfortable with moving forward. The ASF docs seem pretty clear on what we can/can't do at this point, and it looks like we're definitely allowed to do this as long as the feature is optional and not distributed in a form under more restrictive licensing than the Apache license (no binaries).

Aha, I see.  So, we can go ahead and merge it in (once we decide it's ready for that), and provide people with instructions on building it, but, unlike the existing extensions, we won't have a ready-made JAR file on the Guacamole page to download.
For the build instructions, should that be part of the page in the manual, or should I create a README within the extension folder that describes how to build it?  Any other changes that need to take place to the code as it stands today to satisfy the licensing?
Beyond that, were you able to come up with a sufficient ... statement to remove those signature files from the extension, or some other way to work around that issue?

So, I fixed the signature issue using the  tag in the maven-dependency-plugin block in pom.xml.  Any other outstanding issues?  For documentation for building this, did you want that added to the manual page for this extension?

So, I fixed the signature issue using the tag in the maven-dependency-plugin block in pom.xml.

Great! Nice to see that giant commented-out block go away. :)

Any other outstanding issues?

I'll re-review.

For documentation for building this, did you want that added to the manual page for this extension?

Well, we do need documentation regarding configuring Guacamole for RADIUS using this extension. Since the binary form of that extension can't be distributed with the release, I'd say those instructions should cover building the extension, too. If the extension is part of the main guacamole-client build, then just referencing the chapter covering building Guacamole from source is probably enough (along with maybe a pointer to where the .jar can be found).

So, from what I can gather on the LEGAL-299 JIRA issue, it sounds like:

Including this source code is okay.
Including binaries is not.
Having the extension built by default from source is not okay.

Regarding the last item, we can remove the extension from the pom.xml file and either provide instructions on how to add it in if users want to build it, or, alternatively, allow users to build just the extension manually.  Building only the extension manually has always proved problematic for me due to the dependency on the guacamole-ext stuff - is there a good way to tell the pom.xml for the extension to go up the tree and build guacamole-ext if it cannot find it?

Regarding the last item, we can remove the extension from the pom.xml file and either provide instructions on how to add it in if users want to build it, or, alternatively, allow users to build just the extension manually.

Instructions for building that extension manually would probably be best, IMHO, rather than requiring users to make changes to the build files.
I'm not sure if the discussion on LEGAL-299 is saying that we cannot include the extension within the guacamole-client build. It's been clearly said that we must ensure the user has to manually intervene, but I'd think locating and copying the extension .jar into GUACAMOLE_HOME/extensions/ would qualify for that... I asked a followup question within the JIRA issue to hopefully clear up that point.

Building only the extension manually has always proved problematic for me due to the dependency on the guacamole-ext stuff - is there a good way to tell the pom.xml for the extension to go up the tree and build guacamole-ext if it cannot find it?

No, you will always need to build from the top of the tree for such cases. If the root level will not ultimately build the extension, then the only option would be to manually build guacamole-client (or just guacamole-ext) first, and then build the extension.
This will be substantially easier with a released copy of the source, as by that time guacamole-ext and other artifacts will already be present in Maven Central, and building the extension manually should just work.

I pinged on the LEGAL-299 issue to see if anyone had feedback on that.  I agree that a separate JAR file and requirement to manually install it should take care of any concerns about a default LGPL build, but we'll see what they have to say.
Looks like the common, ext, and common-js components are already in Maven, right?  So maybe building just the extension by itself manually will work out?

Yes.
The profiles suggestion on LEGAL-299 seems like a good option, too. As a proof of concept, I tried moving guacamole-example into a profile by modifying the main guacamole-client pom.xml, and it works pretty darn well:
diff --git a/pom.xml b/pom.xml
index 6862ca6..41058c4 100644
--- a/pom.xml
+++ b/pom.xml
@@ -55,11 +55,17 @@
         <module>extensions/guacamole-auth-ldap</module>
         <module>extensions/guacamole-auth-noauth</module>

-        <!-- Example web application using the Guacamole APIs -->
-        <module>doc/guacamole-example</module>
-
     </modules>

+    <profiles>
+        <profile>
+            <id>examples</id>
+            <modules>
+                <module>doc/guacamole-example</module>
+            </modules>
+        </profile>
+    </profiles>
+
     <build>
         <plugins>

With the above, the default guacamole-client build contains only:
[INFO] Reactor Build Order:
[INFO]
[INFO] guacamole-common
[INFO] guacamole-ext
[INFO] guacamole-common-js
[INFO] guacamole
[INFO] guacamole-auth-duo
[INFO] guacamole-auth-header
[INFO] guacamole-auth-jdbc
[INFO] guacamole-auth-jdbc-base
[INFO] guacamole-auth-jdbc-mysql
[INFO] guacamole-auth-jdbc-postgresql
[INFO] guacamole-auth-jdbc-dist
[INFO] guacamole-auth-ldap
[INFO] guacamole-auth-noauth
[INFO] guacamole-client

If run with -Pexamples, however, the build becomes:
[INFO] Reactor Build Order:
[INFO]
[INFO] guacamole-common
[INFO] guacamole-ext
[INFO] guacamole-common-js
[INFO] guacamole
[INFO] guacamole-auth-duo
[INFO] guacamole-auth-header
[INFO] guacamole-auth-jdbc
[INFO] guacamole-auth-jdbc-base
[INFO] guacamole-auth-jdbc-mysql
[INFO] guacamole-auth-jdbc-postgresql
[INFO] guacamole-auth-jdbc-dist
[INFO] guacamole-auth-ldap
[INFO] guacamole-auth-noauth
[INFO] guacamole-example
[INFO] guacamole-client

So we could indeed have some sort of lgpl-extensions profile which adds any extensions which bundle LGPL dependencies to the build.

So, I gave this suggestion a shot, and ended up with Apache RAT being unhappy about "Too many files with unapproved license" when building without specifying the new profile.  If I look at the target/rat.txt report, it seems to still be examining files within the extensions/guacamole-auth-radius directory.  Is there something I need to do to exclude this from being examined when that profile is not built?

Hm ... that's happening because the Apache RAT plugin normally includes only files which aren't associated with modules. When the RADIUS extension is excluded from the build, it's suddenly implicitly included in the RAT check.
I think you'll have to add another <exclude> entry for extensions/guacamole-auth-radius/**/* to the guacamole-client pom.xml, so that it's excluded from the top-level RAT check in all cases:
https://github.com/apache/incubator-guacamole-client/blob/79c66b00f16cc4cc2e4b79f475d5aaed9289a54f/pom.xml#L101-L105

Well, I got this working - took your suggestion and just excluded all of the extensions directories from the top-level Rat check.
But, this shouldn't be necessary.  According to the apache-rat documentation, there's an option, excludeSubProjects (http://creadur.apache.org/rat/apache-rat-plugin/rat-mojo.html#excludeSubProjects), and the default is (supposedly) true, so that a top-level call to apache-rat will not descend into other projects.  According to Maven documentation, sub-projects are defined in the top-level pom.xml using the  tag, so, as far as I can tell, the top-level apache-rat plugin in guacamole client should not be checking all of the extensions and even all of the guacamole-common, guacamole-ext, etc., stuff - basically anything defined in a module section.  Even if I set the option explicitly in pom.xml, it does not seem to prevent RAT from descending into "sub-projects," so either the option doesn't work as advertised, or sub-projects are defined differently than the module tags.
Because each of the extensions already has the check I went ahead and excluded all of the extensions from the top level.  I can exclude just the radius extension if you think that's better, it just seemed a little more generic to just exclude them all.

Just pinging back on this issue to see if there's any further guidance on the proper way to use the RAT plugin per my previous comment.
Also, any additional concerns for this now that we've create a separate build profile?

Ping...any progress on testing this?

Ping...any testing progress here?

Ping.

Eep.
OK - reviewing now.

So, I've moved at least one block of code in the AuthenticationProviderService.java to its own function.  Let me know if this is the kind of thing you have in mind, and if there are any specific areas I should focus on.  I'm combing through it to try to spot things that could easily be pulled out into their own chunks - seems like I either get something too large (almost the entire authenticateUser function) or too small (2-3 lines of code) and have trouble identifying blocks of just the right size to split out.  I'll keep looking...

Made several more tweaks and then one substantial reorganization of the code - I reorganized the code in authenticateUser a little bit, which removed some duplicate code and made it a little more efficient.  And hopefully a little easier to follow.  Let me know if that looks better or if I should roll back that commit, and if there are other specific areas that need some attention.

Okay, so I have one other bug in the current code that I need a little help cleaning up.  Currently, if you log in to RADIUS, get a challenge, and put in the wrong value for the challenge, you cannot actually log in until you reload the page completely.  It seems like what is probably happening is that the parameters for the challenge and the state are not getting cleared out, so when you try to authenticate, again, it's trying the challenge/response piece rather than starting all over at the beginning with the initial authentication (even though the initial username/password dialog is displayed).  Is there something I need to do, either in Java or in the AngularJS code to properly clear these parameters out?

@necouchman
now the redirect_url is config in guacamole.properties, and when user login successfuully, sysytem always redirect to the guacamole home page; but it is not convenient. the best way is that when login susccssfully, system auto redirect to the url which user access before.  i hope you can improve it.

now the redirect_url is config in guacamole.properties, and when user login successfuully, sysytem always redirect to the guacamole home page; but it is not convenient. the best way is that when login susccssfully, system auto redirect to the url which user access before. i hope you can improve it.

I believe you're talking about the CAS module, not the RADIUS module, and I believe you've already posted this feedback on both the CAS JIRA issue and the CAS PR.

Okay, so I have one other bug in the current code that I need a little help cleaning up. Currently, if you log in to Guacamole with RADIUS credentials, get a challenge, and put in the wrong value for the challenge, you cannot actually log in until you reload the page completely. It seems like what is probably happening is that the parameters for the challenge and the state are not getting cleared out, so when you try to authenticate, again, it's trying the challenge/response piece rather than starting all over at the beginning with the initial authentication (even though the initial username/password dialog is displayed). Is there something I need to do, either in Java or in the AngularJS code to properly clear these parameters out?

@mike-jumper Any insight here?

@necouchman I'm not very familiar with RADIUS, but could your issue be related to the state property? When the authentication fails, should a new state be generated for the challenge? It seems easy enough to check with chrome dev tools or similar that the value the user types in is being sent to the server correctly.

@jmuehlner Thanks for the response.  Yes, it is definitely related to the state property - sorry to be so vague about that, but I'm struggling with the proper way in either the AngularJS code or the Java code to clear that out after a failed login is detected.  I'm looking for a little hint/direction/help on the proper way to clear out the existing authentication attributes - including the hidden state one - after a failed logon attempt.
Thanks!

So, looking at https://github.com/apache/incubator-guacamole-client/blob/1c0ee41d0ecd5bc4a3550804b74b73b901e074c2/guacamole/src/main/webapp/app/login/directives/login.js, it looks like throwing the INVALID_CREDENTIALS error will only reset the password fields. It sounds like you might want to modify this so that you can also clear hidden fields?
You'll probably also want to specify the state field when throwing GuacamoleInvalidCredentialsException  instead of using `CredentialsInfo.USERNAME_PASSWORD.

You'll probably also want to specify the state field when throwing GuacamoleInvalidCredentialsException instead of using `CredentialsInfo.USERNAME_PASSWORD.

Thanks, James - I'll give that a go and see what happens!

So, looking at https://github.com/apache/incubator-guacamole-client/blob/1c0ee41d0ecd5bc4a3550804b74b73b901e074c2/guacamole/src/main/webapp/app/login/directives/login.js, it looks like throwing the INVALID_CREDENTIALS error will only reset the password fields. It sounds like you might want to modify this so that you can also clear hidden fields?

So, interestingly, during the RADIUS challenge/response, this block of code does not get called.  I'm not sure if it's because of the route change in the AngularJS app?  Maybe the indexController.js code is more applicable??

So what's actually clearing out the fields then? I don't see any other code handling that error.

So what's actually clearing out the fields...

Nothing - they don't get cleared.

@jmuehlner @mike-jumper Any additional insight on this??

Ping @mike-jumper @jmuehlner

Going to try to dive back into this.

Going to try to dive back into this.

Yeah, I'm working on it, again, too, and I'm now running into the issue where the lack of user context is causing a 404 error that is now blocking authentication from occurring successfully.  So, trying to track that down without creating an empty user context.  If you have any insight on that, or on clearing out the state field during a failure, I'd be grateful for it...I'll continue to search for the bug...

Depending on what's happening, 404 may well be the correct response. Where are you seeing the 404 and how is it blocking authentication?

So, here's my basic methodology:

Enable RADIUS extension by copying to the extensions/ folder, and also ensure it's the first one in the layered setup.
Navigate to Guacamole page.  I see the POST to the api/tokens endpoint that results in a 403, which triggers the Guacamole login.
Enter valid RADIUS credentials and click Login.
I'm doing 2FA with RADIUS at the moment (*), so I get a 403 from the POST to api/tokens with INSUFFICIENT_CREDENTIALS, and the prompt for additional credentials.
I enter the OTP from Google Authenticator, and click Continue.  I see the POST to api/tokens and the 200 return code indicating a successful login.
I then see a api/tokens DELETE operation which results in a 404 (Token Not Found) error, which is normal.
Finally, there's a POST to api/tokens with the token value that was just obtained, and this is the one that results in the 404 error and everything stops.  The response of that 404 error is "Session not associated with authentication provider radius."

This happens whether I use 2FA with this module or not - if I turn off 2FA in RADIUS, it still fails, stopping at the 404 error.

A couple of additional notes:

RADIUS authentication, with or without 2FA, is succeeding - the RADIUS server logs show this, along with the Tomcat log output.
Other modules, like the CAS module, also get this 404 error, but don't seem to stop in their tracks when this happens, so I'm guessing it's something specific to the AngularJS stuff in this module that probably isn't handling that 404 response quite right.  I know we fixed the issue with it for the Settings/Preferences area, but maybe there's something it's hitting in the RADIUS code on the client-side that should be handling this 404 differently but is just killing the login process.

Yeah, I think some recent change is causing some issues with the 404 errors being thrown by the api/tokens endpoint - several of my extensions, after rebasing them on the latest apache master repository, are breaking in various places.  CAS manages to make it past the login to the home screen, but as soon as I try to do anything - like go to Settings - it just breaks.
Went back and built cleanly from apache:master and confirmed that the CAS module is broken there, too.  Should have some time to triage it tomorrow and figure out if it was a recent commit that broke things and track it down.

So, I've narrowed it down to changes introduced in the GUACAMOLE-364 PR (#184).  I'm not sure what exactly within that set of commits is causing it, but if I checkout to a point prior to that merge commit and build, the CAS extension behaves correctly.  If I include that merge commit it breaks.  I'll continue to see if I can track down the exact code causing the issue, but looks like maybe something that was added for event listeners is causing problems for extensions that do not have any UserContext.

Opened JIRA issue 412 on this regression.

So, getting back to the remaining issue, here - failed logins do not clear out either the password or the RADIUS state field - I've tracked down a little further what's going on.  The code that James mentioned in the login.js directive loops through the $scope.remainingFields variable and checks the fields in that array.  At this stage in the login, the only two fields in the $scope.remainingFields array are guac-radius-challenge-response and guac-radius-state.  The password field is not in this array, even though it gets tracked through in the enteredValues array.
In a failure situation in RADIUS, both the password field and the radius state field need to be cleared out.  I'm not sure that code belongs in the login.js file, since it is extension-specific, so I'm guessing there's somewhere in the RADIUS module that this code needs to go.  I'll keep tinkering with it, but I'm not certain off the top of my head what that would look like in the extension.

Ping @mike-jumper - aside from getting JIRA issue 412 fixed so that this starts working, again, any further ideas/feedback?

Okay @mike-jumper and @jmuehlner, getting back to this after that little rabbit hole resolving the regression.  So, still having issues getting fields to clear out properly when there's an authentication failure in the challenge/response part of authentication.  I've attempted to modify the login code that clears the fields ([1]) slightly such that it clears anything that is not a username field.  This causes the challenge and state fields to get cleared, but this itself is a problem since they are still there, just empty, which causes them to be passed on to RADIUS as empty values, which still causes authentication to fail.  I can check in the code for an empty challengeResponse field ([2]), in addition to null, but this doesn't quite seem right - it seems like I need some way to actually delete the fields altogether upon failure, and I'm having trouble figuring out how to do that.
I'm not sure if the authentication failure is broadcast in AngularJS in such a way that I could listen for that event inside the RADIUS code and then remove objects when that happens?
[1] - https://github.com/apache/incubator-guacamole-client/blob/ff2bd3d4f8c24dda68ada899ea52288cb432e15d/guacamole/src/main/webapp/app/login/directives/login.js#L175
[2] - https://github.com/necouchman/incubator-guacamole-client/blob/168c2daa01fcdbeca5d0762f504435eeb026f2f4/extensions/guacamole-auth-radius/src/main/java/org/apache/guacamole/auth/radius/AuthenticationProviderService.java#L152

FWIW: I don't think this is a problem at all. You would never want to send an empty / null challengeResponse field to radius anyways.
 I can check in the code for an empty challengeResponse field ([2]), in addition to null, but this doesn't quite seem right

FWIW: I don't think this is a problem at all. You would never want to send an empty / null challengeResponse field to radius anyways.

This is true, specific to RADIUS, but may not be true of all of the possible fields that could be sent.  If I'm going to modify the base Guacamole code to handle this, I need to do it in a generic sort of a way that transparently handles whatever fields from whatever authentication providers may be present.  If I'm going to do something specific to RADIUS, then it needs to be handled inside the RADIUS extension (which I haven't figured out a good way to do).  So, that's my current predicament - if you have any suggestions/pointers, I'll gladly accept them.  This is soooooooo close to being done!!


Parallel run fails with TypeError: undefined is not a function

To be able to run firefox tests updated configuration to use selenium driver 2.46.0 like this:
"server_path": "./node_modules/testarmada-magellan-nightwatch/node_modules/selenium-server/lib/runner/selenium-server-standalone-2.46.0.jar"
Chrome only => all tests pass
Firefox only => walmart-shirt.js fails, the rest pass.
Chrome,Firefox parallel fails with the following error:
λ "./node_modules/.bin/magellan" --browser=chrome,firefox --bail_fast
...
(1 / 3) <-- Worker 1 FAIL  tests/github.js @chrome,firefox
(2 / 3) <-- Worker 3 FAIL  tests/walmart-shirt.js @chrome,firefox
(3 / 3) <-- Worker 2 FAIL  tests/walmart-book.js @chrome,firefox
...
nightwatch-magellan has found nightwatch configuration at  C:\Users\ASunar\boilerplate\temp\build-magellan-13e9e9364_24ccb1041__temp_assets\nightwatch.json
chrome   TypeError: undefined is not a function
at emitStartedTest (C:\Users\ASunar\boilerplate\node_modules\testarmada-magellan-nightwatch\lib\base-test-class.js:70:13)
at Object.MagellanBaseTest.beforeEach (C:\Users\ASunar\boilerplate\node_modules\testarmada-magellan-nightwatch\lib\base-test-class.js:144:7)
at TestSuite. (C:\Users\ASunar\boilerplate\node_modules\nightwatch\lib\runner\testsuite.js:90:18)
at TestSuite.makePromise (C:\Users\ASunar\boilerplate\node_modules\nightwatch\lib\runner\testsuite.js:384:8)
at Object.beforeEach (C:\Users\ASunar\boilerplate\node_modules\nightwatch\lib\runner\testsuite.js:88:21)
at TestSuite.beforeEach (C:\Users\ASunar\boilerplate\node_modules\nightwatch\lib\runner\testsuite.js:323:21)
at TestCase.run (C:\Users\ASunar\boilerplate\node_modules\nightwatch\lib\runner\testcase.js:47:6)
at TestSuite.runTestCase (C:\Users\ASunar\boilerplate\node_modules\nightwatch\lib\runner\testsuite.js:284:20)
at TestSuite.runNextTestCase (C:\Users\ASunar\boilerplate\node_modules\nightwatch\lib\runner\testsuite.js:272:21)
at C:\Users\ASunar\boilerplate\node_modules\nightwatch\lib\runner\testsuite.js:220:19
http://www.screencast.com/t/H9Z0SguP

@asunar thanks for this -- taking a look

Thanks for reporting! The above error happens because we were treating --browser and --browsers differently. I've fixed it so that you can supply a list or a single browser to both and Magellan will accept either form.
Try magellan 1.5.18, now published to npm (boilerplate project updated also).


BAU Stripe refund handler sets transfer id for gateway transaction

We currently set the ID of the refund against the platform for the
refund gateway_transaction_id. The actual refund relative to the
Connect account is the transfer from the Connect account to the
platform.
Store this ID so we can use to relate refund transactions and GOV.UK Pay
refunds during reconcilation.
See PP-6266

Superseded by https://github.com/alphagov/pay-connector/pull/2329


Problem with custom libraries

When using custom libraries folder, the package foreach is installed fine but when running generate.R using Shiny the following error occurs:
Package ‘foreach’ version 1.4.4 cannot be unloaded:
 Error in unloadNamespace(package) : namespace ‘foreach’ is imported by ‘caret’ so cannot be unloaded

Problem with packages is fixed by adding loading foreach and inerators libraries in utils.R.
Next problem:
When running generate.R:
Subsetting data to match the given training genes...
Data subset. Generating models...
Error: `data` and `reference` should be factors with the same levels.

Files ada_model.rds. ada_matrix.txt, ada_summary.txt and ada_testing.tsv are generated and not empty but then this error occurs.

Fixed by adding
cm <- caret::confusionMatrix(as.factor(predictions), as.factor(validation_set[["status"]]), positive = "1")
caret version 79 changes:
"when creating a confusion matrix using two vectors, the input data are now required to be factors with the same levels"


Pilosa server ignores unknown query arguments

Expected behavior
If an unknown query argument passed, Pilosa server should return an error.
Actual behavior
Pilosa server ignores the query argument
Steps to reproduce the behavior
curl -XPOST 'localhost:15000/query?db=sample&not_exists=true' -d 'Bitmap(id=1, frame="foo")'

Information about your environment (OS/architecture, CPU, RAM, cluster/solo, configuration, etc.)
For feature requests, please provide the following:
Description
Success criteria (What criteria will consider this ticket closeable?)

Closing this, since we don't use query arguments anymore.

Reopening this issue, since I was wrong: passing unknown query arguments raises no errors.


Update index.md

[x] I have read freeCodeCamp's contribution guidelines.
[ ] My pull request has a descriptive title (not a vague title like Update index.md)
[ ] My pull request targets the master branch of freeCodeCamp.
[ ] None of my changes are plagiarized from another source without proper attribution.
[ ] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Plagarism is not allowed here.
http://ngcm.soton.ac.uk/blog/2016-11-29/why-julia.html


Fix and test headers::v6_ext

Exposes the v6_ext module to headers
Tests the overlay of the SR extension header onto a raw buffer
Spitballs a way to access the segments beyond the end of the struct

@drunkirishcoder I think I need to spend some time renaming things. The purpose of the Ipv6ExtHeader is so that we can skip extension headers that we don't care about, but eventually we would probably want to have support for the other known extension headers.

@drunkirishcoder updated for you dawg.

I'm good with this. :shipit:


Topmenu layout is broken

The page title Dwayne Hinterlang does not align with the social media links.

This bug is currently only present on FireFox Nightly
Closing due to existing on a beta browser only


'Remove from Library' not available in current song menu

Checklist:

[ X] I have checked that there are no issues with similar or the same content
YOU SHOULD CHECK CLOSED ISSUES ASWELL

[X ] I have checked the FAQ (https://github.com/MarshallOfSound/Google-Play-Music-Desktop-Player-UNOFFICIAL-/wiki/FAQ) and the answer I am looking for is not there

[X ] I have double checked and can reproduce the issue

OS:
Windows 10
GPMDP Version:
I'm sorry, but I cannot find where the version number is. I'm current as of 2/27/19.
Issue Descriptions:
'Remove from Library' does not seem to be available from the current song menu. Once I remove it an alternative way, the option to 'Add to Library' comes up. Thought that was strange.

Steps to Reproduce:
I had a song added to my library (because I add albums at a time, but then remove songs that get old or that I don't like), and it should be in the current song menu, but it doesn't seem to be. See screen shot. in issue description.
On this other song, this is what it looks like when the song is not in your library:

This UX comes straight from Google, we only add buttons to that menu, we don't remove any

This is actually incorrect @MarshallOfSound, we do hide a few buttons in that menu based on position, which does break this. I attempted a fix but never got around to completing it.

Re-opening as per above
🙇 thanks @jostrander for pointing that out


Layout/IndentationWidth misses unindented blocks

Expected behavior
The Layout/IndentationWidth cop should apply to all the else blocks.
Actual behavior
In some cases, the cop is not applied [to else blocks].
Steps to reproduce the problem
See the following code:
mycondition = rand >= 0.5

if mycondition
puts 'caught (if)'
else
puts 'caught (else)'
end

if mycondition
# comment, no code
else
puts 'not caught (else)'
end

if mycondition # nothing in the if block
else
puts 'not caught (else)'
end

RuboCop version
$ rubocop -v
0.59.2

Proposed fix in #6548.


[admin-api] Not accept Get requests with explicit content type

Kong 0.8.2
Minor issue. Should skip the content-type header for GET requests.
Request
curl -H "Content-Type: application/json" -X GET http://kong:8001/apis
Response
{"message":"Cannot parse JSON body"}

So... is this actually a bug? you're marking it as a json body, yet not providing it. I think this behaviour is quite ok actually.

I'm not sure it's a bug - it's bad input - but at the same time for GET requests you could always safely ignore "Content-Type"; GET requests can include the "Accepts" header instead for content negotiation

Yes, for me it isn't a bug but however it isn't the best user experience. In an REST-like API I expect that a GET request hasn't a body so it's useless check and block the request.

Right. Then the Kong admin api should ignore the body except for PATCH, PUT and POST methods.

fixed in PR #1285, scheduled for 0.9

fixed in #1359, will be in 0.9


White screen when I restart the device

My Ionic 3 app, when is set as launcher, does not start if I restart the device.
The device starts, shows the lock screen, the app tries to start but it shows only a white screen. Chrome's inspector doesn't report anything.
If I disable the lock screen using the Developers options, it starts normally.
I'm testing on a Huawei MediaPad T5

same here, no solution yet?


feat: increase code coverage for retryHandlerFactory [In Progress]

Checklist
🚨 Please review this repository's contribution guidelines.

[ ] I've read and agree to the project's contribution guidelines.
[ ] I'm requesting to pull a topic/feature/bugfix branch.
[ ] I checked that my code additions will pass code linting checks and unit tests.
[ ] I updated unit and integration tests (if applicable).
[ ] I'm ready to notify the team of this contribution.

Description
What does this change do and why?
Increase code coverage by adding tests for RetryHandlerFactory
Fixes https://github.com/intuit/RWebPulse/issues/33
[Link to JIRA]
Thank you!

Closing this PR, will raise a fresh updated one separately.


File comparison front end

Was the addition of the csv files to the repo intentional? If not, please remove them from the CL. If you'd like to keep them in your local repo you could add them to your .gitignore.

Done


Build every model object as separate mesh

Hello! How are you?
My question is: Is there any way to compare the map, but instead of merging everything into a single model, does it create a mesh instance for each object on the map? I think it would be better to use occlusion occluder and etc.
Example:

Instead of merging all these cubes into a single mesh instance, it creates multiple nodes for each cube.

if you group brushes together in trenchboom using func_group then these will be built as separate meshes. You can also define how each entity type is merged or not in the Entity Fgd file by changing it's "Spawn Type".


Not recognizing public domain: rns.tn

-- PublicSuffix::DomainNotAllowed : `rns.tn' is not allowed according to Registry policy
As far as we can tell, it seems like rns.tn belongs to a tunesian ministry.

The suffix is restricted to registrations at the third level domain.
https://github.com/weppos/publicsuffix-ruby/blob/master/data/definitions.txt#L6053

I confirm the PSL definition is correct. According to this document that's a reserved suffix and only third level domains are allowed.


A humanized ImportError message in manage.py

I've been teaching Django for several years in classes like this.
Again and again I've seen newbies flounder when they receive this error after running manage.py.
 % python manage.py
Traceback (most recent call last):
  File "manage.py", line 7, in <module>
    from django.core.management import execute_from_command_line
ImportError: No module named django.core.management

The root cause is almost always simple, like forgetting install Django with pip or neglecting to "activate" a virtual environment. But the Python jargon doesn't do much to help people new to our world connect the dots.
My proposal: Catch that error and print out a more verbose message that explains to the user exactly what's wrong. Here's my draft. I'd welcome any changes, but I think something along these lines could better welcome new people into Django.
 % python manage.py
Traceback (most recent call last):
  File "manage.py", line 11, in <module>
    installed and available on your PATH variable?")
ImportError: Django could not be imported. Are you sure it is installed and available on your PATH variable?

Do you know of any projects that do something similar? I guess I'm a bit skeptical of doing something non-standard. Newbies will need to learn how to interpret import errors one way or another.

In the end this kind of thing is, of course, subjective. However, when introduced strategically I believe it can help provide a handrail for new users.
Django itself is an example of the practice in action. Take a look at the root imports for the django.contrib.gis backend right here. By givings a couple simple clues for new users, you can help them get a foothold more quickly.
I don't have a sweeping survey of users, but my experience teaching Django to dozens of Python newbies is that this particular error frequently deters people from getting started. I'm open to alternative ideas, but I'm confident something a little more literate would make a significant difference. I also don't see what it would help since the same underlying error would be called regardless.

+1. Even if you know Python, the existing error seems to obfuscate the problem for anyone who doesn't know django's internal structure. (The fact that the first import is django.core.management doesn't seem intuitively obvious until you know how manage.py interacts with the framework...)

Grunt throws Error, global grunt not found. Have you tried installing grunt globally? npm install -g grunt (sic)
+1 to this PR

+1 A good error message teaches. It can make the error not only understandable but less likely to be repeated.
As someone first exposed to Django in a @palewire class, this error is an obfuscating barrier both at initial exposure to the framework and again later working on one's own. It simply isn't descriptive of the issue in a way a newbie will understand how to fix.

How about:
raise ImportError(
    "Couldn't import Django. Are you sure it's installed and available "
    "on your PATH environment variable? Did you forget to activate a "
    "virtual environment?"
)

I love it.

merged in 724a279849a5cd09cdb5ef201fe6958a4c26fe73, thanks.

See the discussion on the commit: https://github.com/django/django/commit/724a279849a5cd09cdb5ef201fe6958a4c26fe73
Reopening to (at least) change PATH to PYTHONPATH.

Posted to django-developers to get more feedback.

Opened a ticket: https://code.djangoproject.com/ticket/26484#ticket
and a new PR: https://github.com/django/django/pull/6438

..?
raise ImportError(
"Couldn't import Django. Are you sure it's installed and available "
"on your PATH environment variable? Did you forget to activate a "
"virtual environment?"
)


Add download button for sankey and sunburst in module

Add download button for sankey and sunburst in module

tempFile <- tempfile(fileext = ".html")

dummyData <- data.frame(
  path = c("A+Z", "B", "C", "A-B", "B-C", "D+Z", "E", "F", "D-E", "D-E-F"),
  freq = c(25, 25, 25, 12, 13, 25, 25, 25, 12, 13),
  sex = rep("all", 10),
  age = rep("all", 10),
  index_year = c(rep("all", 5), rep("2020", 5))
)

s <- TreatmentPatterns::createSunburstPlot(dummyData, groupCombinations = FALSE)

htmlwidgets::saveWidget(s, file = tempFile)

webshot2::webshot(url = file.path("file:///", tempFile), file = "./s.png", )


Don't inject content script into HTML if request method is POST

It may break some sites.
See https://github.com/AdguardTeam/AdguardFilters/issues/7140

Normal (HTML form) POST requests should be filtered, so we should not inject only if RequestType is XMLHttpRequest.

Another solution is possible without patching code.


Add three new imaging assays + one device

Resolves #1290 - IDs from the OBI Term ID Reservation sheet.

ID
Label

OBI:0002985
magnetic resonance imaging assay

OBI:0002986
computed   tomography imaging assay

OBI:0002987
positron   emission tomography imaging assay

"MRI scanner" and "magnetic resonance imaging scanner" have been added as synonyms to "NMR instrument".

Discussed on the 2021-02-08 call. Need to generalize the textual definitions of the three assays beyond "body": "An imaging assay that uses ... to produce information about the interior structure and composition of an input material entity." @bpeters42?

I've generalized the definitions for the three new assays:
magnetic resonance imaging assay

An imaging assay in which nuclear magnetic resonance is used to produce information about the interior structure and composition of an input material entity.

computed tomography imaging assay

An imaging assay that uses a series of X-ray images to produce information about the interior structure and composition of an input material entity.

positron emission tomography imaging assay

An imaging assay in which positron-emitting radionuclides are used to visualize functional processes of an input material entity.


Realtime - Unable to communicate with host when running client within WSL

Bug report

[x] I confirm this is a bug with Supabase, not with my own application.
[x] I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug
It seems that the supabase client is unable to communicate with the realtime wss api beyond initial connection. Furthermore, there is no provided error as to why the issue is occurring via status CHANNEL_ERROR.
NOTE: This is for a backend application, not front-end.
I was able to successfully connect to the realtime api and receive updates by doing the following below outside of the package by utilizing wscat. This shows that my WSL configuration is valid and able to communicate normally with the API.
Initial command.
wscat --connect "wss://<project_id>.supabase.co/realtime/v1/websocket?apikey=<apikey>&vsn=1.0.0"
Sent message(s)
{
  "topic": "realtime:custom-all-channel",
  "event": "phx_join",
  "payload": {
    "config": {
      "broadcast": {
        "ack": false,
        "self": false
      },
      "presence": {
        "key": ""
      },
      "postgres_changes": [
        {
          "event": "*",
          "schema": "public",
          "table": "<table_here>"
        }
      ]
    },
    "access_token": "<api_key>"
  },
  "ref": "1",
  "join_ref": "1"
}

To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:
Create a basic nodejs & supabase application within WSL
Try connecting to the realtime api
Expected behavior
Connection and successful subscription to realtime events.
Screenshots
If applicable, add screenshots to help explain your problem.
System information

OS: Windows - 10.0.22621 Build 22621
WSL 2 - Ubuntu 22.04.3 LTS
Version of supabase-js: 2.33.2
Version of Node.js: v20.6.1
Version of Bun 1.0.2 (additional tests were done with this before posting)

Additional context
Code being used to test.
import { REALTIME_SUBSCRIBE_STATES, createClient } from '@supabase/supabase-js'

const SUPABASE_REALTIME_URL = 'https://<project_id>.supabase.co'
const SUPABASE_KEY = 'public-anon-key'
const supabase = createClient(SUPABASE_REALTIME_URL, SUPABASE_KEY, {
    realtime: {
        params: {
            eventsPerSecond: 1000,
        },
    },
})

const channel = supabase.channel('custom-all-channel')
    .on(
        'postgres_changes',
        { event: '*', schema: 'public', table: '<table_name>' },
        (payload) => {
            console.log('Change received!', payload)
        },
    )

channel.subscribe((status: `${REALTIME_SUBSCRIBE_STATES}`, err) => {
    if (status === REALTIME_SUBSCRIBE_STATES.SUBSCRIBED)
        console.log('Subscribed to channel!')

    if (status === REALTIME_SUBSCRIBE_STATES.CHANNEL_ERROR)
        // # err returns undefined?!?!
        console.log('Error subscribing to channel!', err)
})

Facing the same issue for one of my projects but not for the other.
Also same with err being undefined https://github.com/orgs/supabase/discussions/19263
I also opened a ticket as well

@Zendrex could you please open a ticket? That way I might be able to unblock your project.
We might have an issue when we're creating some of the data on our side to connect to the project database. Already checking with the relevant teams 👀

Hi. It's probably not fully related to the original issue, but I had this same err = undefined issue on a self-hosted instance. Basically, it happens when supabase is unreachable (mainly because I did not port-forward, on purpose).
I kind of was expecting some sort of an error message instead, so there might be something to investigate there.
This is happening with the latest release for us, and I could not find where the problem would be, as the callback seems called correctly in the source code.

We actually found a bug related with this where an Invalid JWT is not being reported properly in our JS client and we're still working in checking if this is something at the server side or client side.
The connection issue @groud mentioned might also be related with this issue of lack of proper error reporting on subscribe as such I will keep this issue open as we work on it


Remove need to acknowledge settings changes.

Resolves #88.
/cc @Kriechi

LGTM! Thanks very much!


[New Port Request] < QSimpleUpdater >

Library name: QSimpleUpdater
Library description: QSimpleUpdater is an implementation of an auto-updating system to be used with Qt projects. It allows you to easily check for updates, download them and install them. Additionally, the QSimpleUpdater allows you to check for updates for different "modules" of your application.
Source repository URL: https://github.com/alex-spataru/QSimpleUpdater

If you wish to add this port in the future, you can reopen this issue, but we're closing it for now.

Hope it will be added

If you wish to add this port in the future, you can reopen this issue, but we're closing it for now.


Raise test coverage to 100%

closes hoodiehq/camp#4
I'm putting the PR already so you can see my progress and to be able to discuss certain steps along the way. :)

looks great so far 👍

@hoodiehq/maintainers : Done with this - test coverage is now at :100: !
I took some notes and questions about some things that caught my eye during implementing the tests that I would like to share and hear your opinions. Sorry in advance for the HUGE amount of text following. :D
unit/server/index-test.js
Since I couldn't reach 100% test coverage with integration tests here I created a unit-test-file for the server. As it wasn't in the scope of this pr, this unit-test-file now only contains one test - the error case. It would maybe be nicer if it actually would also cover the whole server.
unit/logger-test.js & server/plugins/logger.js
I realized quickly that the module itself is not very easy testable. It would be easier if the actual logging-method was exposed from the module or extracted into a submodule.
As I see it, the logger.js has 3 responsibilities:

Register the plugin as such with the server
Create the “GoodCase”-Class as a stream-logger
Create the actual log-function for the different events

It would be way nicer (and better testable) to split those 3 responsibilities into three different files. If you agree we could open an issue for that and I would try to create a PR.
client/index.js

I had to refactor the handler in order to make it testable: So far, the promise was resolved BEFORE continuing logic. As the resolved promise is the only way to know from the "outside" when the test i done, I wasn't able to test what fs does. Instead of having return statements, i replaced the whole thing with an if-else-cascade.

Something similar to logger: It would be way easier to test if the actual handler-function was exposed or refactored into a different file. Right now I wasn’t able test if fs actually writes to the correct path  (or only with lots of code duplication). If the Handler-Function could be created with all those paths as options-object, it would be easier. What do you think?

handle-404-test.js
When sending a request with accept: text/html to the url /hoodie/unkown, the server responds with JSON. Maybe there should be a 404.html page?
server/plugins/client/bundle.js
When browserify.bundle runs into an error, the error is thrown instead of passed to the callback – effectively killing the server. Shouldn’t this be handled more gracefully by invoking an error-callback instead?

@gr2m haha 'thanks for the flowers' - as we say in germany. It was my pleasure and I'm happy if you like it. :)
I made the changes you requested, let me know if there is anything else.

unit/server/index-test.js
Since I couldn't reach 100% test coverage with integration tests here I created a unit-test-file for the server. As it wasn't in the scope of this pr, this unit-test-file now only contains one test - the error case. It would maybe be nicer if it actually would also cover the whole server.

The error callbacks are often times hard to test. Other projects add a /* istanbul ignore next */ before the if (error) { ... }. I think using a unit test here is a good choice, creating an integration test that makes the registration of @hoodie/server fail would be hard to create, understand and maintain

unit/logger-test.js & server/plugins/logger.js
I realized quickly that the logger-module itself is not very easy testable. It would be easier if the actual logging-method was exposed from the module or extracted into a submodule.
As I see it, the logger.js has 3 responsibilities:

Register the plugin as such with the server
Create the “GoodCase”-Class as a stream-logger
Create the actual log-function for the different events

It would be way nicer (and better testable) to split those 3 responsibilities into three different files. If you agree we could open an issue for that and I would try to create a PR.

Yes, I agree! It’s a bin of a pain point we have in Hoodie right now, see also https://github.com/hoodiehq/camp/issues/35. I think it would be great if you could create a follow up issue for this, and mention #35, then we can work on it once we have #35 taken care of?

client/index.js

I had to refactor the handler in order to make it testable: So far, the promise was resolved BEFORE continuing logic. As the resolved promise is the only way to know from the "outside" when the test i done, I wasn't able to test what fs does. Instead of having return statements, i replaced the whole thing with an if-else-cascade.

👍

Something similar to logger: It would be way easier to test if the actual handler-function was exposed or refactored into a different file. Right now I wasn’t able test if fs actually writes to the correct path  (or only with lots of code duplication). If the Handler-Function could be created with all those paths as options-object, it would be easier. What do you think?

Hm I cannot follow 100%, but I love that you are thinking on how to make the code base better to test. Maybe you could create a follow up issue for it and start a pull request as a base of discussion?

handle-404-test.js
When sending a request with accept: text/html to the url /hoodie/unkown, the server responds with JSON. Maybe there should be a 404.html page?

Good idea 👍 I’d suggest we create a follow up issue as well, because having 100% test coverage is so awesome to have, I’d like to merge it asap and then iterate, if that’s okay with you?

server/plugins/client/bundle.js
When browserify.bundle runs into an error, the error is thrown instead of passed to the callback – effectively killing the server. Shouldn’t this be handled more gracefully by invoking an error-callback instead?

Good catch, yes! Well, ehm, let’s create a follow up issue as well?

Wow, great work, danke David! If you are okay with creating follow up issues, I’d merge your pull request in :)
Only a few minors, but if you are busy I can take care of them myself :)

Could you make sure that all files end with an empty line? You did it in test/unit/server/logger-test.js, but for example not in test/unit/server/index-test.js
Rebase your PR on top of master, reset your commits and commit

server/* with refactor: testability (or something like that, the refactor: prefix is significant
the rest with test: 100% test coverage

That’d be 💯

@gr2m : You are very welcome! :smiley:
So I squashed the commits a little and separated into one for the test-coverage and one for the refactoring. Line-Endings should be correct now too (the reason it was like that: in IntelliJ you actually have to put TWO empty lines at the end of a file in order to make it commit ONE empty line ending to git - that's super weird, I am going to open an Issue at jetbrains).
For all the other tasks I created issue #593 , #594 , #595 and #596 - as I already wrote in Slack I won't be able to do much this whole next week so I can not tackle them myself. Feel free to put them into the camp or to let it be grabbed by someone else here.

I’ve invited you to Hoodie’s Contributors team :) Welcome!
And are you on twitter by chance? We like giving new contributors a shoutout – only if you like of course

:) nice, thank you very much.
And of course, my twitter is @david_losert - thanks a lot! :+1:


sum a list of lists containing strings

General Question
Should sum on a list of lists containing strings work?
In the FAQ (item #60) sum is mentioned for combining lists of lists. I tried the example in the playground and it works. However, in my use case, I'm trying to flatten a list of lists that contain string values. My intuition says that it shouldn't matter what the type of items in the lists are however I get an error when trying this simple example:
result = sum([["a", "b"], ["c"]])

error:
unsupported operand type(s) for +: 'int' and 'list'

I looked at the documentation for the sum built-in and it mentions actually summing the values of integers but not the combining of lists so I'm unclear what the intent is.

Ok, that works, thank you @Peefy. It makes me wonder if this use case for sum deserves a different name (and documentation). My, admittedly Ruby Lang influenced, idiom for this would be flatten.


Testing updates

Miscellaneous testing related updates
Tasks

[x] In CI use main instead of master + fixed version. See https://github.com/coverallsapp/github-action/issues/201#issuecomment-2234228863
[x] Update Rubocop
[x] Update Rubocop version used by CodeClimate
[ ] Consider updating Rubocop todo

We are already using the highest available rubocop channel used by Codeclimate.
That channel is 1-56-3. See https://github.com/codeclimate/codeclimate-rubocop/branches/all?utf8=✓&query=channel%2Frubocop
So we're using a higher Rubocop locally -- 1.65.0 -- than in CI.


upgrade git-sync container tag v3.5.0

Currently, we use v3.2.2 as the dags.gitSync.image.tag.
Version v3.2.2 has known issues:

when running as pid=1 in container, that can cause failures
when data is corrupt, git-sync may attempt to remove the PVC mount (which will fail)

probably the cause of https://github.com/airflow-helm/charts/issues/518

We should update the default tag to v3.5.0.

Bumping for bot.

I have updated this issue to reference v3.4.0 in which a number of further issues have been fixed.

I have again updated this to reference the new git-sync v3.5.0.


Linked list draft in progress. E.J.O.M. 07/18/2020.

Linked list daft. E.J.O.M. 07/18/2020.

Yes :).


what about fragment

how to add fragment
i call
getSupportFragmentManager().beginTransaction().replace(R.id.container, new TabHomeFm()).commit()
that is error

Maybe your fragment doesn't use android.support.v4.app.Fragment?

I can add fragment, please check my codes:
.java document:
FragmentTransaction transaction = mFragmentManager.beginTransaction();
android.app.Fragment fragment =  new BnHomeFragment();
transaction.replace(R.id.content_bb, fragment).commit();
.xml document:
<android.support.design.widget.CoordinatorLayout
xmlns:android="http://schemas.android.com/apk/res/android"
android:id="@+id/myCoordinator"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:fitsSystemWindows="true">

</android.support.design.widget.CoordinatorLayout>

It looks like you are using normal fragments and trying to use supportFragmentManger with them.
I think you must replace this:
getSupportFragmentManager().beginTransaction().replace(R.id.container, new TabHomeFm()).commit();
for this:
getFragmentManager().beginTransaction().replace(R.id.container, new TabHomeFm()).commit();

@jml90 is right.
As this issue is not related to this library, I'm closing this one.


[SPARK-44352][CONNECT] Put back sameType and friends in DataType.

What changes were proposed in this pull request?
This PR moves back sameType and friends into DataType. Now that we have a conf system for SQL/API we can host them in there.
Why are the changes needed?
We want to retain compatibility with the existing DataType APIs. Also we need to eliminate the use of catalyst specific code in the DataType hierarchy.
Does this PR introduce any user-facing change?
No
How was this patch tested?
Existing tests.

cc @amaliujia


bump to 0.1.3

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

Project coverage is 82.77%. Comparing base (791b7b7) to head (d3c6944).
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #138      +/-   ##
==========================================
- Coverage   89.61%   82.77%   -6.84%
==========================================
  Files          25       25
  Lines        1492     1492
==========================================
- Hits         1337     1235     -102
- Misses        155      257     +102

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


Android APK D2D: Analyze Android APK to map app binaries with source code

An Android APK is a zip file that contains various compiled binaries, bytecode files (compiled from Java and JVM languages), XML manifests and UI files and a few other files. The d2d of an android app has a few steps that are common, like basic file mapping, or matching and would need go through these specific steps:

[x] Android APK D2D: Extract Android APK
[x] https://github.com/aboutcode-org/scancode.io/issues/1372
[x] https://github.com/aboutcode-org/scancode.io/issues/1373
[x] https://github.com/aboutcode-org/scancode.io/issues/1371

This is now completed. There are several improvement and refinements opportunities that are tracked in a follow up issue:

https://github.com/aboutcode-org/scancode.io/issues/1396


How to use GraphQL.RepoDB without Azure?

Is it possible to use GraphQL.RepoDB without Azure packages?

Yes absolutely! They don’t have any dependencies between each other.
The demo project is merely using that as an example that serves multiple purposes.
The Azure Function proxy library only enables HotChocolate to run within the context of Azure Functions v2 & V3.
The RepoDB extensions work with the Hot Chocolate resolvers to prove a facade and mapping implementation directly for RepoDB micro-orm and works with any deployment of Hot Chocolate (eg .Net Core Web App, Azure Functions, etc.).
I strongly recommend spending time to get a solid understanding of how HotChocolate v11 configuration/startup works.

Thank you, I will try to test this way. But will ask questions if have ;-)

Sure, but be sure to read the documentation provided by the HotChocolate core team and the Workshop!
The difference is that GraphQL.RepoDB makes it a lot easier to work without IQueryable and use of EF. And it does this inside the resovlver…
So anytime you would normally inject IResolverContext with GraphQL.RepoDB you have another option to now inject and easier to use facade…and Another helper that uses that to work more easily with RepoDB.
If any of this isn’t clear then it will be much easier to understand once you’ve got a grasp of GraphQL & HotChocolate fundamentals :-)

Ok, thank you. So what NuGet packages should I use in my ASP.NET Server when I need only HC without EF and without Azure functionality ?
Is this right minimal set:

GraphQL.PreProcessingExtension
GraphQL.RepoDb.SqlServer
?

Yes… all you need to install is: GraphQL.RepoDB, because it’s dependencies will automatically be installled by Nuget.


Add separate core location to deployment

WIth the introduction of scheduled uploads core dumps may accumulate so this issue is to track the creation of a separate PV and PVC for the storage of the cores.

Implemented in
https://github.com/IBM/core-dump-handler/commit/57ff29139bb61a8ae4b583ef963e34128c580c38
https://github.com/IBM/core-dump-handler/commit/8fa009ccbf188340472ec240dfc46815374aae8f


How to use 'exec_program' in FIPS???

When I want to build MSVC project of LuaJIT, I found the guide in msvcbuild.bat is
%LJCOMPILE% host\minilua.c
@if errorlevel 1 goto :BAD
%LJLINK% /out:minilua.exe minilua.obj
@if errorlevel 1 goto :BAD
if exist minilua.exe.manifest^
  %LJMT% -manifest minilua.exe.manifest -outputresource:minilua.exe

@set DASMFLAGS=-D WIN -D JIT -D FFI -D P64
@set LJARCH=x64
@minilua
@if errorlevel 8 goto :X64
@set DASC=vm_x86.dasc
@set DASMFLAGS=-D WIN -D JIT -D FFI
@set LJARCH=x86
@set LJCOMPILE=%LJCOMPILE% /arch:SSE2
:X64
@if "%1" neq "nogc64" goto :GC64
@shift
@set DASC=vm_x86.dasc
@set LJCOMPILE=%LJCOMPILE% /DLUAJIT_DISABLE_GC64
:GC64
minilua %DASM% -LN %DASMFLAGS% -o host\buildvm_arch.h %DASC%
@if errorlevel 1 goto :BAD

which means fips_begin_app(minilua cmdline) first and then execute it
minilua %DASM% -LN %DASMFLAGS% -o host\buildvm_arch.h %DASC%

In cmake, exec_program can do this, but I get this problem in FIPS
CMake Warning (dev) at LuaJIT/src/CMakeLists.txt:19:
  Syntax Warning in cmake code at column 19

  Argument not separated from preceding token by whitespace.
This warning is for project developers.  Use -Wno-dev to suppress it.

Process failed because: The system cannot find the file specified

build & execute, maybe FIPS doesn't support this?

Hmm, not sure what the cmake warning is about, this shouldn't be fips-specific though.
I'm not sure if exec_command is the right way to do this though, AFAIK this runs an executable while cmake processes the CMakeLists.txt files, not during the build  (see here: https://cmake.org/cmake/help/v3.17/command/exec_program.html).
Since the the executable is only created during a build there would be a chicken-egg-problem
I would probably use cmake's add_custom_command or add_custom_target in this situation:
https://cmake.org/cmake/help/latest/command/add_custom_command.html
https://cmake.org/cmake/help/latest/command/add_custom_target.html
These allow to run executables during the build process, the only thing you'd need to make sure is that the dependencies are set up properly, so that those custom commands are only running after the executable is built. These are all cmake features though, and should work the same with or without fips.


Update okhttp Library to Address CVE-2021-0341 and CVE-2023-3635

CVE-2021-0341 (okhttp):
Description: This vulnerability in OkHostnameVerifier.java could allow a certificate for the wrong domain to be accepted due to improperly used cryptography. This can lead to remote information disclosure without requiring additional execution privileges1.
Affected Versions: All versions of okhttp v3.x and v4.x are affected.
CVE-2023-3635 (okio):
Description: The GzipSource class does not handle exceptions properly when parsing a malformed gzip buffer. This can lead to a denial of service (DoS) when handling a crafted GZIP archive2.
Proposed Solution
Both issues can be solved by updating okhttp to 4.12.0
Steps to Reproduce
Run a vulnerability scanner (e.g., dependency-check, SonarQube) on any project that uses 3.2.2 version
Observe the reported vulnerabilities for okhttp and okio

I created a PR for this suggestion:
https://github.com/smartsheet/smartsheet-java-sdk/pull/114
Feedback and reviews are truly appreciated


Static image requests (GET request to a back-end API) does no have the Authorization Header

I am using password grant. Everything seems to work perfectly (which suggests that I have setup authenticators, authorizers and mixins correctly). However, I see that the static image requests, for the images embedded into html pages, the GET requests are coming with no Authorization Header.
How can this be fixed (I want to serve static content using the same Authorization as a the rest of the site).
Thanks.

You have to append the token to the image URL.
Please only open issues for actual bugs etc. though and refer to stackoverflow.com for questions.


fix(lambda): Set .status.atProvider during observe

Description of your changes

This sets status.atProvider during observe which is currently left empty.
Fixes #1281
I have:

[x] Read and followed Crossplane's contribution process.
[x] Run make reviewable test to ensure this PR is ready for review.

How has this code been tested
Manually

@haarchri can you take a look at this?

Thanks


No changes for CHANGELOG.rst

There is no changes in the file CHANGELOG.rst

I'm not sure what you're referring to. It seems to work fine for me https://github.com/feincms/feincms/blob/master/CHANGELOG.rst
Please reopen if the problem persists. Thanks!

I was referring to changes that were not included in that file. Right now I see it is okay. Thanks.


docs: volar Type-Checking, custom component name

hi @megasanjay and need add to docs this instructions)

and maybe need move docs to packages folder

I'll add that in the morning lol. I also prefer having the docs separate since it easier for me to handle everything in vercel


Discussion: Subscriptions

This project looks very good and I'd love to use it but I also need subscriptions.
Did you already have a rough idea on how to implement this? So I am not doing the same work twice.

Thanks! I have no idea how to implement subscriptions yet. My suggestion would be that you open up an RFC in discussions and outline your suggested approach and thinking, we can discuss the API and possibly work on the implementation. In terms of ETA (from my side) this should be up and running before the end of February, but I do need some help with implementation and WS support in Swift.

Thanks! I have no idea how to implement subscriptions yet. My suggestion would be that you open up an RFC in discussions and outline your suggested approach and thinking, we can discuss the API and possibly work on the implementation. In terms of ETA (from my side) this should be up and running before the end of February, but I do need some help with implementation and WS support in Swift.

Agreed, I didn't know what the best way was to contact you. Didn't know about discussions, will continue there.

Agreed, I didn't know what the best way was to contact you. Didn't know about discussions, will continue there.


Fix README with correct steps to apply load DB schema and run tests.

If one runs db:migrate, the schema.rb file will be replaced by a blank one, as there are no migrations to run. One should load the current schema instead.


Is there an memory overflow risk of this cache lib?

What will happen if keep adding new key/val pairs into cache?

You will eventually run out of memory. See https://github.com/patrickmn/go-cache/issues/5

@patrickmn  Thanks for reminding me about the #5
Will catch up the issue latter. Thanks again.


Impro1044 part 2: split merge_cubes functionality

Refactored merge_cubes into two classes.  Added new unit tests and migrated existing tests from moved / refactored utilities.
Partially addresses #835
Description of changes:

Moved  _check_coord_bounds, _check_bounds_ranges, _equalise_cell_methods and _equalise_cubes into new MergeCubes class
Refactored MergeCubes._equalise_cubes to use the general utility equalise_cube_attributes, and removed _equalise_cube_attributes (which also created model ID and configuration coordinates)
Created class MergeCubesForWeightedBlending with a new function to create model ID and configuration coordinates, and calling existing function rationalise_blend_time_coords (this will replace the calls in the improver-weighted-blending CLI).  This sets up cubes for blending and then calls the new MergeCubes.process method.
Moved model blending test cases out of test_merge_cubes.py and into MergeCubesForWeightedBlending.py.  (Test setup has been refactored but test cases / coverage remains the same.)  These demonstrate that reordering the setup of cubes for blending has not affected the outcome after merging.

Testing:

[x] Ran tests and they passed OK
[x] Added new tests for the new feature(s)

Note: this overlaps with #838.  Once that has been merged I'll need to sort out the "threshold" coordinate issue in MergeCubes.

@gavinevans Thanks for your comments, I've addressed the easy ones I think (docstrings etc).
On the MergeCubesForWeightedBlending plugin and tests, it looks like I haven't split that very well between __init__ and process, and your comments have highlighted some checks I think I've missed altogether.  So I'll need to spend a little time reworking that next week before it's ready to re-review.  Thanks for picking up on those details.

@gavinevans I think I've now addressed your comments and have reworked the split between __init__ and process to check for things more sensibly (specifically we don't want to create model ID coordinates unless we're blending over models!).  So this should now be ready to re-review.

@cgsandford Thanks for these changes 👍
I've now finished my re-review and just made a couple of very minor comments.

Quick comment that answers some of your questions / comments above.
With this refactor, I haven't actually changed anything about what functionality is called and when.  I've simply moved out the functionality from where "merging=True" (or whatever it was to indicate blending - I honestly can't remember!) into a separate class.  So I'm pretty sure you're right, this won't be the correct split, it's just highlighted exactly how we have been doing it in the past.  This also applies to your question "why aren't we passing these in": they were hard-coded in the previous code, so I've kept them hard-coded here (time-lagging does use concatenation, as realization is a dimension coordinate).  In this way I've done my best to ensure this code behaves (almost) exactly how the old code behaved.
My suggestion is that we don't change anything about the split until the next PR, which will be when I replace the old code.  At that point, I can work against the CLI tests to figure out whether we're using any of the pathways you've highlighted we might want to change or remove.  I can also change the calls to pass in lists of unmatching attributes etc as required.  But if I make any functional changes before that I'm more likely to encounter problems with CLI tests failing because of something we haven't anticipated.
What do you think?

Quick comment that answers some of your questions / comments above.
With this refactor, I haven't actually changed anything about what functionality is called and when. I've simply moved out the functionality from where "merging=True" (or whatever it was to indicate blending - I honestly can't remember!) into a separate class. So I'm pretty sure you're right, this won't be the correct split (or more precisely, I think we'll be able to get rid of a fair bit of the MergeCubes class), it's just highlighted exactly how we have been doing it in the past. This also applies to your question "why aren't we passing these in": they were hard-coded in the previous code, so I've kept them hard-coded here (time-lagging does use concatenation, as realization is a dimension coordinate). In this way I've done my best to ensure this code behaves (almost) exactly how the old code behaved.
My suggestion is that we don't change anything about the split until the next PR, which will be when I replace the old code. At that point, I can work against the CLI tests to figure out whether we're using any of the pathways you've highlighted we might want to change or remove. I can also change the calls to pass in lists of unmatching attributes etc as required. But if I make any functional changes before that I'm more likely to encounter problems with CLI tests failing because of something we haven't anticipated.
What do you think?

I'm happy with this approach and I'll finish reviewing this with this approach in mind. I'm happy for you to do this however you think will give you less problems overall

@cgsandford  I think I've finished reviewing this now

@fionaRust I think I've now addressed all your comments, mostly without question!
Regarding the TODOs, yes, I'm expecting to address these as part of the ticket / issue #835 .  I'm anticipating two more PRs: one to migrate everything to the new plugins and fix any bugs; and then one to move the blending preparation into the weighted blending module.


[SPARK-44693][BUILD] Rename the object Catalyst in SparkBuild to object SqlApi

What changes were proposed in this pull request?
This PR renames the Setting object used by the SqlApi module in SparkBuild/scala from object Catalyst to object SqlApi.
Why are the changes needed?
The SqlApi module should use a more appropriate Setting object name.
Does this PR introduce any user-facing change?
No
How was this patch tested?

Pass GitHub Actions

Merged into master and branch-3.5.Thanks @hvanhovell


Please remove startup log

When using tsdl-image (and tsdl-ttf) in a program, we always get the following log messages at startup which is ennoying:
INFO: Loading Sdl_image, Target = linux
INFO: Loading Sdl_ttf, Target = linux

The culprit is here and since it's a side effect of the module, I don't think that there is an easy way to disable it by changing the log levels before the log message is issued (I don't think that there is a reliable way of ordering the side effects of linked modules).
Unless I overlooked something, could you please remove this startup message in tsdl-image and tsdl-ttf? Thanks!

I think someone else already mentioned this. I'm ok to remove these logs, they have been added to help debugging when porting to other platforms, especially mac os.

Thanks! NB: I have actually been able to remove the logs for now by creating a new library which is liked before tsdl-image and raises the level of printed warnings: https://github.com/savonet/liquidsoap/pull/2913. However, I think that most people would rather have to do that.

done. But I haven't created a new opam version yet

now on opam!

Great, thanks!


Device::cuda_if_available() is false

I use tch = "0.18.0" on windows 11
Downloaded libtorch-win-shared-with-deps-2.5.0+cu118

nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2022 NVIDIA Corporation
Built on Wed_Sep_21_10:41:10_Pacific_Daylight_Time_2022
Cuda compilation tools, release 11.8, V11.8.89
Build cuda_11.8.r11.8/compiler.31833905_0

My env vars are:
LIBTORCH=D:\softwares\Libtorch\libtorch-win-shared-with-deps-2.5.0+cu118\libtorch
TORCH_CUDA_VERSION=11.8
TORCH_VERSION=cu118
Could anybody help me,
what I need to do to have cuda?

same on Ubuntu enviroment, is there any way to solve it?

exactly the same issue on Windows 11

Ensure that you have a build.rs script in your repo that goes along the lines of the ones in tch-rs here, this ensures that the proper flags are used when linking the binary.
Also good if you can checkin the tch-rs repro and run cargo run --example basics -r this should print whether or not the cuda bits are found in this case.

Ensure that you have a build.rs script in your repo that goes along the lines of the ones in tch-rs here, this ensures that the proper flags are used when linking the binary. Also good if you can checkin the tch-rs repro and run cargo run --example basics -r this should print whether or not the cuda bits are found in this case.

Thanks! I tried your suggestion, but unfortunately, the problem still persists.
I checked the contents of target/debug/build/torch-sys-xxx/output and saw that it is already trying to link torch_cuda, but tch::Cuda::is_available is still false.

Well, I'm not sure if this can be the final solution, even I am still can't sure what the issue is, but it seems to have solved my problem for now.
The answer in this link worked for me.
use std::ffi::CString;
use libc::dlopen;

fn main() {
    let path = CString::new("/root/libtorch/lib/libtorch_cuda.so").unwrap();
    unsafe {
        dlopen(path.into_raw(), 1);
    }

    println!("cuda: {}", tch::Cuda::is_available());
    println!("cudnn: {}", tch::Cuda::cudnn_is_available());
}

Ensure that you have a build.rs script in your repo that goes along the lines of the ones in tch-rs here, this ensures that the proper flags are used when linking the binary.

I had this same issue on Ubuntu 22.04.5, tch 0.18.0, and libtorch 2.5.0 cxx11-abi for CUDA 12.4, i.e. all the following lines printed "false":
println!("{:?}", tch::Device::cuda_if_available().is_cuda());
println!("{:?}", tch::utils::has_cuda());
println!("{:?}", tch::utils::has_cudart());

When I added the following build.rs to mycrate root...
fn main() {
    let os = std::env::var("CARGO_CFG_TARGET_OS").expect("Unable to get TARGET_OS");
    match os.as_str() {
        "linux" | "windows" => {
            if let Some(lib_path) = std::env::var_os("DEP_TCH_LIBTORCH_LIB") {
                println!("cargo:rustc-link-arg=-Wl,-rpath={}", lib_path.to_string_lossy());
            }
            println!("cargo:rustc-link-arg=-Wl,--no-as-needed");
            println!("cargo:rustc-link-arg=-Wl,--copy-dt-needed-entries");
            println!("cargo:rustc-link-arg=-ltorch");
        }
        _ => {}
    }
}

...the build failed with the following error:
error: linking with `cc` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH=<paths> VSLANG="1033" "cc" "-m64" <o-file paths> "-Wl,--as-needed" "-Wl,-Bstatic" <rlib-file paths> "-Wl,-Bdynamic" "-lstdc++" "-ltorch_cuda" "-ltorch_cpu" "-ltorch" "-lc10" "-lgomp" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-B/home/myname/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/gcc-ld" "-fuse-ld=lld" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/usr/local/libtorch/lib" "-L" "mycrate/target/debug/build/torch-sys-474ddb9a018375cc/out" "-L" "mycrate/target/debug/build/bzip2-sys-06df454e922f14bd/out/lib" "-L" "mycrate/target/debug/build/zstd-sys-226893407ff59632/out" "-L" "/home/myname/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-o" "mycrate/target/debug/deps/mycrate-4e0e8b81a3a3e1af" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "-Wl,--no-as-needed" "-Wl,--copy-dt-needed-entries" "-ltorch"
  = note: rust-lld: error: unknown argument '--copy-dt-needed-entries'
          collect2: error: ld returned 1 exit status

But simply removing the following line from build.rs fixed that error and now CUDA is detected by tch just fine:
println!("cargo:rustc-link-arg=-Wl,--copy-dt-needed-entries");

I tried to run the examples with cargo run --example basics -r but got this error with a weird path:
Cannot query cuDNN version without ATen_cuda library.

My environment:

windows 11, powershell
pytorch manually downloaded: libtorch-win-shared-with-deps-2.5.1+cu124
PATH and LIBTORCH set

Output:
Cuda available: false
Cudnn available: false
 3
 1
 4
 1
 5
[ CPUIntType{5} ]
-0.6448 -0.9447  1.4366  0.3457
-0.2852  0.7056  0.9534  2.4583
 0.8597  0.0024 -0.6590  0.0307
-0.5374  0.0160 -0.0363  1.3927
-0.5991  0.7843  0.9892 -0.2651
[ CPUFloatType{5,4} ]
 0.8552  0.5553  2.9366  1.8457
 1.2148  2.2056  2.4534  3.9583
 2.3597  1.5024  0.8410  1.5307
 0.9626  1.5160  1.4637  2.8927
 0.9009  2.2843  2.4892  1.2349
[ CPUFloatType{5,4} ]
 1.8552  1.5553  3.9366  2.8457
 2.2148  3.2056  3.4534  4.9583
 3.3597  2.5024  1.8410  2.5307
 1.9626  2.5160  2.4637  3.8927
 1.9009  3.2843  3.4892  2.2349
[ CPUFloatType{5,4} ]
 43.1000
 44.1000
 45.1000
[ CPUFloatType{3} ]
[3] 44.099998474121094
42
5
[ CPUDoubleType{} ]
1.24
[ CPUDoubleType{} ]
1.24
[ CPUDoubleType{} ]
Grad 1.24
has_mps: false
has_vulkan: false
thread 'main' panicked at src\wrappers\utils.rs:124:5:
called `Result::unwrap()` on an `Err` value: Torch("Cannot query cuDNN version without ATen_cuda library. PyTorch splits its backend into two shared libraries: a CPU library and a CUDA library; this error has occurred because you are trying to use some CUDA functionality, but the CUDA library has not been loaded by the dynamic linker for some reason.  The CUDA library MUST be loaded, EVEN IF you don't directly use any symbols from the CUDA library! One common culprit is a lack of -INCLUDE:?warp_size@cuda@at@@YAHXZ in your link arguments; many dynamic linkers will delete dynamic library dependencies if you don't depend on any of their symbols.  You can check if this has occurred by using link on your binary to see if there is a dependency on *_cuda.dll library.\nException raised from versionCuDNN at C:\\actions-runner\\_work\\pytorch\\pytorch\\builder\\windows\\pytorch\\aten\\src\\ATen/detail/CUDAHooksInterface.h:153 (most recent call first):\n00007FFA710883C900007FFA71088320 c10.dll!c10::Error::Error [<unknown file> @ <unknown line number>]\n00007FFA71086C5A00007FFA71086C00 c10.dll!c10::detail::torchCheckFail [<unknown file> @ <unknown line number>]\n00007FF9F17ADDD000007FF9F17ADD80 torch_cpu.dll!at::CUDAHooksInterface::versionCuDNN [<unknown file> @ <unknown line number>]\n00007FF79380CEA000007FF79380CB20 basics.exe!c10::ivalue::Future::waitAndThrow [<unknown file> @ <unknown line number>]\n00007FF7937E3F7E <unknown symbol address> basics.exe!<unknown symbol> [<unknown file> @ <unknown line number>]\n00007FF7937E24BE <unknown symbol address> basics.exe!<unknown symbol> [<unknown file> @ <unknown line number>]\n00007FF7937E1026 <unknown symbol address> basics.exe!<unknown symbol> [<unknown file> @ <unknown line number>]\n00007FF7937E100C <unknown symbol address> basics.exe!<unknown symbol> [<unknown file> @ <unknown line number>]\n00007FF7937E93F9 <unknown symbol address> basics.exe!<unknown symbol> [<unknown file> @ <unknown line number>]\n00007FF7937E2EEC <unknown symbol address> basics.exe!<unknown symbol> [<unknown file> @ <unknown line number>]\n00007FF79385777C00007FF79380CB20 basics.exe!c10::ivalue::Future::waitAndThrow [<unknown file> @ <unknown line number>]\n00007FFAC6FB259D00007FFAC6FB2580 KERNEL32.DLL!BaseThreadInitThunk [<unknown file> @ <unknown line number>]\n00007FFAC7B2AF3800007FFAC7B2AF10 ntdll.dll!RtlUserThreadStart [<unknown file> @ <unknown line number>]\n")
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\release\examples\basics.exe` (exit code: 101)

Ensure that you have a build.rs script in your repo that goes along the lines of the ones in tch-rs here, this ensures that the proper flags are used when linking the binary. Also good if you can checkin the tch-rs repro and run cargo run --example basics -r this should print whether or not the cuda bits are found in this case.

Copying some of the build.rs file worked for me! (I'm compiling on WSL ubuntu)
fn main() {
    if let Some(lib_path) = std::env::var_os("DEP_TCH_LIBTORCH_LIB") {
        println!("cargo:rustc-link-arg=-Wl,-rpath={}", lib_path.to_string_lossy());
    }
    println!("cargo:rustc-link-arg=-Wl,--no-as-needed");
    println!("cargo:rustc-link-arg=-ltorch");
}

Notably, this didn't work without removing the println!("cargo:rustc-link-arg=-Wl,--copy-dt-needed-entries"); line. I'm new to rust, is it expected to have to write/edit a build file for each project like this?

@Anivie's solution worked for me on Windows 11:
use std::ffi::CString;
use std::os::raw::c_char;
use winapi::um::libloaderapi::LoadLibraryA;

fn main() {

    let path = CString::new("X:\\path\\to\\torch_cuda.dll").unwrap();

    unsafe {
        LoadLibraryA(path.as_ptr() as *const c_char);
    }

    println!("cuda: {}", tch::Cuda::is_available());
    println!("cudnn: {}", tch::Cuda::cudnn_is_available());
}


The bridge master can  miss withdraw events

Going through the logs when checking #122, there was no log of this event

Happened again today. https://bscscan.com/tx/0xecfd4886532c55d4411c9bf61506419bc2bfd9fb456a0c08c83bf0f7d7828394

The problem this time was that the bridge was down due to storage issues


Error:  zkSyncTestnet not found in '@wagmi/core/chains'

Due to a recent rename in the wevm/viem repository:
https://github.com/wevm/viem/commit/0b1693aa51468cfe77dae74ad44bd89dfd21fd0e
It appears that zkSyncTestnet has been removed from the chains exports. However, our project still references it here:
https://github.com/matter-labs/dapp-portal/blob/main/data/wagmi.ts#L2
As a result, I'm unable to run the application.

Never mind, my bad...
npm cache clean --force && npm install helped.


Possible printing error: high snark work fee shows as -1

coda client set-snark-work-fee "10000000000000000000"
result:
coda client status
👇
SNARK work fee:                                -1

Closing this issue as it is stale for a long time.


Use Task Provider to avoid task creation during configuration

:pushpin: References

Noticed shot was creating tasks during configuration

:tophat: What is the goal?
This changes task lookup to lazy, via named meaning tasks won't be created during configuration.

How can it be tested?

During configuration shot should have no "tasks" next to it, that means they are created when requested instead of during configuration.
Should work the exact same way as before, all tasks match what was previously generated.

@yogurtearl wondering if this looks good to you too?

LGTM

I suspect that this PR will solve a compatibility issue that I'm seeing with AGP 7.0.0 about something querying applicationId during configuration time. I've tracked that down to Shot, and I bet this PR would solve that.

Ah yes we were seeing that to. Thanks for the quick fix

Oh wait this is my pr lol, oh because right now it's not a lazy look up?

Thank you so much guys. You rock 😃  I'm going to release a new version with the fix right now.
Please @inktomi could you check if the release fixes the issue with AGP 7.0.0 and the appId param?

Unfortunatlly looks like this didn't fix it for us. Lemme have a look later today.

Yea, there still seems to be something going on - sorry, I should have built the project and tested before my comment.

Unfortunatlly looks like this didn't fix it for us.

didn't fix the task creation during config? or didn't fix AGP 7.0.0 compatibility?

Unfortunately looks like this didn't fix it for us.

didn't fix the task creation during config? or didn't fix AGP 7.0.0 compatibility?

The latter


Add starts_with function and operator doc

Added starts_with function and equivalent operator ^@, that are marged into duckdb/duckdb feature branch.
#5334
Also fixed font in the same file.

Thanks!


Extract tarballs in Ubuntu:14.04

Some tarballs cannot be extracted without running as root. Hence tar will be extracted by running the root command
Resolves https://github.com/vmware/tern/issues/433
Signed-off-by: Prajwal M<EMAIL_ADDRESS>

@PrajwalM2212 on line 61
else:
        return result

Can you remove the else: and just return result?

Closing this as the commit is in the PR #440


Expose cooldown system

The cooldown system introduced in 1.9 is fully controlled by the server, and should be accessible to plugins through the API.

Has any progress been made on this?

This really needs to be implemented!

I'll take this. Will be done later today/tomorrow.


⚠ pishem-otzivi has degraded performance

In 365b01c, pishem-otzivi (https://пишем-отзывы.рф/) experienced degraded performance:

HTTP code: 200
Response time: 8559 ms

Resolved: pishem-otzivi performance has improved in 1f78171.