Race condition results in Android replay server behaving like a targeted app

Description
The RenderDoc Android replay server is subject to a race condition on startup that results in its libVkLayer_GLES_RenderDoc.so thinking it’s not running in the replay server. The library thus acts like it’s in an app to be targeted/debugged and opens a control socket (38920) instead of a replay server socket (39920). The most obvious symptom of this is that when you ask RenderDoc to launch an app for debugging, it displays a prompt that says something else is already being debugged (which you know is false). You can then go to File > Attach To Running Instance and you will see the replay server app (e.g., org.renderdoc.renderdoccmd.arm64) listed as something you can attach to, which should never happen.
This doesn’t happen on all devices, but it happens on our devices that have Android 12. A difference between the two situations is the native libraries that are loaded implicitly when the replay server APK starts. In the problematic case (our devices), libhwui.so is loaded immediately when the apk is started. In the working cases (other devices) libhwui.so isn’t loaded. That is, the same exact APK experiences different library loading in the working and failing environments. I’ll provide more details at the end.

The reason libhwui being in the mix is problematic is that it launches a dedicated thread (1) to initialize the Vulkan/GLES environments for the process. http://aospxref.com/android-12.0.0_r3/xref/frameworks/base/libs/hwui/renderthread/RenderThread.cpp#187
This thread starts making vulkan calls (2), and libvulkan.so will, upon the first significant API call, initiate its layer loading. That logic looks for layer libraries in an apk’s lib directory unconditionally (i.e., no properties need to be set). See http://aospxref.com/android-12.0.0_r3/xref/frameworks/base/core/java/android/os/GraphicsEnvironment.java#331
That means that very shortly after the replay server apk starts running, libvulkan will load libVkLayer_GLES_RenderDoc.so (3).
Meanwhile, back on the main thread…the process is busy going other initialization after loading libhwui.so and execution eventually gets to the Loader java class in the replay server that does a System.loadLibrary("renderdoccmd") (4), which loads the replay server logic, all of which is C++ code built into librenderdoccmd.so.
If the main thread doesn’t get to that Java loadLibrary() call before the secondary libhwui thread exercises the vulkan layer loading, then we have a bad situation. The “DllMain” in libVkLayer_GLES_RenderDoc.so tries to determine if it’s in the replay server by doing a dlysm(“renderdoc__replay__marker”). That symbol exists in librenderdoccmd.so. If libVkLayer_GLES_RenderDoc.so was first loaded by the vulkan layer loading, then the library’s DllMain() ran at that time and failed, since librenderdoccmd.so hasn’t yet been loaded.
That dlsym(marker) approach works fine when libVkLayer_GLES_RenderDoc.so is loaded by the loading of renderdoccmd.so in Loader.java, which is how things are supposed to happen. But this secondary thread created by libhwui throws a wrench into things by creating the possibility that libVkLayer_GLES_RenderDoc.so gets loaded prematurely. For our devices it happens more often than not–anywhere from 75% to 95% of the time, depending on the device and build.
I did not find an elegant solution other than to replace the dlsym(marker) call with a check of the process executable and compare it to the name of the Android replay server. I conditionalized this as alternate logic for Android only, of course. If someone can think of a better solution, I’m all for it. I’ll submit the change as a pull request. In general though, it seems hazardous/fragile for libVkLayer_GLES_RenderDoc.so to assume the other library in the replay server (renderdoccmd.so) will be loaded first. Normally (desktop and embedded Linux), the replay server is just an executable and so the assumption is rock solid; the executable will of course be loaded prior to any library the executable dlopens.
Finally, I want to provide more details on why this affects our Android devices but not others I’ve tried (production Android phones). I mentioned early that I noticed a stark difference in the activity in the dynamic loader when launching the replay server APK. Here are some details, in case they provide clues.
When I enable tracing in the bionic loader of a production phone (lacks problem), I see that the first dlopen() in the replay server process is for /system/framework/oat/arm64/org.apache.http.legacy.odex, done by /apex/com.android.art/lib64/libart.so. On our devices (has problem), the first dlopen is for libandroid.so done by /system/lib64/libhwui.so. To enable loader tracing (to logcat), simply do
adb shell setprop debug.ld.app.org.renderdoc.renderdoccmd.arm64 dlopen
Steps to reproduce
This happens on our devices but not production phones I've tried.
Also, this has nothing to do with any app. The problem happens entirely within the replay server apk.
For Android devices where the premature loading of libVkLayer_GLES_RenderDoc.so happens

Launch RenderDoc
Select the Android device in the replay server
Try to launch any app from RenderDoc. You'll get a dialog saying you are already debugging something (although you're not)
Open the Attach to Running Instance and you'll see the replay server listed as something you can attach to (which makes no sense).

Environment

RenderDoc version: 1.20
Operating System:
Host: All
Device: Android 12
Graphics API: N/A since no app is involved.

Baldur, I'm posting my fix here for initial consideration, as it's small. If you think this is acceptable, I'll create a pull request.
diff --git a/renderdoc/os/posix/posix_libentry.cpp b/renderdoc/os/posix/posix_libentry.cpp
index 42756cb68..ee3bf453d 100644
--- a/renderdoc/os/posix/posix_libentry.cpp
+++ b/renderdoc/os/posix/posix_libentry.cpp
@@ -31,7 +31,16 @@ void ResetHookingEnvVars();
 // DllMain equivalent
 void library_loaded()
 {
-  if(LibraryHooks::Detect("renderdoc__replay__marker"))
+  bool isReplayServer = false;
+#if ENABLED(RDOC_ANDROID)
+  rdcstr exeFilename;
+  FileIO::GetExecutableFilename(exeFilename);
+  isReplayServer = exeFilename.beginsWith(RENDERDOC_ANDROID_PACKAGE_BASE);
+#else
+  isReplayServer = LibraryHooks::Detect("renderdoc__replay__marker");
+#endif
+
+  if(isReplayServer)
   {
     RDCDEBUG("Not creating hooks - in replay app");

Is there a way to block the loading of this libhwui.so, or defer it so that it runs at a more sensible time?
I can't imagine how. It's part of the blackbox logic that happens when the apk is launched. I don't think there are any knobs to that process. At the end of the day, there is no reference to that library in the replay server code.

Is there any way to load our libraries before that at an earlier point in initialisation?
Here, too...not that I know of. The existing loadLibrary logic is in a generated java file that is part of a cookie-cutter native activity solution for apks that are effectively native code.

Can we prevent it from loading layers or otherwise configure its vulkan initialisation?
Preventing the layer loading was what I was hoping for, but I studied libvulkan and I see no way to prevent it.
References:
http://aospxref.com/android-12.0.0_r3/xref/frameworks/native/vulkan/libvulkan/api.cpp#1186
http://aospxref.com/android-12.0.0_r3/xref/frameworks/native/vulkan/libvulkan/layers_extensions.cpp?fi=DiscoverLayers#DiscoverLayers

Also the opengrok reference I put in the issue description...it shows the apk's lib directory being added to the search path unconditionally.

is there a reliable order that layers are loaded in? E.g. if it goes alphabetically ....
Unfortunately not. On Android (and presumably Linux), it uses opendir/readdir alone to iterate, and that API provides no guarantees on ordering.

I originally used to just look at executable name until it became clear that that was not sufficient to cover all cases
Ah, ok. Well, that settles that. I can understand why you wouldn't want to go back to something that has already proven problematic. Maybe the proper solution here is to pursue this with Google/AOSP to see if they could provide a way in their vulkan loader to forego adding the apk's lib directory to the layer loading searchpath via a property instead of adding it unconditionally.

So, feel free to close this issue. I've captured/shared the problem here, which was honestly my primary objective. I suspected a proper fix was going to be tricky. I'll create a ticket with AOSP with the ask above and reference this issue. Maybe we get lucky and Android gives us a path for a proper solution down the road.

My worry is that from what you're saying there's nothing specific about this - any Android device could run into this, there's just something about your specific setup which makes it much more likely. With a broken platform like Android that's the kind of thing that can quickly snowball into "lots of people see this".

Maybe the proper solution here is to pursue this with Google/AOSP to see if they could provide a way in their vulkan loader to forego adding the apk's lib directory to the layer loading searchpath via a property instead of adding it unconditionally.

I'm not sure what you mean by a property here? If we have code running early enough that can set some kind of flag, could we not instead use that code to load the library in the correct order?
I have zero confidence that any change will come from this from Google/AOSP, so I'm afraid we will need to do something about it. If there's no possible feasible hack then we should find a way to detect this case and disable the replay server indicating that this bug has occurred.
One other thing I considered, would it be feasible to extend the 'symbol detection' on android (in LibraryHooks::Detect in android_hook.cpp) to call into java and look for that symbol in the java side as well? E.g. require that a class of that name is exported somewhere. I don't know whether this code is running even before java is loaded though, and on top of that like I say there could be other things that break even if this is fixed because the replay server is not intended to run on multiple threads simultaneously.

I'm not sure what you mean by a property here? If we have code running early enough that can set some kind of flag, could we not instead use that code to load the library in the correct order?

The layer search path used by the Android vulkan is controlled by Android properties, and then Android framework code reads those properties and extends the search path accordingly. The host side RenderDoc code sets those properties. What's missing is a property that says "don't load any layers at all". If we had that, then we could set the property when we launch the replay server.

One other thing I considered, would it be feasible to extend the 'symbol detection' on android (in LibraryHooks::Detect in android_hook.cpp) to call into java and look for that symbol in the java side as well?

Hm. Good idea. Let me look into that.

Another idea that @Zorro666 suggested - can you place custom properties in an android manifest and retrieve them in LibraryHooks::Detect ?

I'm unaware of any, but I'll look into that, too

I'm not an Android expert, but if you mean the ones set with adb shell setprop then IMO those should not be used as they are unreliable.

I'm not an Android expert, but if you mean the ones set with adb shell setprop then IMO those should not be used as they are unreliable.

RenderDoc already has a deep reliance on setting properties that way.

I've looked into the latest two suggestions. They aren't feasible. Calling back into the Java world from the C++ world requires context that becomes available to the C++ only after the Java world has first called into the C++ world. The formal C++ world of the apk is in enderdoccmd.so, which hasn't yet been loaded (thus the race condition). And so, no such context for calling into Java is available at that time.

Yes unfortunately so, often mandated by the system only having those properties for necessary settings. That's how I know that the properties are unreliable because there are cases where it will break (e.g. people sometimes run into problems where properties aren't unset properly and no vulkan programs work anymore on the device).

Absolutely. It's quite hackish because properties are global but they're being used to control per-process behavior.

I found a possible solution but it requires API 27 and greater. So not sure if that's a deal breaker.
You can launch a debuggable apk (which the replay server is) with an environment variable using a wrap shell script.
https://developer.android.com/ndk/guides/wrap-script
Thoughts?

As long as that won't break on any other android versions and won't cause any other problems that sounds OK, though it seems a bit lightly documented so I'm a little worried it's going to be unpredictable.

As long as that won't break on any other android version

Well, that's my point., It requires API 27 and higher, which means if we go that route, RenderDoc will stop working on Android versions older than 8.1. For reference, 8.1 was released at the end of 2017. This requires a judgment call from you, as I don't know how far back you want to support Android, nor do I know the oldest version of Android RenderDoc currently supports.

older versions of android would still work fine because they just won't run the script?

But the solution would involve two things:

make use of the script to set an environment variable
change the am-i-in-the-replay server check in libVkLayer_GLES_RenderDoc.so to check the environment variable instead of doing a dlsym(marker)

It's (2) that would break older Android versions given the script won't run pre 8.1

Ah I see what you mean. Ideally yes, a solution which works on all android versions would be best, but from the previous discussion on the issue it doesn't seem like any such solution exists :smile: . Particularly if we're not even sure if this bug is possible to reproduce on older Androids. FWIW this isn't without precedent, e.g. until Android 10 GL layers are available RenderDoc uses JDWP/interceptor-lib hooking which does not always work on all devices/apps.
Either way let's leave this for now unless someone comes up with a clear portable fix.

but from the previous discussion on the issue it doesn't seem like any such solution exists 😄

It sure has been leaning that way, but there's always a chance there's an epiphany around the corner.
And yeah, I agree with the open questions of...why exactly is the apk order loading different for our Android platform? Are we alone? If we're not, what range of Android versions are at play? So yeah, probably best to park this until we have a more pressing reason to address it globally. I already have a local fix (which uses the executable filename check you once had; the problematic scenario you said it suffers from is N/A for my company).
And yeah...thank god for Android GLES layer loading now. Things were not pretty before then.

Could we please reopen this issue? Pixel 6 is affected by this, and it seriously hampers usage of RenderDoc.
And about a solution, assuming switching to API 27 does in fact solve the problem, how about at least providing a build config? The official build could continue to use the old API version as long as Android 6 is supported, but at least we could build RenderDoc from source, specify that we are ok with a newer API version, and not have this problem anymore.

Curious. What version of Android is on your Pixel 6? If this indeed ends up being an issue for only recent Android versions, then Baldur's recommendation to add the new type of check to the existing one, instead of replacing it, would be the cleanest fix. Until now, it wasn't even clear if anyone else but me was seeing this behavior. We now have at least one other person, so yeah...we need to start thinking more seriously about fixing it (as best we can).

I was worried this Android bug wouldn't be isolated to a single case :(.
Yes I think the best solution for this is to allow the use of the wrapper script on newer Androids, use normal detection on older Androids (or I guess newer Androids will use both implicitly). I'll need to read more documentation on the scripts to make sure there aren't any unpleasant side-effects or other bugs. Hopefully this bug is only introduced in a new version of Android so there's no gap in coverage, but at least that will fix it for the common case of broken new Android versions.

What version of Android is on your Pixel 6?

I'm on something more recent now (and still an issue), but this was observable even with the original Android version that shipped with Pixel 6.
Infinite gratitude if it can be fixed!

That commit adds a wrap script to export an env var, and checks it optionally with the proper symbol. I don't have a device with a broken version of Android though so I can't properly test that it fixes the problem (maybe the renderdoc library will still get loaded before the wrap script executes perhaps?).
Can you test to see if that commit fixes it, either with a local build or else with the next nightly?

Either I'm getting super lucky suddenly, or indeed the commit fixes it
:1st_place_medal: for @jcortell68 for diagnosing this and :1st_place_medal: for Baldur for the quick fix. Thank you!

Just got back from PTO. I'll try the fix locally (after disabling the alternative fix) later today and report back

Baldur, interesting results from trying the fix.
It works, which is good. The curious part is that the fix has altered how the replay server's dynamic linking plays out. I know see libart.so getting loaded early on, which is something that wasn't happening without the wrapper script. The end result is that the race condition no longer happens. Consequently, in logcat, I see the following every time
08-18 11:18:05.619  2650  2650 I renderdoc: @62fe663d00000001@ RDOC 002650: [11:18:05] 	android_hook.cpp( 683) - Log 	- Detecting symbol renderdoc__replay__marker by dlsym: yes
08-18 11:18:05.620  2650  2650 I renderdoc: @62fe663d00000002@ RDOC 002650: [11:18:05] 	android_hook.cpp( 684) - Log 	- Detecting symbol renderdoc__replay__marker by getenv: yes

What this means is that the setting of the env variable isn't actually needed, which is a bit ironic. The purpose of the change is to introduce an environment variable that can be used to detect the replay server context, but the mechanism used makes the environment variable unnecessary :-)
Bottom line, though...the change fixes the problem, and that's what's important.

Baldur & jcortell68,  I can also reproduce this issue with OPPO find X3 pro, and luckily your patch works well on my devices,
Thank you~

It's probably going to break again, especially given the previous reply that it is already being unreliable, even just with the workaround to an Android bug. It's impossible to predict how or where though, Android is such a completely terrible and fundamentally broken platform that nothing ever works reliably as it should, and there is always some incredibly stupid new breakage.
My guess is there will be devices where the original android bug manifests but those devices have disabled wrapper scripts so the environment variable workaround doesn't run. It's not feasible to try and predict that though so we'll need to wait and see what goes wrong.

It's probably going to break again, especially given the previous reply that it is already being unreliable, even just with the workaround to an Android bug. It's impossible to predict how or where though, Android is such a completely terrible and fundamentally broken platform that nothing ever works reliably as it should, and there is always some incredibly stupid new breakage.
My guess is there will be devices where the original android bug manifests but those devices have disabled wrapper scripts so the environment variable workaround doesn't run. It's not feasible to try and predict that though so we'll need to wait and see what goes wrong.

Yes, I hava done more tests to verify this patch and found out it does not always work on my devices.
There is  about 50% repetition that I can still reproduce this issue with this patch.

Baldur, interesting results from trying the fix.
It works, which is good. The curious part is that the fix has altered how the replay server's dynamic linking plays out. I now see libart.so getting loaded early on, which is something that wasn't happening without the wrapper script. The end result is that the race condition no longer happens. Consequently, in logcat, I see the following every time
08-18 11:18:05.619  2650  2650 I renderdoc: @62fe663d00000001@ RDOC 002650: [11:18:05] 	android_hook.cpp( 683) - Log 	- Detecting symbol renderdoc__replay__marker by dlsym: yes
08-18 11:18:05.620  2650  2650 I renderdoc: @62fe663d00000002@ RDOC 002650: [11:18:05] 	android_hook.cpp( 684) - Log 	- Detecting symbol renderdoc__replay__marker by getenv: yes

What this means is that the setting of the env variable isn't actually needed, which is a bit ironic. The purpose of the change is to introduce an environment variable that can be used to detect the replay server context, but the mechanism used makes the environment variable unnecessary :-)
Bottom line, though...the change fixes the problem, and that's what's important.

I am a little confused that why this patch can change the order of *.so loading....

And it only took 4 hours for Android to prove itself to be a garbage platform once again.
Can you share a clean logcat from just starting the remote server - clear the logcat buffer before with the server not running, then connect to that replay context in the UI and let the server start itself and save the logcat.

And it only took 4 hours for Android to prove itself to be a garbage platform once again.
Can you share a clean logcat from just starting the remote server - clear the logcat buffer before with the server not running, then connect to that replay context in the UI and let the server start itself and save the logcat.

I have shared the logcat via E-mail(baldurk(at)baldurk.org), please check your Email inbox..
The tag logs in the logcat is,
08-22 21:21:18.077 15230 32488 D linker  : dlsym(handle=0x0("n/a"), sym_name="renderdoc__replay__marker", sym_ver="(null)", caller="/data/app/~~MbSMXCHatqRNsIKIhnqgyg==/org.renderdoc.renderdoccmd.arm64-5hiRyGriAn8KPXKX_-e15w==/lib/arm64/libVkLayer_GLES_RDC_Test.so", caller_ns=classloader-namespace@0x7a58b71e80) ...
08-22 21:21:18.077 15230 32488 D linker  : undefined symbol: renderdoc__replay__marker
08-22 21:21:18.077 15230 32488 D linker  : ... dlsym failed: undefined symbol: renderdoc__replay__marker
08-22 21:21:18.077 15230 32488 D linker  : dlerror set to "undefined symbol: renderdoc__replay__marker"
08-22 21:21:18.077 15230 32488 I renderdoc: @630382ce00000001@ RDOC 015230: [21:21:18]     android_hook.cpp( 683) - Log     - Detecting symbol renderdoc__replay__marker by dlsym: no
08-22 21:21:18.077 15230 32488 I renderdoc: @630382ce00000002@ RDOC 015230: [21:21:18]     android_hook.cpp( 684) - Log     - Detecting symbol renderdoc__replay__marker by getenv: no
08-22 21:21:18.078 15230 32488 I renderdoc: @630382ce00000003@ RDOC 015230: [21:21:18]    posix_network.cpp( 429) - Log     - Created and bind socket: 233

What exactly is this build? The log snippet you posted references a file libVkLayer_GLES_RDC_Test.so in the org.renderdoc.renderdoccmd.arm64 package which has never existed and does not exist now, and the log indicates the build is from v1.20 at commit 19b25d86d9247a134cd84731fe4cf9b624633ff5 which is the wrong version and that commit does not exist on this repository.
In fact the log shows two processes starting, one is the RenderDoc remote server which is correctly detected and the second is a captured program.
Please explain what is happening here, and if you can reproduce this issue as you said above please share a logcat as I requested above - cleared before the bug appears, and only showing the launch of the remote server when it is misidentified as a captured program without then launching a program for capture. If the bug doesn't manifest, close everything and clear the logcat then start again so you can get a clean log.

As we all know, RenderDoc is a very excellent graphic debug tool, I hava added some new functions to enhance the compatibility of RenderDoc which is  based on v1.20, such as to support GL_TEXTURE_EXTERNAL_OES textures in OpenGL ES for Android platforms and change the name of libVkLayer_GLES_RenderDoc .so to libVkLayer_GLES_RDC_Test.so.
The commit of 19b25d86d9247a134cd84731fe4cf9b624633ff5 is the "wrap script patch", I just  changing the commit ID for my local git repository.
All in all, those commits are nothing to do with this issue.
Back on this issue itself, I don't know why that I have tested many times but I cannot reproduce this issue again on my device today.... So, the patch works today, feel free to close this case.

In future do not waste my time again by reporting bugs based on a customised non-standard build.


Have you considered to push this mainline?

Thus many BAP users would see it out of the box. And probably more testing and contributing.

We'd definitely like to, but there are a couple low-hanging ways to improve it that I've been meaning to get around to first.  It's been a busy few months, but hopefully soon!

Well, it is already sort of pushed, see the opam package. Once it is installed, any bap user can benefit of it.

@ivg yes, it is available once you know about its existence. It is not mentioned anywhere on the BAP site as far as I remember. Having it under the BAP organization will provide better visibility.

We can include it in the bap package, this was the plan, actually. We're waiting for the first stable release of cbat_tools. Of course, cbat developers are welcome to BinaryAnalysisPlatform repo, and if they want we can grant them all the necessary rights, but I believe they will feel more comfortable under their own organization :) We are also happy to include cbat in our README.md, but this is not extensible solution. The best way to learn about the existence of this package, is to do opam search bap

Note, now with BAP 2.0 being in master, it might require some changes in the code:

https://github.com/BinaryAnalysisPlatform/bap/pull/960
http://binaryanalysisplatform.github.io/knowledge-intro-1

Indeed - we plan to update to BAP 2.0, but it may be a few weeks.  In general we are still happy for any of these tools to eventually be included with BAP - in particular the WP analysis is at this point quite useful.  However, since it is also still under active development, I'm not sure what the best strategy for that would be.


Need better example

Current example in README is:
text.replace(new RegExp(RegExp.escape(str), "g"), newSubstr)

But because we now have replaceAll, it could be simply ourLongText.replaceAll(str, newSubstr) now.

PR welcome

PR welcome


Force multiplatform to ignore android plugin

This is temporary, but it simplifies the consumption story in MPP projects which also apply the Android plugin until we can handle multiplatform platforms before variants.

CI was going green. Want the SNAPSHOT build.


Wheel with enableTonalPalette -> LateInitializationError: Field '_activeColorSwatchList@1082511434' has not been initialized.

To reproduce the problem you need to modify example from: https://pub.dev/packages/flex_color_picker/example with
class _ColorPickerPageState extends State<ColorPickerPage> {
...
@override
  void initState() {
	...
	dialogPickerColor = const Color(0xFF613E42); \\ Set custom color to force wheel
	...
   }

   ...
  Future<bool> colorPickerDialog() async {
    return ColorPicker(
    ...
    enableTonalPalette: true, \\Enable tonal palete
    ...
    ).showPickerDialog(
     ...
    );
   }
}

Then you have to:

click on color swatch from section ''Click this color to modify it in a dialog..' to open 'Select color' with Wheel dialog active
select any color from tonal palete
change tab to primary then you will get an exception:

======== Exception caught by widgets library =======================================================
The following LateError was thrown building ColorPicker(dirty, state: _ColorPickerState#a56bf):
LateInitializationError: Field '_activeColorSwatchList@1082511434' has not been initialized.

The relevant error-causing widget was:
  ColorPicker ColorPicker:file:///D:/workspace/mobile/ex_app/lib/ag/main.dart:255:12
When the exception was thrown, this was the stack:
#0      _ColorPickerState._activeColorSwatchList (package:flex_color_picker/src/color_picker.dart)
#1      _ColorPickerState.build (package:flex_color_picker/src/color_picker.dart:1709:42)
#2      StatefulElement.build (package:flutter/src/widgets/framework.dart:5583:27)
#3      ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:5471:15)
#4      StatefulElement.performRebuild (package:flutter/src/widgets/framework.dart:5634:11)
#5      Element.rebuild (package:flutter/src/widgets/framework.dart:5187:7)
#6      BuildOwner.buildScope (package:flutter/src/widgets/framework.dart:2895:19)
#7      WidgetsBinding.drawFrame (package:flutter/src/widgets/binding.dart:984:21)

Hi @te8uekm12,
Thanks for this report and sorry for the delay.
I have verified the bug, identified the bug and made a fix.
I just needs to test and verify it a bit more.
I should be able to release the fix later today.

The bug is fixed, but the package is not released yet. GitHub auto closes an issues with a FIX is mentioned that references and issue. I re-opened the issue and will close it manually when the updated package that contains the fix has actually been released on pub.

Version 3.3.1 with the fix has been released.


fix issue with api version

since 3.0.1 issues to collect api version
fix the issue opened here : https://github.com/bb-Ricardo/netbox-sync/issues/88

Thank you for the PR, we both fixed it at the same time. Will close this PR.


Update ember-cli-babel

Ember-cli-babel needs to be updated to at least 7.26.1. The below is happening and preventing an upgrade to Ember 4
Prior to v7.26.6, ember-cli-babel sometimes transpiled imports into the equivalent Ember Global API, potentially triggering this deprecation message indirectly, even when you did not observe these deprecated usages in your code.

fixed in https://github.com/san650/ember-cli-page-object/pull/574. Thanks!

@ro0gr since this was merged can a 1.17.10 get published?

@rtablada sure, will do it today

https://github.com/san650/ember-cli-page-object/releases/tag/v1.17.10

For the record, I suspect even with this change it still won't be possible upgrade to Ember 4 against ember-cli-page-object@1 due to "@ember/polyfills" usage https://github.com/san650/ember-cli-page-object/issues/571


Unable to enable frzr tweeks

Hello I tired the sudo command but it says frzr overrides are disabled.
I navigated to the configuration file but it says I don’t have permission to open it or change it.
I am new to Linux so have no idea how to change this
Thanks

You need to use sudo when opening the file
Eg,  in a terminal:
sudo nano /etc/device-quirks/device-quirks.conf


upgrade espower-source to ^2.0.0

Will be a minor release.
@zoncoen Would you take a look?

@zoncoen Thank you!


Add developer docs preview deployments

Description

It's the same idea as our storybook/tailwind configuration deployment previews in the frontend, but with the developer docs that are published from the API :grin:
Testing Instructions

Check the PR comments and try the preview link.
Checklist

[ ] My pull request has a descriptive title (not a vague title like Update index.md).
[ ] My pull request targets the default branch of the repository (main) or a parent feature branch.
[ ] My commit messages follow best practices.
[ ] My code follows the established code style of the repository.
[ ] I added or updated tests for the changes I made (if applicable).
[ ] I added or updated documentation (if applicable).
[ ] I tried running the project locally and verified that there are no visible errors.

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

@AetherUnbound I think I want to write a marketplace action for it!

That would be amazing! 😮 ✨


Is cooperativeGestures parameter supported?

I'd like to use this option for better UX on mobile.
So far I've tried adding it to the Map component as a prop, to the mapComponent object, and as an option, but having no luck.
<Map
  accessToken={PUBLIC_MAPBOX_API_TOKEN}
  style="mapbox://styles/mapbox/outdoors-v11"
  bind:this={mapComponent}
  on:ready={onReady}
  center={[event.location.lng, event.location.lat]}
  zoom="4"
  cooperativeGestures={true}
// or
  options={{ cooperativeGestures: true }}
>

or mapComponent.cooperativeGesture = true;
or mapComponent.options = {cooperativeGesture = true};
Thought I'd check if it's supported or something I'm doing wrong. (most likely the latter, i'm a Svelte noob!)

It used to work in earlier versions. Currently it works with  but only for mobile. It appears that the Desktop version stopped working at some point, unfortunately I'm unable to say at which point.


the root nobuild does not have the fmt subcommand

introduced in #450

It does not need to anymore. Now it simply passes the arguments to the children subprojects


Combined output problem

Don't use exec.Cmd.CombinedOutput() when execing as it makes redirection to yaml file prone to silent failures
sven@x1carbon:~/src/github/timescaledb/tobs/cli$ tobs helm show-values | head
WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /etc/rancher/k3s/k3s.yaml
# Values for configuring the deployment of TimescaleDB
# The charts README is at:
#    https://github.com/timescale/timescaledb-kubernetes/tree/master/charts/timescaledb-single
# Check out the various configuration options (administration guide) at:
#    https://github.com/timescale/timescaledb-kubernetes/blob/master/charts/timescaledb-single/admin-guide.md
cli: false
timescaledb-single:
  # disable the chart if an existing TimescaleDB instance is used
  enabled: true
sven@x1carbon:~/src/github/timescaledb/tobs/cli$ ./bin/tobs helm show-values > /tmp/values.yaml| head
WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /etc/rancher/k3s/k3s.yaml

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: heyleke:x: SvenDowideitYou have signed the CLA already but the status is still pending? Let us recheck it.

the first commit is from #95 - as I need that too :)


App crashes immediately after lunching on Android

There seem to be a problem running apps on Android. It works fine I'm when running it on Mac OS but crashes immediately after the source files have been extracted on Android. I'm using buildozer to build it and what I can see there are no problems when building the app.
I/python  (14025): extracting lib/python2.7/site-packages/pygame/threads/init.pyo
I/python  (14025): extracting main.pyo
I/python  (14025): extracting renderer.pyo
I/python  (14025): extracting sitecustomize.pyo
W/ResourceType(14025): No package identifier when getting value for resource number 0x00000000
E/art     (14025): dlopen("/data/app/org.test.myapp-2/lib/arm/libpython2.7.so", RTLD_LAZY) failed: dlopen failed: cannot locate symbol "exp" referenced by "libpython2.7.so"...
E/AndroidRuntime(14025): FATAL EXCEPTION: Thread-757
E/AndroidRuntime(14025): Process: org.test.myapp:python, PID: 14025
E/AndroidRuntime(14025): java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "exp" referenced by "libpython2.7.so"...
E/AndroidRuntime(14025): 	at java.lang.Runtime.loadLibrary(Runtime.java:371)
E/AndroidRuntime(14025): 	at java.lang.System.loadLibrary(System.java:988)
E/AndroidRuntime(14025): 	at org.renpy.android.PythonActivity.run(PythonActivity.java:254)
E/AndroidRuntime(14025): 	at java.lang.Thread.run(Thread.java:818)
W/ActivityManager(  562):   Force finishing activity 1 org.test.myapp/org.renpy.android.PythonActivity

What phone do you have?

And which SDK did you use to compile?

I've got a Nexus 4 running Android 5.1.1. I'm using SDK 21

exactly the same issue occured with me

It might be related to http://stackoverflow.com/questions/27119623/android-l-5-0-does-not-search-native-libraries-in-armeabi-or-armeabi-v7a-f

I'm running into this issue as well, independent of device. However, I'm able to build the same app using the same toolchain on linux (fedora 22), but receive this error when building on a mac (osx 10.11.1). I'm using buildozer pointed to the old_toolchain branch of python-for-android. Perhaps this bug should be moved to the old_toolchain branch of python-for-android?

@tito
@rammie
Hi Guys,
I believe I have the same problem here on OSX 10.9.5:
D/houdini ( 6638): [6657] Load library /data/app/org.test.njeapp-2/lib/arm/libpython2.7.so failed.
E/art     ( 6638): dlopen("/data/app/org.test.njeapp-2/lib/arm/libpython2.7.so", RTLD_LAZY) failed: dlopen failed: "/data/app/org.test.njeapp-2/lib/arm/libpython2.7.so" has unexpected e_machine: 40

@heliomaster You have a different problem. You are not missing the same exp symbol as the original post. You're also using Android x86, while P4A compiles for ARM. This usually works fine via houdini, but apparently houdini is rejecting for some reason (and you didn't include that reason, which should have been right above those lines from the log). Feel free to open a new issue.

Hi kived ,
I will open the issue, thank you for the answer.

I'm having a similar error
E/art     (18347): dlopen("/data/app/org.test.mypainter-1/lib/arm/libpython2.7.so", RTLD_LAZY) failed: dlopen failed: cannot locate symbol "exp" referenced by "libpython2.7.so"...
E/AndroidRuntime(18347): FATAL EXCEPTION: Thread-4308
E/AndroidRuntime(18347): Process: org.test.mypainter:python, PID: 18347
E/AndroidRuntime(18347): java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "exp" referenced by "libpython2.7.so"...
E/AndroidRuntime(18347): 	at java.lang.Runtime.loadLibrary(Runtime.java:371)
E/AndroidRuntime(18347): 	at java.lang.System.loadLibrary(System.java:988)
E/AndroidRuntime(18347): 	at org.renpy.android.PythonActivity.run(PythonActivity.java:254)
E/AndroidRuntime(18347): 	at java.lang.Thread.run(Thread.java:818)

I'm experiencing the same error whilst trying to deploy using Buildozer. I've tried changing the SDK versions etc to no avail. I'm using OSX Yosemite and my phone is a OnePlus One.

This issue was moved to kivy/python-for-android#653


Use cache service to store configuration

Codecov Report

Merging #14 (23e506c) into main (4d9bf31) will increase coverage by 0.13%.
The diff coverage is 85.29%.

@@             Coverage Diff              @@
##               main      #14      +/-   ##
============================================
+ Coverage     81.06%   81.19%   +0.13%
- Complexity     3087     3090       +3
============================================
  Files           145      145
  Lines          7905     7907       +2
============================================
+ Hits           6408     6420      +12
+ Misses         1497     1487      -10

Impacted Files
Coverage Δ

src/Mapping/MappedEventSubscriber.php
89.74% <82.60%> (+9.46%)
:arrow_up:

src/Mapping/ExtensionMetadataFactory.php
91.78% <90.90%> (-0.87%)
:arrow_down:

src/Tree/Mapping/Driver/Yaml.php
67.59% <0.00%> (-0.93%)
:arrow_down:

src/Uploadable/UploadableListener.php
92.91% <0.00%> (-0.38%)
:arrow_down:

src/Tree/RepositoryUtils.php
96.29% <0.00%> (-0.05%)
:arrow_down:

.../MongoDB/Repository/MaterializedPathRepository.php
98.30% <0.00%> (-0.03%)
:arrow_down:

...e/Entity/Repository/MaterializedPathRepository.php
98.11% <0.00%> (-0.02%)
:arrow_down:

...c/Tree/Entity/Repository/ClosureTreeRepository.php
52.99% <0.00%> (+0.16%)
:arrow_up:

src/Mapping/Annotation/Timestampable.php
66.66% <0.00%> (+6.66%)
:arrow_up:

src/Mapping/Annotation/Loggable.php
57.14% <0.00%> (+7.14%)
:arrow_up:

... and 3 more

Continue to review full report at Codecov.

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


Correctly identify the license of the package

Systems that scan license IDs expect standard license identifiers from SPDX. This also disambiguates between Apache-1.1 and Apache-2.0 and conforms with the package.json documentation.

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


fix(Zerion): return only non-spam items

Description
This PR adds an additional filter to Zerion requests to filter out only non-spam items in transactions history and address balance since we don't need to return spam items. According to the Zerion API docs filter filter[trash] is applied.
How Has This Been Tested?

Current integration tests.

Due Diligence

[ ] Breaking change
[ ] Requires a documentation update
[ ] Requires a e2e/integration test update

Maybe we could use a constant or a function or something to make a little more DRY? Lgtm tho. Thanks!!!

Makes sense, encapsulated in the function now. Thanks!!!


FactoryBean for Zookeeper properties.

I'd love something like:
@ZookeeperProperty(name="helpful-url",auto-start=false)
private Provider<String> helpfulUrlProvider;
...
    LOG.debug("You can find help at: {}", helpfulUrlProvider.get());

Since it's a Provider, calls to .get would automatically have the "latest" value from ZK via the ZookeeperTreeCachePropertySource. The property would automatically be expected to live under one of the contexts. auto-start false would indicate that all wiring and looking up would be performed on the first query instead of bean wiring time.
@EphemeralNode(name="helpful-url",auto-start=false,default-value="http://localhost:${server.port}")
private EphemeralNode helpfulUrl;
....
// maybe after leader election
ephemeralNode.start();
ephemeralNode.set("update value");

EphemeralNode would be lifecycle aware and close on predestroy, and if auto-start=true, call start() during post create.

No need for something like @ZookeeperProperty+Provider. With spring boot/cloud  @ConfigurationProperties object can be refreshed with new values.  (ie if you POST to /refresh). What is missing is to trigger a refresh if using ZookeeperTreeCachePropertySource.

Is there a general design you'd like to see so that beans can subscribe to property value changes via TreeCacheEvents? Would this tie in with the existing @RefreshScope? We're looking for this functionality and can probably contribute it back.

It should tie in with existing /refresh functionality from spring-cloud-commons. See here for a current PR for consul.

Does this sound reasonable? Have ZookeeperTreeCachePropertySource implement TreeCacheListener and register itself with the backing TreeCache. When a TreeCacheEvent happens, call RefreshEndpoint#refresh. RefreshEndpoint could be wired up in ZookeeperConfigBootstrapConfiguration.
The only problem I see with this approach is that the entire context is refreshed with any property change, instead of just the affected beans.
It might be possible to grab all beans tagged with @ConfigurationProperties and introspect their path from the annotation and only refresh the bean that matches TreeCacheEvent.getData().getPath() via RefreshScope.refresh(String name) instead of RefreshScope.refreshAll(). Although I don't know how to figure out the full path for nested configurations.

Ok, I have this working as I described in the bottom of previous post. If a @ConfigurationProperties is also tagged with @RefreshScope then that bean, and only that bean, will be refreshed when a TreeCacheEvent is received and the event's path matches the bean's path.
The only problem is that I need to register the child application context, not the bootstrap context, with each ZookeeperTreeCachePropertySource. I've got an ugly hack that walks through the PropertySources after initialization, but I'm sure there has to be a better way.


Show loader when the audio file is loading

STR:

Clicked on a Surah to play
Player appeared with all the controls
Did not see a loader or anything to indicate the file is loading... after 2s it started to play.

amazing idea.

Perhaps you can disable all the buttons and have the Play/Pause button be a spinner?


How to extend iso4217.py from outside the application?

How to extend iso4217.py from outside the application?
I want to create my own currency that is not found in iso4217.py
my custom currency_code not in CURRENCIES and therefore I get an error.
please help.

At the end of iso4217.py, I added

feel free to add more currencies, alphabetically ordered

so, please add your currency, create a pull request and I will merge it immediatly.

Thanks for answering.
My question is to know if there is a possibility to add new currencies externally without affecting the core of the project.
Anyway I just sent a pull request.
Thank you so much!

or just tell me, which currency you need.

I have sent pull request

closed via #818


Allow for an existing cloudProviderApiKey secret

The helm chart allows for the use of an existing prometheus secret
https://github.com/opencost/opencost-helm-chart/blob/c86ac7031c2965c839a757591a73d3f32f2a9e93/charts/opencost/templates/deployment.yaml#L149
However an existing cloudProviderApiKey secret cannot be specified.
https://github.com/opencost/opencost-helm-chart/blob/c86ac7031c2965c839a757591a73d3f32f2a9e93/charts/opencost/templates/deployment.yaml#L126C46-L126C65

You want to use a cloudProviderApiKey to access Prometheus? Would that be a separate block of
name: DB_BASIC_AUTH_USERNAME
              valueFrom:
                secretKeyRef:

?
Could you provide an redacted example of what you'd want this to look like?

If the OP is in the same situation as us, we already have a Secret created by other means, ie external-secrets, which has the cloudProviderApiKey in it, and want to use this Secret instead of hard coding the API key in the helm values. This would be similar to how the opencost.cloudIntegrationSecret values is set up.
If we configure opencost.exporter.cloudProviderApiKey in values, the helm chart will also create a Secret, and if we do not configure this setting, the Deployment manifest will not add the environment variable CLOUD_PROVIDER_API_KEY to the Deployment manifest using the pre-existing Secret.
To get around this we would need to use kustomize to avoid putting secrets in our git repositories (we use ArgoCD to deploy all our apps).
If something like this could be added to the Deployment manifest, it could fill this usecase:
            {{- if .Values.opencost.exporter.cloudProviderApiKeySecret }}
            - name: CLOUD_PROVIDER_API_KEY
              valueFrom:
                secretKeyRef:
                  name: {{ include "opencost.exporter.cloudProviderApiKeySecret" . }}
                  key: CLOUD_PROVIDER_API_KEY
            {{- end }}

@andersbulderbank we'd definitely take a test PR for that

I've made a PR that should resolve this issue "indirectly".
We could now add extra env this way:
extraEnv:
- name: FOO
  value: BAR
- name: SECRET_FOO
  valueFrom:
    secretKeyRef:
      name: secret-foo
      key: bar

Sorry for coming in super late here, but there are 2 existing environment properties, one that accepts a list of custom formatted env entries and one that accepts a map of key/value pairs.
List - opencost.exporter.env
Map - opencost.exporter.extraEnv
opencost:
  exporter:
    env:
      - name: CLOUD_PROVIDER_API_KEY
         valueFrom:
         secretKeyRef:
           name: my-secret-key
           key: CLOUD_PROVIDER_API_KEY

The combination of these two should be usable for any environment variable you want to pass. Please let me know if I am misunderstanding and this doesn't solve your use case.


chore: update ngx-launcher

@gastaldi this updates the angular-app branch and fixes https://github.com/fabric8-launcher/launcher-frontend/issues/1126 all we need to do now is merge / test and release


Dismiss open autocompletes between tests

Clearing the value doesn’t seem to work reliably when the autocomplete is currently open, especially if it has been interacted with (e.g. in a test that sends the arrow down key to focus on a result)
By sending ‘escape’ we dismiss any open autocompletes, which then seems to make the input-clearing work reliably.

Going to merge this so I can investigate https://github.com/alphagov/accessible-autocomplete/pull/400, hope this is OK :)


jps: Watch harmonyrealestate.com.au

jps requests the watch of the watch_keyword harmonyrealestate\.com\.au. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

harmonyrealestate\.com\.au has been seen in 0 true positives, 0 false positives, and 0 NAAs.

Discussions spam https://chat.stackexchange.com/transcript/message/65360718#65360718

Approved by tripleee in Charcoal HQ


Futures (Request for feedback)

Looking for highlevel feedback, you can ignore formatting/comment issues till later.
@patflynn @meltsufin @etanshaul @akerekes @aslo @elharo @nbashirbello @joaoandremartins
It might make sense to pull the branch down into your repository and explore the v2 package path. Start with DeployExample.java
CloudSdkv2 is just to disambiguate with the original cloudSdk to keep changes out of the main packages.

It seems like this PR does a lot more than just adding Futures. Why not just "futurize" CloudSdkAppEngineDeployment's et al. return?
I don't see the value of adding extra complexity in the form of request factories, etc., especially since a next milestone for this project could be to get rid of gcloud and use a Java API instead (which would hopefully use Futures).

@loosebazooka I think it might be easier to go over all this in a meeting. Do you want to set something up for next week?

We've contemplated moving to Java 8 for the Eclipse tools.  I wonder if there's some way to be enable using CompletableFuture for Java 8 as it a nicer JavaScript-like promises programming paradigm.  Perhaps providing a FutureFactory<F extends Future>?

Restructured pull request into more reviewable blocks, see commits for each block

The public API with deploy
The process management
The cloud sdk implemenation

Anyone who's interested, take a look again. I've changed some of the internals to make them easier to test. Taken out the callbacks. The interface is only Futures and an Output handler.

@akerekes take a look, I fixed some of the naming also changed the pkg to "Experimental"

LGTM


Building time for cargo bench takes quite a long time

Is your feature request related to a problem or challenge?
Running cargo bench --bench math_query_sql takes almost 4min for building, @goldmedal reported that it takes about 10min for him
Most of the time stuck at datafusion/core crate.
Describe the solution you'd like
Find the root cause and reduce the building time if possible
Describe alternatives you've considered
No response
Additional context
No response

By the way, I only modified a small part of the codebase, but it takes about 10 minutes to compile (I have builded it once). I guess it rebuilds everything every time.

5:45 here in a docker .devcontainer to run that bench command. I suspect a good portion of it is because cargo bench uses the bench profile which inherits from release. Adding --profile=dev  to the command reduces the build down to 56s here.

5:45 here in a docker .devcontainer to run that bench command. I suspect a good portion of it is because cargo bench uses the bench profile which inherits from release. Adding --profile=dev  to the command reduces the build down to 56s here.

release mode is prefer for benchmarking, therefore it doesn't seem like a good idea to add --profile=dev


[ICONS] export all shapes modules from index.ts

This PR will allow users to import all shapes from the same source path. And this should be the recommended way to import shape modules.
Example:
import {ClrShapeCar, ClrShapeApplication, EssentialShapes } from "@clr/icons"

Signed-off-by: Shijir Tsogoo<EMAIL_ADDRESS>

Please make sure to update documentation.

Closing this PR as it would introduce a breaking change. @gnomeontherun is currently investigating other possible solutions.


Output the snapshot to set location?

So we're using this to export a couple of RDS DBs into our data lake. The problem I have is each day the snapshot is created in a new folder (with the new date) so my Glue Crawlers create another set of tables with the latest data.  This means our analysts have no easy way to find the latest data - they see multiple copies of "my_table" with a random string suffix.
What I'd like to do is always output to one set location for my snapshot, and effectively overwrite the data each day. That way my analysts will always be looking at the latest version of the data.  The only way I can see this working is to output the snapshots to a "staging" type area, and have some sort of job that moves the latest data each morning.  Has anyone found a better way to do this?

Did you ever come to a solution for this? This sounds exactly like what I'm running in to right now.

Sort of yes. What we've ended up doing is landing the snapshots with the different folder names (as there does not seem to be anyway to stop this) but then we have a Lambda that will;

Delete all of the data in that bucket folder except the latest i.e. martin-snapshot-2021-11-21 will all get removed leaving only martin-snapshot-2021-11-22
Delete the Glue tables that the crawler created (as these point to the old data I deleted)

Time this so the process is done before your Crawler runs (ours runs once day at 4am, so we run this at about 3am) and then when it runs there is only one folder of data (the latest) and so that gets created without any nasty suffixes.
It feels slightly hacky, but it works perfectly for us - so until a better solution presents itself this is what we're doing.

+1 we have a similar use case and wish there was a less-hacky solution, such as a parameter that would remove the unique export identifier from the output filename convention.


Seed not working with np.random.randint only if parallel=True

[x] I have tried using the latest released version of Numba (most recent is
visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
[x] I have included a self contained code sample to reproduce the problem.
i.e. it's possible to run as 'python bug.py'.

Versions
python==3.10.11
numba==0.57.0
numpy==1.24.1

When using np.random.randint the numba seed only works correctly when not using parallel=True.
This works as expected, both arrays are the same.
from numba import jit
import numpy as np

@jit(nopython=True)
def seed(a):
    np.random.seed(a)

@jit(nopython=True, parallel=False)
def f(n):
    '''Numpy randint
    '''
    return np.random.randint(0, 20, size = n)

seed(1)
print(f(5)) -> [ 5 11 12  8  9]
seed(1)
print(f(5)) -> [ 5 11 12  8  9]

Once we put parallel=True the seed no longer works.
from numba import jit
import numpy as np

@jit(nopython=True)
def seed(a):
    np.random.seed(a)

@jit(nopython=True, parallel=True)
def f(n):
    '''Numpy randint
    '''
    return np.random.randint(0, 20, size = n)

seed(1)
print(f(5)) -> [ 5 11 14 18  9] # these numbers might differ since seed is not working
seed(1)
print(f(5)) -> [ 5 11  6  3 13] # these numbers might differ since seed is not working

Expected behaviour: both arrays should be the same.

ping @DrTodd13. Is parfors changing the randint implementation here?

Noting behavior of np.random.randint with parallel=True:

The np.random.randint call is converted into a parfor gufunc such that the work is splitted among the threads. https://github.com/numba/numba/blob/e4ff3cf5fcb59e91fc7d46c340f2e7eb664dd0c0/numba/parfors/parfor.py#L1996-L1997
Each thread is initializing the seed in TLS slot https://github.com/numba/numba/blob/e4ff3cf5fcb59e91fc7d46c340f2e7eb664dd0c0/numba/_random.c#L122
Initialization is race-free due to protection from the GIL https://github.com/numba/numba/blob/e4ff3cf5fcb59e91fc7d46c340f2e7eb664dd0c0/numba/_random.c#L196

Because the randint work is distributed to threads but the seed is not broadcasted to the threads, each thread is starting with a different seed. Only the main thread see the seed the user set.

Based on @sklam's description above, it sounds like this is a bug - @DrTodd13 any thoughts on this issue?


integrations: Add webhook code, API endpoint, and tests for mention

The fixture is from another pull request that hasn't yet been merged. That should be merged first, and then I'll remove the fixture from this commit (will it have any effect if there is no diff?).

Automated message from Dropbox CLA bot
@fazerlicourice7, it looks like you've already signed the Dropbox CLA. Thanks!

So does the commit need to be edited and the fixture removed? Or is it fine the way it is?

You're fine, the next time your code is rebased onto master, it'll automatically drop the duplicate fixture.

Ok, cool.

@fazerlicourice7 it looks like you've got some lint/mypy errors as noted by Travis CI.

I encountered some mypy errors in tools/deprecated/iframe-bot/show-last-message and reported it to @mjec , he told me it's unrelated to my code and can be ignores.

A bunch commits have just changed the text_type to Text in those directories. Can you change them. Otherwise looks good to me.

@pweaver Do you mean the import line? from six import text_type

Yes, add from typing import Text if it is not already imported.
and change all the text_types to Text

Thanks for making the changes @fazerlicourice7!

Can this be merged before any merge conflicts arise?

Merged, thanks @fazerlicourice7!


PROD Issue - Batch Job Issue: Published FOMs Did Not Get Switched To Commenting Open On Opening Date.

Describe the Bug
Julius reported that a FOM in Published state but commenting opening date is today in production did not get changed to status to be Commenting Open.
Expected Behaviour
Status should be Commenting Open.
Actual Behaviour
Still on Published status.
** Steps To Reproduce**
See screenshot below (Production)
Screenshots

Additional context

As of today FOM also havs pending changes in pipeline TEST.
Additional related tickets: #561 , #562

Issue and Solution:
This issue is cased by the cronjob uses wrong image. As shared in #562, the cronjob pulls image from GitHub image registry, with the latest "test" tag. However, since we're doing some recent improvement and test deployment, the latest "test" tag image has all our new features. The cronjob argument got changed, so the checks to run the state change cronjob failed and it can't be triggered anymore.
And if we check the api deployment config, it's pulling the image from the Openshift image stream. It uses the latest "test" image when we did prod deployment last time, which is expected.
So in the fix ticket #562, pr #568, we updated the api/openshift.deploy.yml, to let cronjob pull the image from Openshift image stream as well. The workflow works as below:

Currently when we merge a pr, it will do test deployment (.github/workflows/merge-main.yml)
And when the pr merged to main and closed, it will set "test" tag to the image (.github/workflows/pr-close.yml)
When we do prod deployment, it will push the latest "test" tag image from GHCR to Openshift image stream
And after prod deployment, it will set the "prod" tag to the latest "test" tag image we used for prod deployment
So as long as both cronjob and api are pulling image from the Openshift image stream, our test deployment won't impact them anymore. We only push "test" tag image to Openshift image stream when doing prod deployment.

Deployment Condition
We did a PROD deployment on Wednesday to get all business required feature improvement in prod. And that make the cronjob argument works again to trigger the cronjob. So this problem is solved temporarily.
The complete fixes are done in pr #568, and it's merged to main and deployed in test now. We still need to deploy the fix to production to avoid getting the same issue in the feature.


Is the description of highlight correct?

https://docs.microsoft.com/en-us/azure/search/search-pagination-page-layout
This page says the highlight will be

But I got
'super bowl is super awesome with a bowl of chips'
which contains 2

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: e12a8976-0a1d-c1ea-994d-ddc57d6e468b
Version Independent ID: cb0473e9-8f4f-3eab-13fc-dd36f7bf2e20
Content: How to work with search results - Azure Cognitive Search
Content Source: articles/search/search-pagination-page-layout.md
Service: cognitive-search
GitHub Login: @HeidiSteen
Microsoft Alias: heidist

@yuanweilei  Yes, you are correct!  I will update the docs. Thank you for letting us know.

@yuanweilei   The doc update is now live:  https://docs.microsoft.com/en-us/azure/search/search-pagination-page-layout#new-behavior-starting-july-15
Closing this issue.
#please-close

@RyanHill-MSFT Hi, I resolved and closed this issue earlier this morning.  Wondering if those labels should be removed, or are they needed for reporting purposes??

Hi @HeidiSteen, needed for reporting.

@HeidiSteen, @RyanHill-MSFT
Thank you team!


Load paths config before webpack config.

The paths config doesn't really work unless you load it before the webpack config, since a bunch of paths config values are used in the webpack config module, synchronously during module loadtime. You can ctrl+F for paths. in this file to see what I mean.
When I rearranged these, my code started working.

Who's up for reviewing this?
Also Hi @benwiley4000 we met at ForwardJS on Ottawa last year.

@timarney hey Tim! I had spaced but I remember seeing it was you maintaining this. Hope you're surviving quarantine alright! 😄

Let me know if there's anything else I'll need to add to the PR. I think the change is pretty minimal but I guess there's a possibility it could break someone's code if they were expecting to rewire the paths config based on something read out of the webpack config.. that sounds pretty nasty to me though, so I sort of doubt it.

Will get this published as soon as I can.

Thank you!

react-app-rewired
2.1.6

Thanks!


Setting amount for output stack

The wiki lists two different methods under IItemStack amounts - .amount(int amount) and .withAmount(int amount) - but doesn't explain the difference (is there one?) between them. The "returns" line only reads A new IItemStack with the changed property. In (much) older version, I recall that one of them was for an input filter and one was to set an output stack's quantity, is this still true or are they now equivalent?

Originally, .withAmount was called when using the  * Operator.
.amount was the alternative way of calling the method.
With changes in ZS both annotations could be used on one method so now they still do the same, they create a new IItemStack object with the new stack size.

Closing this issue as no further questions were asked.
If this is incorrect, please reply to this issue and it will be reopened.


Open WSA sideloader

Describe your request
I think adding an option to launch your Side-loader app, would streamline things. Having all your WSA needs right in one panel would be great!

I was thinking of doing that, but I need to find a way to detect if WSA Sideloader is installed, and if not it should prompt the user to download it. I'll see what I can do about this

Consider wsa pacman as an option for this too.

As Microsoft has discontinued work on the subsystem, this application is now in maintenance mode, meaning no new updates will be released apart from bug fixes. For more information please see #22. Thank you for your understanding and sorry if this decision disappointed you.


2-3: is six a dependency or do we ship it?

In the branch https://github.com/sjsrey/pysal/tree/py3merge the tests complain about six not being available. pip install fixes this but as it stands, if we released the 3 version of pysal this would require six as a hard dependency. Since it is only a single file, do we want to include it explicitly?

Link to tests?
I could try to patch around it. If I recall correctly, I'm just using it in two patterns:

version stuff which could get replaced with if int(sys.version[0]) < 3 or something like that.
range/zip in pyDbfIO which I think gets caught by 2to3.

I know it's one file, but that difference is so small, it would be easy to fix.

Grep tells me it's here:
Binary file ./pysal/examples/virginia/virginia_queen.mat matches
./pysal/core/IOHandlers/tests/test_pyDbfIO.py:from six.moves import range
./pysal/core/IOHandlers/tests/test_pyDbfIO.py:from six.moves import zip
./pysal/core/IOHandlers/tests/test_csvWrapper.py:import six
./pysal/core/IOHandlers/tests/test_csvWrapper.py:        if six.PY2:
./pysal/core/IOHandlers/tests/test_csvWrapper.py:        elif six.PY3:
./pysal/core/util/tests/test_shapefile.py:import six
./pysal/core/util/tests/test_shapefile.py:if six.PY3:
./pysal/core/util/tests/test_shapefile.py:elif six.PY2:
./pysal/core/util/tests/test_shapefile.py:    if six.PY3:
./pysal/core/util/tests/test_shapefile.py:    elif six.PY2:
./pysal/core/util/shapefile.py:import six
./pysal/core/util/shapefile.py:if six.PY3:
./pysal/core/util/shapefile.py:elif six.PY2:
./pysal/core/util/shapefile.py:    if six.PY2:
./pysal/core/util/shapefile.py:    elif six.PY3:

I've got a cleaned version running through tests here.

sjsrey/pysal#16 removes six.


Cannot use focus() on Android TV

I'm trying to build a React Native app for Android TV. In some parts of app I need to manually focus on some elements. But if I try to focus on any of them using refs, an error appears:
"Illegal number of arguments for 'UpdateHotspot' command".
For some reason, focusing on TextInput does work as expected, focusing on another components does not.
React Native version:
System:
OS: Windows 8.1 6.3.9600
CPU: (8) x64 Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
Memory: 945.05 MB / 15.90 GB
Binaries:
Node: 12.10.0 - C:\Program Files\nodejs\node.EXE
Yarn: 1.17.3 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
npm: 6.10.3 - C:\Program Files\nodejs\npm.CMD
SDKs:
Android SDK:
API Levels: 17, 23, 25, 27, 28, 29
Build Tools: 27.0.3, 28.0.3, 29.0.2
System Images: android-17 | MIPS, android-17 | Google APIs Intel x86 Atom,
android-19 | Google APIs Intel x86 Atom, android-22 | Android TV Intel x86 Atom
, android-25 | Android TV Intel x86 Atom, android-27 | Google Play Intel x86 Ato
m, android-28 | Android TV Intel x86 Atom
IDEs:
Android Studio: Version  <IP_ADDRESS> AI-183.6<IP_ADDRESS>92245
npmPackages:
react: 16.9.0 => 16.9.0
react-native: 0.61.5 => 0.61.5
Steps To Reproduce
import React from 'react';
import {
    SafeAreaView,
    ScrollView,
    View,
    TouchableHighlight,
    Button
} from 'react-native';

class App extends React.Component {
    constructor() {
        super();
        this.focusRef = this.focusRef.bind(this);
     }

    focusRef(ref) {
        ref.focus();
    }

    render() {
        return (
            <>
                <SafeAreaView>
                    <ScrollView>
                        <View>

                            <TouchableHighlight hasTVPreferredFocus={true} ref={ref => this.focusRef(ref)}>
                                <Button title="test">
                                </Button>
                            </TouchableHighlight>
                        </View>
                    </ScrollView>
                </SafeAreaView>
            </>
        );
    }
};
export default App;

We are seeing the same issue. Has anyone found any other way to force focus on a non-textInput element on AndroidTV?


p2p crash, assertion failed in create_blockchain_synopsis_for_peer

1320944ms th_a       application.cpp:388           handle_block         ] Got block #57498 with time 2015-09-20T22:22:00 from network with latency of 944 ms from init3
1320945ms th_a       fork_database.cpp:57          push_block           ] Pushing block to fork database that failed to link: 0000e09a9341adfce9eeefa1b46b6a838103a9b8, 57498
1320945ms th_a       fork_database.cpp:58          push_block           ] Head: 57477, 0000e085250623e91e852d3f666be4c8d0b14c4f
1320945ms th_a       application.cpp:415           handle_block         ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
    {}
    th_a  fork_database.cpp:79 _push_block

    {"new_block":{"previous":"0000e099e091bb4748a0d6d20580134561b49619","timestamp":"2015-09-20T22:22:00","witness":"1.6.4","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f593a9e6e0c5bd108fb733606cdf5225867d0ecf01a66a4a5ecf8f6708e98edab3c8f3f10c4a9e9737e7cc3c00d25cd3bc6316f80eb59a8aafe44ebc7ea193523","transactions":[]}}
    th_a  db_block.cpp:195 _push_block
1321000ms th_a       witness.cpp:188               block_production_loo ] Not producing block because I don't have the private key for GPH6TnCjniG8UnHakPFDvz12BicGd1pYC2DFJFc8mbHNKKva25pV2
1321797ms th_a       application.cpp:388           handle_block         ] Got block #57498 with time 2015-09-20T22:22:00 from network with latency of 1797 ms from init3
1321797ms th_a       fork_database.cpp:57          push_block           ] Pushing block to fork database that failed to link: 0000e09a9341adfce9eeefa1b46b6a838103a9b8, 57498
1321797ms th_a       fork_database.cpp:58          push_block           ] Head: 57477, 0000e085250623e91e852d3f666be4c8d0b14c4f
1321798ms th_a       application.cpp:415           handle_block         ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
    {}
    th_a  fork_database.cpp:79 _push_block

    {"new_block":{"previous":"0000e099e091bb4748a0d6d20580134561b49619","timestamp":"2015-09-20T22:22:00","witness":"1.6.4","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f593a9e6e0c5bd108fb733606cdf5225867d0ecf01a66a4a5ecf8f6708e98edab3c8f3f10c4a9e9737e7cc3c00d25cd3bc6316f80eb59a8aafe44ebc7ea193523","transactions":[]}}
    th_a  db_block.cpp:195 _push_block
1322000ms th_a       witness.cpp:188               block_production_loo ] Not producing block because I don't have the private key for GPH6TnCjniG8UnHakPFDvz12BicGd1pYC2DFJFc8mbHNKKva25pV2
1323006ms th_a       witness.cpp:182               block_production_loo ] Not producing block because it isn't my turn
1323007ms th_a       application.cpp:388           handle_block         ] Got block #57499 with time 2015-09-20T22:22:03 from network with latency of 7 ms from init4
1323007ms th_a       fork_database.cpp:57          push_block           ] Pushing block to fork database that failed to link: 0000e09b3fb9a4616e37cf1d5555e3f9e821e6c2, 57499
1323007ms th_a       fork_database.cpp:58          push_block           ] Head: 57477, 0000e085250623e91e852d3f666be4c8d0b14c4f
1323008ms th_a       application.cpp:415           handle_block         ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
    {}
    th_a  fork_database.cpp:79 _push_block

    {"new_block":{"previous":"0000e09a9341adfce9eeefa1b46b6a838103a9b8","timestamp":"2015-09-20T22:22:03","witness":"1.6.5","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"204ef78f8d63f96d1b1432464916c1036ad1f33a36f46c03def1a9d71b2e3c5dd90f44f7d501aba3b6ecc6258ba07f0b0912c9040bf57aaf5938f00fcf435b33dd","transactions":[]}}
    th_a  db_block.cpp:195 _push_block
1323032ms th_a       application.cpp:388           handle_block         ] Got block #57499 with time 2015-09-20T22:22:03 from network with latency of 32 ms from init4
1323033ms th_a       fork_database.cpp:57          push_block           ] Pushing block to fork database that failed to link: 0000e09b3fb9a4616e37cf1d5555e3f9e821e6c2, 57499
1323033ms th_a       fork_database.cpp:58          push_block           ] Head: 57477, 0000e085250623e91e852d3f666be4c8d0b14c4f
1323033ms th_a       application.cpp:415           handle_block         ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
    {}
    th_a  fork_database.cpp:79 _push_block

...

1332948ms th_a       application.cpp:388           handle_block         ] Got block #57502 with time 2015-09-20T22:22:12 from network with latency of 948 ms from in.abit
1332948ms th_a       fork_database.cpp:57          push_block           ] Pushing block to fork database that failed to link: 0000e09e3c338a8994a5644a05d407b655c328d8, 57502
1332948ms th_a       fork_database.cpp:58          push_block           ] Head: 57477, 0000e085250623e91e852d3f666be4c8d0b14c4f
1332949ms th_a       application.cpp:415           handle_block         ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
    {}
    th_a  fork_database.cpp:79 _push_block

    {"new_block":{"previous":"0000e09d9599fa4d57f40e5011fa6d426cd5101e","timestamp":"2015-09-20T22:22:12","witness":"1.6.5247","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f73a86b31d00e765cd40af03f0a52be6047300cdc01352bd98a15ff87e804adea05d1f59d1122f5b5a6f24c46483484051ebb3f78475cd8ab206ba2a716922634","transactions":[]}}
    th_a  db_block.cpp:195 _push_block
1333000ms th_a       witness.cpp:188               block_production_loo ] Not producing block because I don't have the private key for GPH81b62rrJZNvEtoQAKMywbmLvj1DdcxBqAsedGeXZcR6kZrN5WT
1333592ms th_a       application.cpp:388           handle_block         ] Got block #57502 with time 2015-09-20T22:22:12 from network with latency of 1592 ms from in.abit
1333592ms th_a       fork_database.cpp:57          push_block           ] Pushing block to fork database that failed to link: 0000e09e3c338a8994a5644a05d407b655c328d8, 57502
1333592ms th_a       fork_database.cpp:58          push_block           ] Head: 57477, 0000e085250623e91e852d3f666be4c8d0b14c4f
1333593ms th_a       application.cpp:415           handle_block         ] Error when pushing block:
3080000 unlinkable_block_exception: unlinkable block
block does not link to known chain
    {}
    th_a  fork_database.cpp:79 _push_block

    {"new_block":{"previous":"0000e09d9599fa4d57f40e5011fa6d426cd5101e","timestamp":"2015-09-20T22:22:12","witness":"1.6.5247","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f73a86b31d00e765cd40af03f0a52be6047300cdc01352bd98a15ff87e804adea05d1f59d1122f5b5a6f24c46483484051ebb3f78475cd8ab206ba2a716922634","transactions":[]}}
    th_a  db_block.cpp:195 _push_block
1334000ms th_a       witness.cpp:188               block_production_loo ] Not producing block because I don't have the private key for GPH81b62rrJZNvEtoQAKMywbmLvj1DdcxBqAsedGeXZcR6kZrN5WT
1334177ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e07be602e73230e329757b89802d387c7ecf","0000e081e8247a87a465e605d2c2a58c851043ee","0000e084246f90baf96c43ed5b873ab6b6da7194","0000e086ea3d2267a8baff
17dabe8543e82daaad"]
1334177ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e07be602e73230e329757b89802d387c7ecf","0000e081e8247a87a465e605d2c2a58c851043ee","0000e084246f90baf96c43ed5b873ab6b6da7194","0000e086ea3d2267a8baff17dabe8543e82daaad"]
1334178ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e07be602e73230e329757b89802d387c7ecf","0000e081e8247a87a465e605d2c2a58c851043ee","0000e084246f90baf96c43ed5b873ab6b6da7194","0000e086ea3d2267a8baff17dabe8543e82daaad"]
1334178ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e07be602e73230e329757b89802d387c7ecf","0000e081e8247a87a465e605d2c2a58c851043ee","0000e084246f90baf96c43ed5b873ab6b6da7194","0000e086ea3d2267a8baff17dabe8543e82daaad"]
1334178ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e07be602e73230e329757b89802d387c7ecf","0000e081e8247a87a465e605d2c2a58c851043ee","0000e084246f90baf96c43ed5b873ab6b6da7194","0000e086ea3d2267a8baff17dabe8543e82daaad"]
1334179ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e07be602e73230e329757b89802d387c7ecf","0000e081e8247a87a465e605d2c2a58c851043ee","0000e084246f90baf96c43ed5b873ab6b6da7194","0000e086ea3d2267a8baff17dabe8543e82daaad"]
1334179ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e07be602e73230e329757b89802d387c7ecf","0000e081e8247a87a465e605d2c2a58c851043ee","0000e084246f90baf96c43ed5b873ab6b6da7194","0000e086ea3d2267a8baff17dabe8543e82daaad"]
1334179ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e07be602e73230e329757b89802d387c7ecf","0000e081e8247a87a465e605d2c2a58c851043ee","0000e084246f90baf96c43ed5b873ab6b6da7194","0000e086ea3d2267a8baff17dabe8543e82daaad"]
1334179ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e07be602e73230e329757b89802d387c7ecf","0000e081e8247a87a465e605d2c2a58c851043ee","0000e084246f90baf96c43ed5b873ab6b6da7194","0000e086ea3d2267a8baff17dabe8543e82daaad"]
1334181ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e07be602e73230e329757b89802d387c7ecf","0000e081e8247a87a465e605d2c2a58c851043ee","0000e084246f90baf96c43ed5b873ab6b6da7194","0000e086ea3d2267a8baff17dabe8543e82daaad"]
1334181ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e07be602e73230e329757b89802d387c7ecf","0000e081e8247a87a465e605d2c2a58c851043ee","0000e084246f90baf96c43ed5b873ab6b6da7194","0000e086ea3d2267a8baff17dabe8543e82daaad"]
1334181ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e07be602e73230e329757b89802d387c7ecf","0000e081e8247a87a465e605d2c2a58c851043ee","0000e084246f90baf96c43ed5b873ab6b6da7194","0000e086ea3d2267a8baff17dabe8543e82daaad"]
1334182ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e07be602e73230e329757b89802d387c7ecf","0000e081e8247a87a465e605d2c2a58c851043ee","0000e084246f90baf96c43ed5b873ab6b6da7194","0000e086ea3d2267a8baff17dabe8543e82daaad"]
1334182ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e07be602e73230e329757b89802d387c7ecf","0000e081e8247a87a465e605d2c2a58c851043ee","0000e084246f90baf96c43ed5b873ab6b6da7194","0000e086ea3d2267a8baff17dabe8543e82daaad"]
1334182ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e07be602e73230e329757b89802d387c7ecf","0000e081e8247a87a465e605d2c2a58c851043ee","0000e084246f90baf96c43ed5b873ab6b6da7194","0000e086ea3d2267a8baff17dabe8543e82daaad"]
1334185ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e07ca3a70f4b2a07bf791a51d25153f93135","0000e0828bf9df86c466d0d3323e4210e957b9f3","0000e085250623e91e852d3f666be4c8d0b14c4f","0000e087b92fc9a60566a4fd4d5005f6cd596a42"]
1334185ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e07ca3a70f4b2a07bf791a51d25153f93135","0000e0828bf9df86c466d0d3323e4210e957b9f3","0000e085250623e91e852d3f666be4c8d0b14c4f","0000e087b92fc9a60566a4fd4d5005f6cd596a42"]
1334186ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e07ca3a70f4b2a07bf791a51d25153f93135","0000e0828bf9df86c466d0d3323e4210e957b9f3","0000e085250623e91e852d3f666be4c8d0b14c4f","0000e087b92fc9a60566a4fd4d5005f6cd596a42"]
1334195ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334196ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334197ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334197ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334197ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334198ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334199ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334199ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334200ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334201ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334201ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334202ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334202ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334202ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334203ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334204ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334205ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334205ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334206ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334206ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334206ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334208ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334209ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334209ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334209ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334210ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334211ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334212ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194"]
1334212ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
1334213ms th_a       application.cpp:695           get_blockchain_synop ] synopsis: ["0000e084246f90baf96c43ed5b873ab6b6da7194","0000e08ae843312f92483c524b5c702e0d4d2d39","0000e08d97746a8cda79a3864f7f08897961408a","0000e08fde5ee42c7a6a3c3be1d62cfe5455baf8"]
witness_node: /home/cc/graphene/src/graphene/libraries/net/node.cpp:2319: std::vector<fc::ripemd160> graphene::net::detail::node_impl::create_blockchain_synopsis_for_peer(const graphene::net::peer_connection*): Assertion `synopsis.back() == original_ids_of_items_to_get->back()' failed.

As this no longer crashes, I think I'll close this.


Cleanup code for solarpilot app open source

removing extraneous code, cleaning up header files, removing plant and TES from solarpilot calculations to focus only on solar field

Build fails on linux


Archive post forecast

Not sure how we'll handle notifications yet, so I left a very general sentence. We can modify it later, when we will have more retrospect on our use


Don't allow request to proceed from network/cache if fields missing

Closes https://github.com/apollographql/apollo-android/issues/466
There is currently a bug where if a request has all @nullable fields and has never been executed before, and is executed with CACHE_FIRST, we will resolve null from cache and never go to network.
Per the graphql spec, requested fields should never be missing -- only null. Addtionally, we respect this in the cache, and store null when the server returns null.
As this is part of the GQL spec, if the server returns missing fields, we should throw an exception.
If there are missing fields when reading from the cache, this is a cache miss. This is an important case because if all the objects in a query are nullable, the cache needs to be able to differentiate between valid nullability, and nullability because a request has never been executed.

Also, this is how iOS operates: https://github.com/apollographql/apollo-ios/blob/b3cf1c6252caf96d87884ef7d070653cdc9740bc/SharedTests/LoadQueryFromStoreTests.swift#L46


Dump gimme output to ~/.bashrc

So that debug session can read it and set up Go runtime environment

Tested:
Run individual commands; or execute configured build phases
with `travis_run_*` functions (e.g., `travis_run_before_install`).

For more information, consult https://docs.travis-ci.com/user/running-build-in-debug-mode/, or email<EMAIL_ADDRESS>
travis@testing-docker-2741a1a4-ef69-4f60-8d1d-331e90ccaa93:~/gopath/src/github.com/BanzaiMan/travis_staging_test$ go version
go version go1.8 linux/amd64
travis@testing-docker-2741a1a4-ef69-4f60-8d1d-331e90ccaa93:~/gopath/src/github.com/BanzaiMan/travis_staging_test$


fix potential memory leak of AudioStreamPlaybackBusDetails

I found this one with scan-build. AudioServer::start_playback_stream() potentially leaks an instance of AudioStreamPlaybackBusDetails if an error is encountered within the for loop.

Hopefully the way I did this makes sense, happy to revise if not :smile:

Thanks!


Should not keep user logged in, if password was changed on his account.

Ghost should not keep user logged in, if password was changed on his account.
Issue Summary
When one human changes password for specific user, any other people, who are logged in that user aren't logged out but still logged in and can still do anything.
Steps to Reproduce (2 humans)

One person logs in your website with your account, which is powered by Ghost,
You change your password,
Another person who has logged in is still there and can do any kind of stuff.

Because of that, I think, ghost needs to log out all people, who are logged in one account, where password was changed, except of the one who changed password.
Technical details:

Ghost Version: 0.7.5
Client OS: Windows 8.1
Server OS: Ubuntu 15.10, with nginx that adds SSL and some custom error pages, inside Microsoft Azure
Node Version: 0.10.40
Browser: Google Chrome Version 48.0.2564.82 m
Database: SQLite

I'm actually a little surprised that Ghost doesn't do this already. Going to spin up a demo instance and test this out.

AustinPaquette, I tried this on my phone (I reopened browser) while changing password on PC, they are on different networks.

@wowse It wouldn't be a network related issue, it would be invalidating the active session(s) when a password change occurs. I don't think device type, or connectivity details would play much (if any?) of a role here.

AustinPaquette, right, I didn't mean to add additional info about devices.

@wowse If you sign out by clicking the drop-down in the top left and selecting "Sign Out" then you will be signed out on all devices as the session/authorization keys are deleted from the database.

@kevinansfield, are you talking about Ghost Pro, self-hosted, or both? It doesn't do so for me on self-hosted blog on nginx with sqlite, and despite that, still, it should automatically log out.

@wowse can you please update your issue to include details of your Ghost setup? E.g. are you on 0.7.5 or master?
There is a bug report template in our contributing guidelines that should give you a good idea what sorts of info to include.

@ErisDS, yes, I've updated post so it fits to template, thanks for response.

@kevinansfield This is not correct. When you sign out it will only delete the current access_token (https://github.com/TryGhost/Ghost/blob/master/core/server/api/authentication.js#L314). You can easily test this by opening a second tab in incognito mode, logging in, and hitting sign out on your second tab. You will still be logged in on the second tab (as I would expect). Hitting sign out on one devise/browser should not log you out on a different devise/browser.
Maybe this is a misunderstanding - the issue is specifically talking about changing your password, in which case I agree that we should clear out all access/refresh tokens of that user to log out other currently active sessions.

Yeah, my bad, I think I'd opened the user.js file instead of the authentication.js file :flushed:

@kevinansfield Why you do not commit on this issue?

@loskiq Ghost is open source, if you want to see something fixed you're more than welcome to submit a PR.

@ErisDS Isn't that a task of ghost developers?

@ErisDS I'm not a programmer. I just use your engine.

This is an Open Source Software project, backed by a not-for-profit foundation. The tiny team of developers who work for the foundation is hard at work managing a balancing act of new features, bug fixing and infrastructure.
If you have an interest in seeing something particular fixed faster than we're going to fix it, you're more than welcome to submit a PR. If you aren't a software developer, then consider contributing in some other way to ease the burden on our developers so that they can fix more things. There's lots of info here and here.
By writing comments like this here on GitHub, you achieve little more than requiring a team member to put down whatever it is they are working on to come and reply to you.

What would be the best approach to this?

Deleting all the tokens for the user, generate a new one and let the application update the token.
or
Delete all the token except the one of the current session.

In my opinion the latter is the best but has more impact to the code because the token is not passed to the API and is the only value which discriminate the different sessions

If code impact isn’t too huge, second is the best solution.
Sent from Windows Mail
From: Fabrizio Ruggeri
Sent: Tuesday, February 9, 2016 6:13 AM
To: TryGhost/Ghost
Cc: tuturu♪
What would be the best approach to this?
Deleting all the tokens for the user, generate a new one and let the application update the token.
or
Delete all the token except the one of the current session.
In my opinion the latter is the best but has more impact to the code because the token is not passed to the API and is the only value which discriminate the different sessions
—
Reply to this email directly or view it on GitHub.

@allouis / @kevinansfield With the new authentication methods on the v2 API, does this become easier to implement?
I suggest we close this as it was suggested by the community 3 years ago.

It was in the spec for the new auth but I don't think the todo item was checked off. @allouis could you confirm and open a new issue if necessary?

closing in favour of https://github.com/TryGhost/Ghost/issues/10323


Use PyPI archive after upstream fixed packing issues

[x] I read the conda-forge documentation and could not find the solution for my problem there.

Issue:

Environment (conda list):

$ conda list

Details about  conda and system ( conda info ):

$ conda info

c.f. predictive-analytics-lab/data-science-types#204, predictive-analytics-lab/data-science-types#205

closed by #2


stalker portal

I tried several stalker portals, but none of them open.
It reports an error:
Ooops, no content here, please change the category or content type.
All portals work in other players.

Same here :(
great app though, if only that worked and the possibility to record the stream, that would be perfect :)

same error "Ooops, no content here, please change the category or content type."

Same error with the Mac OS version
Do you have a solution to offer ?
Thanks

same issue here

Tested with ministra 5.6.0, same issue

It also gives me the same problem, other times it tells me the account is expired. The problem depends on the program because with the same MAC I can see everything perfectly with the app "stalker_player".
I hope they fix it because I prefer the look of iptvnator.

Same issue on 0.15.1, @4gray just so you're aware. Thanks!


fix rubocop offenses

This fixes our Rubocop offenses. Basically this is just a single pass of
bundle exec rubocop -a

Just noticed the CI failures, looking through them

👍 sounds good, I'll squash and merge once build passes

Argh - there's no update! in Rails 3 of course 😞 - fixed and should be good now