Imports and the scriptable event handler use case combined with REPL

I have an issue with an application that implements the scriptable event handler use case and also provides a REPL interface:
The book recommends that imports be placed at the top of the script: https://rhai.rs/book/language/modules/import.html#admonition-place-import-statements-at-the-top
REPL implementations typically use AST::clear_statements() to prevent statements from being executed twice.
After clear_statements has been called any imports at top level will be gone from the AST causing event handler functions that depends on the global imports to fail.
One approach that I tried to circumvent this is to add the loaded script into a global module similar to how the Rhai REPL does things. However it seems that script functions in a global module cannot be directly accessed from rust side preventing me from calling them using Engine::call_fn().
Am I missing something or is this use-case simply not supported unless the imports are placed inside the event handler functions?

You cannot call a native Rust function via call_fn.  The idea is that it is much easier to just call the Rust version instead of going through Rhai.

Ok, here is another example with the function defined in a Rhai script which still does not work:
Executing: cargo run --release --bin rhai-repl --features rustyline -- testing.rhai
testing.rhai:
fn testing() {
	print("Works");
}

Changes:
diff --git a/src/bin/rhai-repl.rs b/src/bin/rhai-repl.rs
index 6a1215c7..6959e6b7 100644
--- a/src/bin/rhai-repl.rs
+++ b/src/bin/rhai-repl.rs
@@ -596,6 +596,10 @@ fn main() {

         // Throw away all the statements, leaving only the functions
         main_ast.clear_statements();
+
+        engine
+            .call_fn::<()>(&mut scope, &main_ast, "testing", ())
+            .expect("Failed...");
     }

     rl.save_history(HISTORY_FILE)

Output:
Rhai REPL tool (version 1.20.0)
===============================
Script 'testing.rhai' loaded.

help       => print this help
quit, exit => quit
keys       => print list of key bindings
history    => print lines history
!!         => repeat the last history line
!<#>       => repeat a particular history line
!<text>    => repeat the last history line starting with some text
!?<text>   => repeat the last history line containing some text
scope      => print all variables in the scope
strict     => toggle on/off Strict Variables Mode
optimize   => toggle on/off script optimization
ast        => print the last AST (optimized)
astu       => print the last raw, un-optimized AST

press Ctrl-Enter or end a line with `\`
to continue to the next line.

repl> testing();
Works
thread 'main' panicked at src/bin/rhai-repl.rs:602:14:
Failed...: ErrorFunctionNotFound("testing", none)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

That would be interesting.  Can you put a testing(); inside the script to see if it works?
Also you can dump the function signatures to see if testing is properly seen...

Sure,
Updated script:
fn testing() {
	print("Works");
}

testing();

Executing: cargo run --release --bin rhai-repl --features rustyline --features metadata -- testing.rhai
Changes:
diff --git a/src/bin/rhai-repl.rs b/src/bin/rhai-repl.rs
index 6a1215c7..6959e6b7 100644
--- a/src/bin/rhai-repl.rs
+++ b/src/bin/rhai-repl.rs
@@ -596,6 +596,10 @@ fn main() {

         // Throw away all the statements, leaving only the functions
         main_ast.clear_statements();
+
+        engine
+            .call_fn::<()>(&mut scope, &main_ast, "testing", ())
+            .expect("Failed...");
     }

     rl.save_history(HISTORY_FILE)

Output:
Rhai REPL tool (version 1.20.0)
===============================
Works
Script 'testing.rhai' loaded.

help       => print this help
quit, exit => quit
keys       => print list of key bindings
history    => print lines history
!!         => repeat the last history line
!<#>       => repeat a particular history line
!<text>    => repeat the last history line starting with some text
!?<text>   => repeat the last history line containing some text
scope      => print all variables in the scope
strict     => toggle on/off Strict Variables Mode
optimize   => toggle on/off script optimization
functions  => print all functions defined
json       => output all functions to `metadata.json`
ast        => print the last AST (optimized)
astu       => print the last raw, un-optimized AST

press Ctrl-Enter or end a line with `\`
to continue to the next line.

repl> functions
test(x: i64, y: i64) -> MyType
test(x: &mut i64, y: i64, z: string)
testing()

repl> testing()
Works
thread 'main' panicked at src/bin/rhai-repl.rs:602:14:
Failed...: ErrorFunctionNotFound("testing", none)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Conclusions:

Works is printed once when the module is evaluated.
Works is printed once more when testing(); is executed from the REPL.
testing() is listed when the functions is printed.
testing() is not available to Engine::call_fn.

Can you use rhai-run instead of repl?

Yes, using rhai-run would work since it does not load the file into a global module (and the REPL will also work when the function is defined through the repl> interface).
The problem I'm having is combining the event-handler pattern with a REPL wich requires that i use AST::clear_statements() which in turn removes the top-level import statements.
I tried to work around this limitation by registering the source as a global module but then discovered that it was not possible to call any of the event handler functions defined in the registered global module.

So it seems call_fn may not find functions loaded into global.  I'll take a look at that.

Thank you :slightly_smiling_face:

I'm sorry it was misleading.  call_fn only calls functions defined within the current script.
Functions inside your scripts, however, I believe should be able to call your scripts loaded into global.

Yes, it would be great however if there was a way to call a function from rust side that first attempts to call the function in the given AST and if the function was not found then attempt to call the function in the registered global modules.

Yes, it would be great however if there was a way to call a function from rust side that first attempts to call the function in the given AST and if the function was not found then attempt to call the function in the registered global modules.

I fear that may be a breaking change...


Refactor code in ViewBill.jsx to make it conform to checklists.

Please do work for this task in a branch called issue-42.

Done with refactoring. ViewBill.jsx uses a custom naming scheme for a better user experience, so some parts of the code might look redundant, but they'll have different names.


arbitrary restriction on the set of possible byte values

It would be super-flexible if there was an option where you could actually specify the keybyte values to use. 0x41 - 0x5d is for example the uppercase ASCII range. Maybe you want to do uppercase and lowercase - which cannot be specified continuously. And I don't always have a 144 core machine at hand to just include the bytes in between. Maybe the bytes to use could be specified as a single param like --bytestouse<PHONE_NUMBER>889fa0a1a2a3 etc. for 0x41, 0x42, 0x43, 0x44, 0x45, 0x18, 0x89,0xfa,0x0a,0xa1,0xa2,0xa3, etc.
Originally posted by @OevreFlataeker in https://github.com/sebastien-riou/aes-brute-force/issues/2#issuecomment-490455604

implemented, see test_restricted.sh and "usage 2" of command line, make sure the bytes are sorted in ascending order.

Works perfectly! Thank you!


Don't exclude the process object

Some npm package we depend on can at any time start expecting a property on process to exists and then break. The process polyfill is pretty small anyway.

It's a whole 6KB more! 😞


Revert "cypress: pip install ansible"

Reverts ansible/ansible-hub-ui#2355
No longer needed, https://github.com/ansible/galaxykit/pull/55 removes the ansible dependency from galaxykit again :).
Cc @hendersonreed , thanks :)

@himdel do we think that the failing cypress tests in signing.js are unrelated to galaxykit? If they're unrelated, then we can merge straightaway, I say.

Thanks, yeah, those are probably coming from the interaction of https://github.com/ansible/ansible-hub-ui/pull/2069 with https://github.com/ansible/galaxy_ng/pull/1351, and definitely happening on master as well :)


python.pkgs.backports_ssl_match_hostname_3_4_0_2: remove

Motivation for this change
We don't want multiple versions of the same package in pythonPackages.
Things done

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

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

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

The last commit is optional. Its intention is to reduce the number of rebuilds.

The last commit is optional. Its intention is to reduce the number of rebuilds.

Don't bother, it's fine when it goes to staging.


stop editing /etc/sudoers directly

Hi @kjbweb - If this is still an issue, would you be able to get this PR updated with the latest code, or can this PR be closed?

Hi @kjbweb - If this is still an issue, would you be able to get this PR updated with the latest code, or can this PR be closed?

Hi @jeffreycoe, it is by the looks of things, I've updated my fork, hope it helps.

Codecov Report

Merging #334 into master will not change coverage.
The diff coverage is 60.43%.

@@           Coverage Diff           @@
##           master     #334   +/-   ##
=======================================
  Coverage   36.76%   36.76%
=======================================
  Files          10       10
  Lines         544      544
=======================================
  Hits          200      200
  Misses        344      344

Impacted Files
Coverage Δ

lib/kitchen/docker/helpers/dockerfile_helper.rb
44.44% <ø> (ø)

lib/kitchen/driver/docker.rb
60.43% <60.43%> (ø)

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 d9db4f9...cf30fac. Read the comment docs.

@kjbweb It looks like lib/kitchen/driver/docker.rb was modified or was accidentally added to your commit. Would you be able to remove this file from the change and then squash the commits? Once that's done, we should be able to merge. Thanks!

@jeffreycoe The only made to lib/kitchen/driver/docker.rb are converting the line endings from Windows to Unix style. It was probably done by the submitter's local .gitconfig, but it does (appear to) bring that file in-line with the rest of the code base.

@joshuariojas Thanks Josh. I reviewed it as well and it looks to be fine. I'll merge this PR.


adds detail

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

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

Thanks for adding more details to this guide. They are relevant and helpful.

Please open a new PR for adding the image. Thanks.


Improvements to ApplicationStartup.

Added a try-catch block to "FindMethod" which will allow further error-handling.
Also catching AmbiguousMatchException which occurs when multiple occurences of "Configure" (of example) are present. This will solve issue #212

Hi @rausmaus, I'm your friendly neighborhood Microsoft Open Technologies, Inc. Pull Request Bot (You can call me MSOTBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla2.msopentech.com.

TTYL, MSOTBOT;

@rausmaus, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR.
Thanks, MSOTBOT;

Oh yes, VS2015 has messed it up. I will try to fix.

Formatting now fixed.

Can you also add a unit test for this in similar to the ones here?
https://github.com/aspnet/Hosting/blob/dev/test/Microsoft.AspNet.Hosting.Tests/StartupManagerTests.cs

@HaoK having trouble running the .sln, looks xproj-related. Will have a look as soon as i have it running. :smile:

This needs a rebase on top of dev, @HaoK checked in some big changes

Hi @rausmaus, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla2.dotnetfoundation.org.

TTYL, DNFBOT;

This has been handled by a separate PR.


[Feature Request] Sortable by Each Column

Would it be possible to be able to sort all the columns in the different tabs.  It would be nice to sort on things like mpg.

@Abateman121 this is released.


app is now connected to postgresSQL

Everything is working,
Created two tables of brokenlinks and stored_recipes so that post requests will not break.

@Hazannovich Did you check that it worked? Have you ran the server and saw that it's connected?

@Hazannovich Did you check that it worked? Have you ran the server and saw that it's connected?

Yes everything is connected and working from pgadmin 4 and I can create new queries from the app with sqlalchemy


Implement to be bottom after interval

When settings interval as 5 sec in this screenshot.

After https://github.com/pankona/mobu/pull/8/commits/819868cc3600bff791ca366ef3a4a03443144eb4

🎍


Start with system

My app doesnt start with system, and there is no option for that, is it possible to add it? Thanks, in advance

Just go to Preference Panel -> Users & Groups -> Current User -> Login Items and drop Application to this list.

It works, ty

Hi. I know this issue is closed and that this is a standard macOS feature, but I was a bit confused about this and looking for the option to start with system in the Settings of CornerCal because I have a lot of status bar applications that auomate the process this way and I kinda forgot Login Items was even a thing on Mac.
Would it be possible to add this option into the Settings in a future update? I know it‘s a tiny thing; it‘s just an idea to maybe make the usability a little bit better if it isn‘t too much work.
Otherwise, if that isn’t possible or part of your plan, could one maybe just add a section to the README describing the process of adding CornerCal to the Login Items for newbies? Just like in your helpful comment. One could even just use the same text.


Defining Synonyms.

Rasa is incredible :)
Im curious to know if there is a way to define synonyms (like how it is in WIT)?

Sure - if you define entities as having the same value they will be treated as synonyms.
If you need something more sophisticated you can extend / replace the entity_synonyms component https://github.com/golastmile/rasa_nlu/blob/master/rasa_nlu/extractors/entity_synonyms.py
      {
        "text": "in the center of town",
        "intent": "search",
        "entities": [
          {
            "start": 7,
            "end": 13,
            "value": "center",
            "entity": "center"
          }
        ]
      },
      {
        "text": "in the centre of town",
        "intent": "search",
        "entities": [
          {
            "start": 7,
            "end": 13,
            "value": "centre",
            "entity": "center"
          }
        ]
      }

:+1: i've added an example to the documentation of the training data format for future reference.


Ubuntu Desktop.foo() doesn't work properly

Desktop.mail()
Desktop.open() //Used to download new patch
Desktop seems to have very little Linux support. Alternative?

https://stackoverflow.com/a/18004334
didnt work


[Feature-Request] Enhancement to Brightness control in CameraControl message

Start with the why:
Changing of gamma curve is a very useful feature to have, it could brighten up the shade area of the image to give more information for the downstream machine vision pipeline.
To my best knowledge (discussed with @Erol444 ), the gamma curve is control by Brightness within CameraControl message. And it is performed in ISP.
However, the Brightness option only works for ColorCamera, and not MonoCamera. This is pretty much unexpected and undesirable.
Move to the what:
Add support of Brightness control to MonoCamera.
Move to the how:
It would be great if MonoCamera could also be route to some ISP hw so that it can get gamma correction done.
A less ideal option, would be allow the monochrome sensor to be used as ColorCamera, but with RAW8 output. Not sure if this option is any easier to implement

CC: @alex-luxonis  on underlying controls for this
WRT common node, @chengguizi you may try camera_node, which allows for both Mono or Color sensors to be used under same interface & features (dai::node::Camera)

@themarpe Very interesting to see there is work for a unified camera_node. May I know if that branch is still in early phase, or expected to be merged to mainline soon? I guess it is quite some significant change, as it changes fundamentally how camera node is constructed
I am using a custom firmware on a custom branch, so not too easy to try that out just yet :p
In the meantime, it is still be great if we can "backport" some of the ISP features to MonoCamera, particularly this gamma correction feature.


make rosdistro accept collada-dom from gentoo's portage

dev-libs/collada-dom is provided by gentoos package management system portage.
media-libs/collada-dom is provided by ros-overlay [1] which is used in the official (although experimental) install instructions for ROS on gentoo [2].
Allowing ros to install without the over will ease/eable the transition of gentoo's ROS-support from overlay to its native repository, especially since the overlay is suspected to be redundant.
relevant issue:
https://github.com/ros/rosdistro/issues/11687
[1] https://github.com/ros/ros-overlay
[2] http://wiki.ros.org/kinetic/Installation/Gentoo (also for older ROS distros)

If multiple packages are listed, they are AND related [1] [2], therefore this pull request should not be accepted at its current state. Changing to dev-libs/collada-dom without while keeping maximum compatibility to the ros-overlay (if that is favourable) would require

fixing the version of dev-libs/collada-dom to 2.4.0 (as this is the only version available in the overlay)
transfer/merge of dependencies RDEPEND [3] as applicable

sources:
[1] http://docs.ros.org/independent/api/rosdep/html/rosdep_yaml_format.html
[2] http://www.ros.org/reps/rep-0111.html
[3]
overlay
RDEPEND="     dev-libs/boost         dev-libs/libxml2         virtual/opengl         media-libs/freeglut         >=dev-util/cmake-2.6.0         >=media-gfx/nvidia-cg-toolkit-2.0 "
portage
RDEPEND="         dev-libs/boost:=         sys-libs/zlib:=[minizip]         dev-libs/libxml2         dev-libs/libpcre[cxx] "

@allenh1 FYI

Closing this pull request since the latest change would break the old/outdated install instructions (which users probably still follow)


Where is struct Message defined?

I read the raft-rs source code in idea, but I couldn't found where struct Message defined

Therefore I couldn't  know what default value for the message.

It's a protobuf struct defined at https://github.com/tikv/raft-rs/blob/2357cb22760719bcd107a90d1e64ef505bdb1e15/proto/proto/eraftpb.proto#L71-L92.

It's a protobuf struct defined at
https://github.com/tikv/raft-rs/blob/2357cb22760719bcd107a90d1e64ef505bdb1e15/proto/proto/eraftpb.proto#L71-L92
.
Thank you very much

good


distutils.spawn.find_executable not working to find ffmpeg

🐛 Describe the bug
distutils.spawn.find_executable not working to find ffmpeg
Versions
https://github.com/pytorch/vision/blob/e8cb0bacd86c49e67a7e1a5f83c6da866bc451cf/setup.py#L343
for python 3.10,
import distutils
distutils.spawn.find_executable("ffmpeg")

outputs:
Traceback (most recent call last):
  File "<input>", line 1, in <module>
    distutils.spawn.find_executable("ffmpeg")
AttributeError: module 'distutils' has no attribute 'spawn'

so ffmpeg_exe = distutils.spawn.find_executable("ffmpeg") leads to ffmpeg_exe = None
use this instead:
from distutils import spawn
spawn.find_executable('ffmpeg')

also,
DeprecationWarning: The distutils package is deprecated an
d slated for removal in Python 3.12. Use setuptools or check PEP 632 for potent
ial alternatives

@datumbox thanks for flagging, I'll take the liberty to replace this with shutil.which as it's recommended in PEP632 migration advice

Closed via #5849


Allow for specifying colors via CSS rather than via props

Right now the colors are done via props. In order to add a color via CSS I need to render the loader like:
<ScaleLoader className="halogenium-loader" />

And then add CSS like:
.halogenium-loader {
  div {
    background-color: blue !important;
  }
}

Ideally, I wouldn't have to override all child <div/> elements using the !important rule, instead something like this would be enough:
.halogenium-loader {
  color: blue;
}

hi
interesting feature, I think it can be done in the next version

you now should be able to pass className and override color just fine


use calicoctl-util to apply manifests

Description

Calicoctl docker image is based out of the scratch image,  hence it doesn't have any Linux utils or shell. Replace shell dependency with calicoctl-util tool

Deploy preview for calico ready!

This depends on https://github.com/projectcalico/calicoctl/pull/2158
Casey and I have commented on that PR that we thought this was going to be done by adding a new feature to calicoctl to apply resources in a directory.

Closing in favor of this guy: https://github.com/projectcalico/calico/pull/3874


Stop segments leaking in cleaner

Segments were leaking - leading to file handles not being closed down properly. So benchmarks ran out of file handles.

The way you have it the segments won't be deleted in order from oldest to newest, which I don't like the idea of.

@travisjeffery Would you accept a patch that discovered the cut point, and then used slice range notation to first drop the overflow segments in the order they were added, and then to return the clean list?

The order of messages is #2 of the four guarantees of Kafka's cleaner, as per their design docs (old and under renovation, I read somewhere).
  Log compaction guarantees the following:

1. Any consumer that stays caught-up to within the head of the log will see every message that is written; these messages will have sequential offsets. The topic's min.compaction.lag.ms can be used to guarantee the minimum length of time must pass after a message is written before it could be compacted. I.e. it provides a lower bound on how long each message will remain in the (uncompacted) head.

2. Ordering of messages is always maintained. Compaction will never re-order messages, just remove some.

3. The offset for a message never changes. It is the permanent identifier for a position in the log.

4. Any consumer progressing from the start of the log will see at least the final state of all records in the order they were written. Additionally, all delete markers for deleted records will be seen, provided the consumer reaches the head of the log in a time period less than the topic's delete.retention.ms setting (the default is 24 hours). In other words: since the removal of delete markers happens concurrently with reads, it is possible for a consumer to miss delete markers if it lags by more than delete.retention.ms.

@politician I think so? I'd have to see the PR to be sure

Gonna close this PR


new minify regex code improvements

This fix actually works.

@mjauvin tests are failing

Yeah, I saw, was away for a while, I'll take a look.
On Thu, Apr 15, 2021 at 3:45 PM Luke Towers @.***>
wrote:

@mjauvin https://github.com/mjauvin tests are failing
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/wintercms/storm/pull/23#issuecomment-820687685, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAPLTPVHENNE5LH7M4CHCETTI466VANCNFSM43AACIYA
.

--
Marc

@LukeTowers Any idea why the test is failing on php 7.2 !?


CSRF verification failed. Request aborted.

We have installed DefectDojo with the Docker option in Debian 11.
Reverse proxy has been configured to protect the machine with a public ip.
After accessing with the proxy ip and login we get the following error:

After reviewing previous problems in this platform, we have realized that we have to add the CSRF_TRUSTED_ORIGINS variable, but we do not know in which file to do it, since the installation has been done on top of the docker.
This is the structure of the DefectDojo folder:

Thank you,

You can overwrite default settings using localsettings please follow https://defectdojo.github.io/django-DefectDojo/getting_started/configuration/#local_settingspy-not-with-kubernetes

Thank you!
We have been able to solve the problem, with the documentation provided.

Closing

Thank you! We have been able to solve the problem, with the documentation provided.

@isrc-team Can you share how did you resolve this issue? Did you made any changes in settings.dist.py or any other settings file you have created and what is the settings that you have added?

As the linked PR above shows, you need CSRF_TRUSTED_ORIGINS
You can set that in local_settings.py or use an environmental variable like:
DD_CSRF_TRUSTED_ORIGINS="https://my.domain.com"
More details at https://docs.djangoproject.com/en/4.0/ref/settings/#csrf-trusted-origins


VCPKG forcing Ninja

No matter how I structure my portfile.cmake Ninja is being chose by  vcpkg_configure_cmake.
Environment

OS: Linux
Compiler: gcc 11.2
Latest VCPKG latest revision

`
 find_program(GIT git)
 set(GIT_URL "xxxxxxxxxxx")
 set(GIT_REV "2a8e132e85a527603a3d6d4503ded117d5066eaf")
 message(STATUS "port: ${PORT}")
 make_directory( ${CURRENT_BUILDTREES_DIR}/src/${PORT})
 set(SOURCE_PATH ${CURRENT_BUILDTREES_DIR}/src/${PORT})

 if(NOT EXISTS "${SOURCE_PATH}/.git")
	  message(STATUS "Cloning and fetching submodules")
	  vcpkg_execute_required_process(
	    COMMAND ${GIT} clone --recurse-submodules ${GIT_URL} ${SOURCE_PATH}
	    WORKING_DIRECTORY ${SOURCE_PATH}
	    LOGNAME clone
	  )
	  message(STATUS "Checkout revision ${GIT_REV}")
	  vcpkg_execute_required_process(
	    COMMAND ${GIT} checkout ${GIT_REV}
	    WORKING_DIRECTORY ${SOURCE_PATH}
	    LOGNAME checkout
	  )
  endif()

  vcpkg_configure_cmake(
    SOURCE_PATH ${SOURCE_PATH}
     OPTIONS -DBUILD_SERVER=OFF -G "Unix Makefiles"
  )

  vcpkg_install_cmake()
  vcpkg_fixup_cmake_targets()

`
If I run cmake from the command line with -G Unix Makefiles, everything works. However, vcpkg is inserting a second -G option for Ninja  that's taking precedence
resulting output that fails
  Command failed: /usr/local/bin/cmake /home/simple_dds/vcpkg/buildtrees/nebula/src/nebula -DBUILD_NEBULA_SERVER=OFF -G "Unix Makefiles" -DCMAKE_MAKE_PROGRAM=/home/simple_dds/vcpkg/downloads/tools/ninja-1.10.2-linux/ninja -DCMAKE_SYSTEM_NAME=Linux -DBUILD_SHARED_LIBS=OFF -DVCPKG_CHAINLOAD_TOOLCHAIN_FILE=/home/simple_dds/vcpkg/scripts/toolchains/linux.cmake -DVCPKG_TARGET_TRIPLET=x64-linux -DVCPKG_SET_CHARSET_FLAG=ON -DVCPKG_PLATFORM_TOOLSET=external -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP=TRUE -DCMAKE_VERBOSE_MAKEFILE=ON -DVCPKG_APPLOCAL_DEPS=OFF -DCMAKE_TOOLCHAIN_FILE=/home/simple_dds/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION=ON -DVCPKG_CXX_FLAGS= -DVCPKG_CXX_FLAGS_RELEASE= -DVCPKG_CXX_FLAGS_DEBUG= -DVCPKG_C_FLAGS= -DVCPKG_C_FLAGS_RELEASE= -DVCPKG_C_FLAGS_DEBUG= -DVCPKG_CRT_LINKAGE=dynamic -DVCPKG_LINKER_FLAGS= -DVCPKG_LINKER_FLAGS_RELEASE= -DVCPKG_LINKER_FLAGS_DEBUG= -DVCPKG_TARGET_ARCHITECTURE=x64 -DCMAKE_INSTALL_LIBDIR:STRING=lib -DCMAKE_INSTALL_BINDIR:STRING=bin -D_VCPKG_ROOT_DIR=/home/simple_dds/vcpkg -DZ_VCPKG_ROOT_DIR=/home/simple_dds/vcpkg -D_VCPKG_INSTALLED_DIR=/home/simple_dds/vcpkg/installed -DVCPKG_MANIFEST_INSTALL=OFF -G Ninja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/home/simple_dds/vcpkg/packages/nebula_x64-linux/debug

note the -G Ninja in the second to last line. I tried adding GENERATOR "Unix Makefile" I get
  Unrecognized GENERATOR setting from vcpkg_configure_cmake().  Valid
  generators are: Ninja, Visual Studio, and NMake Makefiles

I can't change the portion that's causing an issue with Ninja since I don't own that code and it's for an older release anyway. Is there any way to run it with "Unix Makefiles" and still use vcpkg_configure_cmake?

If your repo has makefiles, you may use vcpkg_*_make instead.

Thanks for the suggestion @JackBoosY , but it only has makefiles

Why do you want to use the Makefile generator? Using Ninja is preferred inside vcpkg. You are not supposed to work with the files in the buildtree.

Ping @diehard2 for response.

@Neumann-A , I don't particularly want to use the Makefile generator, but that option works and the Ninja option doesn't. I don't particularly want to spend time figuring out why, so I was hoping to just use the option that gets me a build.
Regardless of if this is the correct approach, its clearly incorrect behavior based on both the vcpkg documentation and the cmake allowable options. "Unix Makefiles" is allowed by the cmake command line (and works) and PREFER_NINJA does nothing. Ninja is forced regardless.
Not allowing "Unix Makefiles" in Generator seems like an oversight since it's a valid option for CMake

Ninja option doesn't.

show the log.... If ninja doesn't work there is probably a bug in the CMakeLists.txt which is just hidden by the Makefile generator.

Sorry for the delay. The CMakeLists.txt calls
find_package(zstd MODULE REQUIRED)
and this in turn generates
#############################################
Custom command for thirdparty/zstd/src/zstdBuild-stamp/zstdBuild-build
build thirdparty/zstd/src/zstdBuild-stamp/zstdBuild-build | ${cmake_ninja_workdir}thirdparty/zstd/src/zstdBuild-stamp/zstdBuild-build: CUSTOM_COMMAND thirdparty/zstd/src/zstdBuild-stamp/zstdBuild-configure
COMMAND = cd /home/simple_dds/vcpkg/buildtrees/nebula/thirdparty/zstd/src/zstdBuild && $(MAKE) -j1 -C lib PREFIX=/home/simple_dds/vcpkg/buildtrees/nebula/thirdparty/zstd LIBDIR=/home/simple_dds/vcpkg/buildtrees/nebula/thirdparty/zstd/lib && /usr/local/bin/cmake -E touch /home/simple_dds/vcpkg/buildtrees/nebula/thirdparty/zstd/src/zstdBuild-stamp/zstdBuild-build
DESC = Performing build step for 'zstdBuild'
restat = 1
The error being generated is
ninja: error: build.ninja:7741: bad $-escape (literal $ must be written as $$)
But since this is all autogenerated I don't have a ton of options here for making this work (as far as I can tell) other than being able to use "Unix Makefiles" as a Generator

Ah I saw this issue before.

Can you please provide file build.ninja in your cmake binary dir?

attached
build.ninja.txt

${cmake_ninja_workdir}

Did you install ninja manullay? Can you confirm whether VCPKG_ROOT/downloads/tools/ninja-1.10.2-linux/ exists?

I did not install it manually and that directory exists

I did not install it manually and that directory exists

I'll take a look.

 Command failed: /usr/local/bin/cmake /home/simple_dds/vcpkg/buildtrees/nebula/src/nebula -DBUILD_NEBULA_SERVER=OFF -G "Unix Makefiles" -DCMAKE_MAKE_PROGRAM=/home/simple_dds/vcpkg/downloads/tools/ninja-1.10.2-linux/ninja -DCMAKE_SYSTEM_NAME=Linux -DBUILD_SHARED_LIBS=OFF -DVCPKG_CHAINLOAD_TOOLCHAIN_FILE=/home/simple_dds/vcpkg/scripts/toolchains/linux.cmake -DVCPKG_TARGET_TRIPLET=x64-linux -DVCPKG_SET_CHARSET_FLAG=ON -DVCPKG_PLATFORM_TOOLSET=external -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP=TRUE -DCMAKE_VERBOSE_MAKEFILE=ON -DVCPKG_APPLOCAL_DEPS=OFF -DCMAKE_TOOLCHAIN_FILE=/home/simple_dds/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION=ON -DVCPKG_CXX_FLAGS= -DVCPKG_CXX_FLAGS_RELEASE= -DVCPKG_CXX_FLAGS_DEBUG= -DVCPKG_C_FLAGS= -DVCPKG_C_FLAGS_RELEASE= -DVCPKG_C_FLAGS_DEBUG= -DVCPKG_CRT_LINKAGE=dynamic -DVCPKG_LINKER_FLAGS= -DVCPKG_LINKER_FLAGS_RELEASE= -DVCPKG_LINKER_FLAGS_DEBUG= -DVCPKG_TARGET_ARCHITECTURE=x64 -DCMAKE_INSTALL_LIBDIR:STRING=lib -DCMAKE_INSTALL_BINDIR:STRING=bin -D_VCPKG_ROOT_DIR=/home/simple_dds/vcpkg -DZ_VCPKG_ROOT_DIR=/home/simple_dds/vcpkg -D_VCPKG_INSTALLED_DIR=/home/simple_dds/vcpkg/installed -DVCPKG_MANIFEST_INSTALL=OFF -G Ninja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/home/simple_dds/vcpkg/packages/nebula_x64-linux/debug

...
build CMakeFiles/rebuild_cache.util: CUSTOM_COMMAND
  COMMAND = cd /home/simple_dds/vcpkg/buildtrees/nebula/x64-linux-dbg && /usr/local/bin/cmake --regenerate-during-build -S/home/simple_dds/vcpkg/buildtrees/nebula/src/nebula -B/home/simple_dds/vcpkg/buildtrees/nebula/x64-linux-dbg

FTR:

There is no port "nebula" in vcpkg.
The custom port builds zstd as a vendored dependency.
The nebula build seems to build the vendored zstd via explicit commands for Makefiles ($(MAKE)). This assumes that nebula itseld is build with make.

@dg0yt I'm attempting to build it as an internal package for vcpkg. It builds fine with cmake outside of vcpkg. Its being pulled in with the find_package command from cmake

It is a vcpkg problem. It needs to support cmake (the configuration system) with make (the build tool) for ports that assume this combination. Maybe #22597 is just the same issue, but with a port that already is part of vcpkg. But in generally, ports avoid vendored dependencies, and for other part, you don't use $(MAKE) very often.
(My old superbuild uses cmake+$(MAKE) to parallelize everything across packages and target systems.)

It is a vcpkg problem.

Not really. Just means the buildsystem is not really cmake..... CMake build scripts should be agnostic to the generator otherwise using cmake is in itself absurd.

$(MAKE)

change to ${MAKE} and do a find_program call ?

@Neumann-A  thanks, I'll try to do a patch that fixes those up. I suppose another alternative is calling cmake directly with the arguments for "Unix Makefiles"

It is a vcpkg problem.

Not really. Just means the buildsystem is not really cmake..... CMake build scripts should be agnostic to the generator otherwise using cmake is in itself absurd.

This is overstretched. cmake doesn't only specific rules from generic rules. It also deals with configuration prior to deciding which generic rules to feed into the generation.
CMake does allow to choose different systems. vpckg limits this choice in two ways:

It always sets a generator.
It doesn't allow some common generators such as "Unix Makefiles".

There is no reason for these limitation, given that the build system is run via cmake --build.

Such issues are generally caused by some macros in the cmake code that are not defined and are not escaped in build.ninja.

No. It is not about cmake variables.
Here, it is intentionally using literal $(MAKE), a make variable. $(MAKE) passes makeflags, in particular parallelism, to sub-makes. This ties the cmake build system to the "Unix Makefiles" generator.
What @Neumann-A proposes is to patch the package to call make directly instead of relying on $(MAKE) variable. This will work to some extent (no parallelism, maybe additional assumptions about the build environment).
But when there is a widely-used cmake generator (Unix Makefiles) that is compatible with a package, and a widely used build tool (make) which is compatible with the package, how can vcpkg_configure_cmake not support that combination?

I agree with @dg0yt that if CMake has an option/generator that allows this to be used, vcpkg should let me use it. It would also make this much easier on me :D

@diehard2 You may try the changes from #22626. Note that I updated the vcpkg_cmake port, not the legacy maintainer functions.

thanks @dg0yt. I'll try it this afternoon

@dg0yt sorry, I'm still new to vcpkg. I'm on your branch and can see the changes, but I'm not seeing how to hit the new functionality. This is my portfile.cmake (I'm not using the git functions because they don't work with submodules). I'm assuming I'm missing something easy.
find_program(GIT git)
set(GIT_URL "******")
set(GIT_REV "2a8e132e85a527603a3d6d4503ded117d5066eaf")
message(STATUS "port: ${PORT}")
make_directory( ${CURRENT_BUILDTREES_DIR}/src/${PORT})
set(SOURCE_PATH ${CURRENT_BUILDTREES_DIR}/src/${PORT})
message(STATUS "path: ${SOURCE_PATH}")
if(NOT EXISTS "${SOURCE_PATH}/.git")
message(STATUS "Cloning and fetching submodules")
vcpkg_execute_required_process(
COMMAND ${GIT} clone --recurse-submodules ${GIT_URL} ${SOURCE_PATH}
WORKING_DIRECTORY ${SOURCE_PATH}
LOGNAME clone
)
message(STATUS "Checkout revision ${GIT_REV}")
vcpkg_execute_required_process(
  COMMAND ${GIT} checkout ${GIT_REV}
  WORKING_DIRECTORY ${SOURCE_PATH}
  LOGNAME checkout
)

endif()
vcpkg_configure_cmake(
SOURCE_PATH ${SOURCE_PATH}
MAYBE_UNUSED_VARIABLES BUILD_NEBULA_SERVER
GENERATOR "Unix Makefiles"
OPTIONS -DBUILD_NEBULA_SERVER=OFF
)
vcpkg_install_cmake()
vcpkg_fixup_cmake_targets()
#file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/include")

The changes are not in the legacy function vcpkg_configure_cmake.
You need to install port vcpkg-cmake for your host triplet (in manifests, add a host dependency).
And then call the function prefixed with vcpkg_cmake, i.e. vcpkg_cmake_configure etc.

Its getting closer. Currently cmake is telling me that I have an argument that is unused in the CMakeLists.txt, but it definitely is used and if I call cmake directly I don't et the warning, and everything builds without issue. The bigger issue is
gmake: *** No rule to make target 'install'.  Stop.
from
Command failed: /usr/local/bin/cmake --build . --config Debug --target install -- VERBOSE=1 -j13
Thanks for the help on all of this

okay, figured out to add vcpkg_cmake_build(). Not sure what's going on with not being able to find that argument yet

Its getting closer. Currently cmake is telling me that I have an argument that is unused in the CMakeLists.txt, but it definitely is used and if I call cmake directly I don't et the warning, and everything builds without issue. The bigger issue is
gmake: *** No rule to make target 'install'. Stop.
from
Command failed: /usr/local/bin/cmake --build . --config Debug --target install -- VERBOSE=1 -j13
Thanks for the help on all of this

Does the CMakeLists.txt have install content?

Currently cmake is telling me that I have an argument that is unused in the CMakeLists.txt

Maybe you have an argument in OPTIONS which is only used in a particular configuration. We see this with CMAKE_DEBUG_POSTFIX which needs to be placed in OPTIONS_DEBUG.


Bug: swaggerUIRedirectOauth2 null after redirect

Expected Behaviour
Complete login flow to generate JWT access token.
Current Behaviour
When I click on "Authorize" button in Swagger UI, the login flow begins and I'm eventually redirected back to a URL like:
https://example.com/v3/swagger?format=oauth2-redirect&code=XXXXXXXX-6ee0-4b21-a78a-1a1d9652df68&state=XXXXXXXXXSAzMCAyMDI0IDE1OjE3OjA0IEdNVC0wNTAwIChDZW50cmFsIERheWxpZ2h0IFRpbWUp

But at this point, the flow fails with a blank page. The HTML for the page is the correct "Redirect" generated HTML, but there is an error in the console like:
TypeError: Cannot read properties of null (reading 'swaggerUIRedirectOauth2')
    at run (swagger?format=oauth2-redirect&code=c1ac9cf1-6ee0-4b21-a78a-1a1d9652df68&state=VGh1IE1heSAzMCAyMDI0IDE1OjE3OjA0IEdNVC0wNTAwIChDZW50cmFsIERheWxpZ2h0IFRpbWUp:10:36)
    at HTMLDocument.<anonymous> (swagger?format=oauth2-redirect&code=c1ac9cf1-6ee0-4b21-a78a-1a1d9652df68&state=VGh1IE1heSAzMCAyMDI0IDE1OjE3OjA0IEdNVC0wNTAwIChDZW50cmFsIERheWxpZ2h0IFRpbWUp:74:13)

And it seems that no other Javascript is being loaded by the page.
Code snippet
oauth2 = OAuth2Config(
    client_id="CHANGEME",
    app_name="CHANGEME",
)

app = APIGatewayRestResolver(enable_validation=True)
app.enable_swagger(
    path="/swagger",
    oauth2_config=oauth2,
    security_schemes={
        "oauth": OAuth2(
            flows=OAuthFlows(
                authorizationCode=OAuthFlowAuthorizationCode(
                    authorizationUrl="https://CHANGEME/oauth2/authorize",
                    tokenUrl="https://CHANGEME/oauth2/token",
                ),
            ),
        ),
    },
    security=[{"oauth": []}],
)

Possible Solution
I wonder if the swagger_js generated for the main Swagger page is supposed to also be loaded in here, but is not because of the redirect flow resetting the web page (https://docs.powertools.aws.dev/lambda/python/latest/api/event_handler/openapi/swagger_ui/index.html).
Steps to Reproduce
Should be able to use the config I gave in the code snippet, assuming you have an oauth2 identity provider at hand.
Powertools for AWS Lambda (Python) version
latest
AWS Lambda function runtime
3.10
Packaging format used
PyPi
Debugging logs
No response

Hey @Thomas-McKanna! Thanks for opening this issue.
I suspect that somewhere in the authentication mechanism it is not possible to read the properties of the Swagger main page. Let me explain the steps we took to authenticate and recover the token, which may help us identify the problem.
1 - When we set up OAuth2 authentication in SwaggerUI, it opens a modal window to fill in the client/secret (I'm using machine-to-machine authentication, but the process is the same for user authentication). When we click on the Authorizer button, it takes us to a new OIDC provider tab and one parameter we send is the redirect URL, in my case this is http://localhost:3000/swagger?format=oauth2-redirect.
2 - When the authentication is successful and the OIDC Provider redirects to http://localhost:3000/swagger?format=oauth2-redirect, the first thing that happens is accessing the swaggerUIRedirectOauth2 object from the Swagger main page, and that's where the issue is occurring in your case. For some reason, it is not possible to read this object. I have tested this with Chrome, Firefox, Safari, as well as with Cognito, Keycloak, and Okta, and I was unable to reproduce the problem in any of these scenarios. This suggests that in your specific case, either a page is being reloaded and losing the reference to swaggerUIRedirectOauth2, or there is some other reason why it is not possible to read this object.
3 - If I directly access the page /swagger?format=oauth2-redirect without authentication, I encounter the same error as you, which further reinforces the idea that, for some reason, the page is might being reloaded in your scenario.
Maybe you can test a few more scenarios to see if you can find the source of the problem? I haven't made much progress in identifying this here on my side.
Thanks

Hmmmm. I have been looking into this one for a while and I can't seem to figure it out. For some reason, browser is setting window.opener to null. I've tried in Safari, Chrome, and Firefox. My best guess is that it that the problem is due to my OAuth2 origin being different than my Swagger origin (auth.example.com vs. myapp.example.com). Then again, I don't know how you would have gotten it working with localhost.
I'm using Cognito Hosted UI. I'm going to drop work on this one for now.
@leandrodamascena Do you think it makes sense to keep this issue open in case someone else has the same issue? Otherwise, I will close it.

Hi @Thomas-McKanna, I think we can have a call and if possible can you show me your scenario and I will try to reproduce it here. It is now 5PM here and I have until 6PM, if you can, we can talk for a few minutes and I can better understand the scenario you are in there. If you are having this problem, perhaps others are and we would like to get ahead of this.
If you prefer, we can schedule this meeting the next week. Please send a email to aws-powertools-maintainers at amazon.com.

(for my own on-call update).. this call happened. We might be able to get it released this Thursday, otherwise later this month

Hello @Thomas-McKanna! I tried my best to find a way to solve this problem, but there's nothing we can do about it here. The problem is that we really need the opener's reference (the window/tab who opened the window/tab auth) to update SwaggerUI, without that there's nothing we can do.
I'm closing this issue, but if you find a solution and/or we find one on our side, we can open it again.
Thanks for insights and your patience.


ZEPPELIN-390 Update download page and add release note

Vote for 0.5.5-incubating is passed
Dev list vote result : here
IPMC vote result: here
This PR Update download page and add a release note for 0.5.5-incubating.
Please review releases/zeppelin-release-0.5.5-incubating.md and give me any feedback, addition, correction, etc. Once this PR is merged, 0.5.5-incubating release will announced.
This PR also bringing back release note of previous release, 0.5.0-incubating, removed by mistake https://github.com/apache/incubator-zeppelin/commit/71db6d57e711ba1eeca01422d2c00f240294ba29.

Thanks @jongyoul @felixcheung for the feedback.
I'm merging this PR if there're no more discussions

LGTM


Option to receive push notification when app is killed

Here on my android, i doesn't receive push notifications when app is killed / closed, just on background. How can this be solved ?

We are using this library in our 3 productions apps and seems to work fine. Are you expecting to receive data payload based notifications (where there is no title & body)?

What version of Android do you have?

@eeerrrttty were you able to get this working? Because this fork is working for us in our two production applications.

I also had the same problem on ios12. I couldn't receive notification when I was running in the background, but I was notified when I was running in the front desk, hoping to get a reply.

test on another phone, if it works, reset your device's messaging settings

@eeerrrttty I'm closing this issue assuming things are working now for you. Please feel free to re-open later if this is not the case.


Various software refuses to bind to it's listenaddress

This is a weird bug. When a service is changed during nixos-rebuild and therefore restarted, it refuses to bind to it's given port. For Example:
starting the following units: accounts-daemon.service, cups.socket, mpd.service, nix-daemon.socket, systemd-modules-load.service, systemd-udevd-control.socket, systemd-udevd-kernel.socket, tlp.service, udisks2.service, zerotierone.service
Job failed. See "journalctl -xe" for details.
warning: the following units failed: cups.socket

● cups.socket - CUPS Scheduler
   Loaded: loaded (/nix/store/nkihl7vbzbqz990hq15q42h69c06pijg-cups-2.2.12/lib/systemd/system/cups.socket; enabled; vendor preset: enabled)
  Drop-In: /nix/store/za3k732cia0g9y21xc5sdfflvgfsxd9j-system-units/cups.socket.d
           └─overrides.conf
   Active: failed (Result: resources) since Mon 2019-10-14 10:17:56 CEST; 3s ago
   Listen: /run/cups/cups.sock (Stream)
           /run/cups/cups.sock (Stream)
           <IP_ADDRESS>:631 (Stream)
       IP: 2.1K in, 2.2K out
      CPU: 645us

Oct 14 10:17:58 zornpad systemd[1]: /nix/store/nkihl7vbzbqz990hq15q42h69c06pijg-cups-2.2.12/lib/systemd/system/cups.socket:6: ListenStream= references a path below legacy directory /var/run/, updating /var/run/cups/cups.sock → /run/cups/cups.sock; please update the unit file accordingly....
Oct 14 10:17:58 zornpad systemd[1]: cups.socket: Failed to receive listening socket (<IP_ADDRESS>:631): Input/output error
Oct 14 10:17:58 zornpad systemd[1]: cups.socket: Failed to listen on sockets: Input/output error
Oct 14 10:17:58 zornpad systemd[1]: cups.socket: Failed with result 'resources'.
Oct 14 10:17:58 zornpad systemd[1]: Failed to listen on CUPS Scheduler.
Oct 14 10:17:58 zornpad systemd[2307]: cups.socket: Failed to create listening socket (<IP_ADDRESS>:631): Cannot assign requested address
Oct 14 10:17:58 zornpad systemd[1]: cups.socket: Failed to receive listening socket (<IP_ADDRESS>:631): Input/output error
Oct 14 10:17:58 zornpad systemd[1]: cups.socket: Failed to listen on sockets: Input/output error
Oct 14 10:17:58 zornpad systemd[1]: cups.socket: Failed with result 'resources'.
Oct 14 10:17:58 zornpad systemd[1]: Failed to listen on CUPS Scheduler.
Hint: Some lines were ellipsized, use -l to show in full.
warning: error(s) occurred while switching to the new configuration
sudo nixos-rebuild test  18.28s user 4.83s system 7% cpu 5:23.89 total

Though nothing is listening on that port:
$ sudo ss -tlpn
State    Recv-Q   Send-Q            Local Address:Port        Peer Address:Port
LISTEN   0        128               <IP_ADDRESS>%lo:53               <IP_ADDRESS>:*       users:(("systemd-resolve",pid=1003,fd=17))
LISTEN   0        128                     <IP_ADDRESS>:22               <IP_ADDRESS>:*       users:(("sshd",pid=1028,fd=3))
LISTEN   0        128         <IP_ADDRESS>%wlp3s0:21915            <IP_ADDRESS>:*       users:(("zerotier-one",pid=2313,fd=17))
LISTEN   0        128         <IP_ADDRESS>%wlp3s0:21916            <IP_ADDRESS>:*       users:(("zerotier-one",pid=2313,fd=19))
LISTEN   0        5                       <IP_ADDRESS>:6600             <IP_ADDRESS>:*       users:(("mpd",pid=2301,fd=7))
LISTEN   0        128         <IP_ADDRESS>%wlp3s0:9993             <IP_ADDRESS>:*       users:(("zerotier-one",pid=2313,fd=15))
LISTEN   0        5                       <IP_ADDRESS>:4713             <IP_ADDRESS>:*       users:(("pulseaudio",pid=1418,fd=32))
LISTEN   0        128                     <IP_ADDRESS>:5355             <IP_ADDRESS>:*       users:(("systemd-resolve",pid=1003,fd=12))
LISTEN   0        128                        [::]:22                  [::]:*       users:(("sshd",pid=1028,fd=4))
LISTEN   0        5                          [::]:4713                [::]:*       users:(("pulseaudio",pid=1418,fd=10))
LISTEN   0        128                        [::]:5355                [::]:*       users:(("systemd-resolve",pid=1003,fd=14))

I have this problem with all kind of services, for example mpd. Even a local build of zola (a static site generator with a preview function) doesn't start at this point:
$ zola serve
No port available.

Changing the port in question doesn't change anything.
The symptomatics is always the same: according to ss the port is not in use yet the software claims that it cannot bind to the port. I'm desperate for input on how to debug this.
Edit 1:
After a fresh restart, things (zola serve) work! Then, after nixos-rebuild test, things (zola serve) still work. So, I still don't know how to reproduce this reliable.
Edit 2:
After a systemctl suspend, things (zola serve) won't work.
Expected behavior
Service starts listening on it's assigned and free port
Additional context
I've encountered this on two of my machines, one with linux 4 and one with linux 5
Metadata

system: "x86_64-linux"
host os: Linux 5.3.5, NixOS, 19.09.789.7952807791d (Loris)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.3
channels(root): "nixos-19.09.789.7952807791d, nixos-unstable-20.03pre197080.dd050270c78"
channels(wucke13): "nixos-unstable-20.03pre196480.8b46dcb3db5"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

are you running any large server workloads on this box? First thing I was thining of is that perhaps your file descriptor pool is exhausted?

Could you show the output of  $ strace zola serve  (Or any other cli tool that tries to bind to a port?)
I want to know what syscall is failing and with what error code

are you running any large server workloads on this box? First thing I was thining of is that perhaps your file descriptor pool is exhausted?

Nope, one of the machines is my laptop with few services.

Could you show the output of $ strace zola serve (Or any other cli tool that tries to bind to a port?)
I want to know what syscall is failing and with what error code

Sure! trace.txt
At least for zola serve, the systemctl suspend seems to be a reliable  way to reproduce this behavior.

Thanks. could you also show the output of $ ip link when this issue happens?
From the logs it seems like your loopback interface is not available (which is odd)
socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_IP) = 3
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(8995), sin_addr=inet_addr("<IP_ADDRESS>")}, 16) = -1 EADDRNOTAVAIL (Cannot assign requested address)
close(3)                                = 0

``

Sure :smile:
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s25: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
    link/ether <one of my mac addresses> brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether <one of my mac addresses> brd ff:ff:ff:ff:ff:ff
4: zt<zerotier id>: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2800 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether <one of my mac addresses> brd ff:ff:ff:ff:ff:ff
5: zt<zerotier id>: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2800 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether <one of my mac addresses> brd ff:ff:ff:ff:ff:ff

$ cat /etc/hosts
<IP_ADDRESS> localhost
<IP_ADDRESS> <hostname>
::1 localhost

Worth noting, I do use systemd-networkd to configure my interfaces.

In that case, a networkctl status -a when the issue is manifested will also be useful ;)

As requested. Note that I removed the zerotier interfaces from the list, as I do not expect the issue to be related to them.
$ networkctl status -a
● 1: lo
             Link File: /nix/store/6snycpaz9zrs5m7xz6dixl1nl0ngdrma-systemd-243/lib/systemd/network/99-default.link
          Network File: /etc/systemd/network/99-main.network
                  Type: loopback
                 State: carrier (configured)
                   MTU: 65536
  Queue Length (Tx/Rx): 1/1

● 2: enp0s25
             Link File: /nix/store/6snycpaz9zrs5m7xz6dixl1nl0ngdrma-systemd-243/lib/systemd/network/99-default.link
          Network File: /etc/systemd/network/99-main.network
                  Type: ether
                 State: no-carrier (configuring)
                  Path: pci-0000:00:19.0
                Driver: e1000e
                Vendor: Intel Corporation
                 Model: Ethernet Connection (3) I218-LM
            HW Address: <my mac address> (LCFC(HeFei) Electronics Technology co., ltd)
                   MTU: 1500 (min: 68, max: 9000)
  Queue Length (Tx/Rx): 1/1
      Auto negotiation: yes
                 Speed: n/a
                  Port: tp

● 3: wlp3s0
             Link File: /nix/store/6snycpaz9zrs5m7xz6dixl1nl0ngdrma-systemd-243/lib/systemd/network/99-default.link
          Network File: /etc/systemd/network/99-main.network
                  Type: wlan
                 State: routable (configured)
                  Path: pci-0000:03:00.0
                Driver: iwlwifi
                Vendor: Intel Corporation
                 Model: Wireless 7265 (Dual Band Wireless-AC 7265)
            HW Address: <my mac address> (Intel Corporate)
                   MTU: 1500 (min: 256, max: 2304)
  Queue Length (Tx/Rx): 1/1
               Address: <IP_ADDRESS>
                        fe80::6257:18ff:fe6e:65d1
               Gateway: <IP_ADDRESS> (<brand name of my gateway>)
                   DNS: <IP_ADDRESS>

Looks like the loopback interface has lost its configuration as it doesn't have any addresses. This sounds like the same issue as I reported here.

@alexbakker Ah yes!

That networkd  is managing the lo interface by default seems undesirable to me. We should probably exclude it in the generated config.  For completeness sake, could you post
$ cat /etc/systemd/network/99-main.network

here?
networkd managing the lo interface should be supported as far as I understand.  That stuff goes bananas after suspend sounds like an upstream systemd-networkd issue to me.  and should probably be filed as a bug with the systemd project.  I'd like to try to reproduce this on a non-NixOS distro using your 99-main.network and then see if we can file an upstream issue for it.
For you to get further and not have a buggy experience, I advice to make lo explicitly unmanaged by default like in the issue @alexbakker linked. We should also probably make this the default; and backport it to 19.09.

@arianvp Sure!

[Network]
DHCP=yes

IPv6AcceptRA=no
DNSSEC=no

Many thanks for the information, this makes sence.

Interesting. Could you show your networking config section of your nixos configuration? I'm kind of surprised it generated a file with DHCP=yes on all interfaces.    I thought we removed this from 19.09. It should've given you an evaluation error
as per release notes:

The networking.useDHCP option is unsupported in combination with networking.useNetworkd in anticipation of defaulting to it by default. It has to be set to false and enabled per interface with networking.interfaces..useDHCP = true;

https://github.com/NixOS/nixpkgs/pull/69302

I have experienced the lo interface losing its IP addresses when managed by systemd, as far as I could tell at suspend/wakeup. Since, I have removed the 99-main for me, which we will remove soon for 20.03, too.

Could you show your networking config section of your nixos configuration?

Sure!
networking = {
    useNetworkd = true;
    useDHCP = false;
    firewall. enable = false;
};
systemd.services."systemd-networkd-wait-online".enable = false;
systemd.network = {
  enable = true;
  networks = {
    "10-unmanaged" = {
      matchConfig.Name = "docker* nlmon* tun* virbr* zt*";
      linkConfig.Unmanaged = true;
    };
    "99-main" = {
      DHCP = "yes";
      extraConfig = ''
        IPv6AcceptRA=no
        DNSSEC=no
      '';
    };
  };
};

So looks like it is my fault, as I have DHCP=yes. Would you mind sharing a basic idiomatic sample for a systemd-networkd config?

    "99-main" = {
      MatchConfig = "en* wl*";
      DHCP = "yes";
      extraConfig = ''
        IPv6AcceptRA=no
        DNSSEC=no
      '';
    };

Should do the job in your case.
Or you could add lo to your Umanaged list:
  networks = {
    "10-unmanaged" = {
      matchConfig.Name = "lo docker* nlmon* tun* virbr* zt*";
      linkConfig.Unmanaged = true;
    };
    "99-main" = {
      DHCP = "yes";
      extraConfig = ''
        IPv6AcceptRA=no
        DNSSEC=no
      '';
    };
  };

Both will work.

I was looking to see if this is a systemd bug, but this behaviour is documented. It's not a bug. From the systemd-networkd man page (emphasis mine):

systemd-networkd will manage network addresses and routes for any link for which it finds a .network file with an appropriate [Match] section, see systemd.network(5). For those links, it will flush existing network  addresses and routes when bringing up the device.

The linux kernel brings lo up. So when systemd-network starts, there is nothing for it to do. However when you suspend, and unsuspend, lo will be down, and systemd-networkd tries to configure it, which will flush the addresses before configuring, making lo lose the <IP_ADDRESS> address.
Another way to fix this would be to have an explicit configuration for loopback, and make it a very high presedence. This will cause the loopback interface to always be correctly configured.
networks."00-loopback" = {  matchConfig.Name = "lo";   Address = "<IP_ADDRESS>"; };

I would personally much rather have the option to have networkd not touch any network interfaces by default, except for the ones that have a config in configuration.nix.

Agreed. That is the option we're planning to implement soon.

Issue is solved by https://github.com/NixOS/nixpkgs/issues/71106#issuecomment-542084629, thank you all!


Question - I am not able to track every method under my fastapi endpoint

In the logs i just see the framework level tracing, where as i want to know it for every method under the endpoint call. Am i missing something or is that the expected output.
this is how as per your example i am adding to the fastapi middleware.
app.add_middleware(PyInstrumentProfilerMiddleware)

You don't need this library probably. Just use something like this:
from pyinstrument import Profiler

app = ...

@app.middleware("http")
async def __profiling(request: Request, call_next):
    p = Profiler()
    p.start()
    response: Response = await call_next(request)
    p.stop()
    p.print()
    return response

@kigawas use a middleware is more pythonic. 😄


Increment version for workloadmonitor releases

Increment package version after release of Azure.ResourceManager.WorkloadMonitor

API change check
API changes are not detected in this pull request.


Patch 8.0.0754 (commit eeac677) breaks bold colours on xterm t_Co=8

Potentially involved commits:
https://github.com/vim/vim/commit/eeac67788677a9ea81bcab69f81b4fc22c2adc00 (8.0.0754)
https://github.com/vim/vim/commit/b41bf8e6b45a773456031954bca1bc4212cbffbe (8.0.0791)
I recent upgraded my FreeBSD 10.3 vim-lite package from 8.0.0742 to 8.0.0809 and was surprised to find that colours looked incorrect -- specifically, they were darker (i.e. bold bit no longer being set on terminal output).
FreeBSD's TERM=xterm uses t_Co=8 and has for decades.  The terminal truly only supports 8 colours, but in the terminal emulator (PuTTY), bold being set causes the colours to be brighter.  This behaviour is "ANSI-like" (where bold means "brighter colour" rather than a bolded font) and is extremely common.
I do not use t_Co=256 because the colours look weird to me ("washed out", purely an aesthetic dislike), and I do not use TERM=xterm-color (which uses t_Co=256 anyway) because not all *IX software works correctly with xterm-color.
Attached are screenshots of FreeBSD 10.3 vim-lite 8.0.0809 vs. FreeBSD 9.3 vim-lite 8.0.0134.  There are irrelevant termcap differences (I reviewed them), but visually you can see the difference I'm referring to (re: lack of bold).  FreeBSD binary package updates do not have have a native way to revert to a previous package, so I cannot roll back to 8.0.0742.
Crummy workaround, which may or not be accurate (can't tell if 0754 or 0791 is responsible):
if has("patch-8.0.0754") && &term =~ "xterm"
  set t_Co=16
endif

I noticed this problem as well and bisected it to 8.0.0791 (b41bf8e6b)
Before 791:

After 791:

Manually setting set t_Co=16 as per @koitsu's workaround fixes the colours
Running iTerm2 on macos with tmux and TERM=screen

@sdt Thanks so much for confirming it's b41bf8e that causes the problem!

I see the problem, but I'm not sure on what the solution might be.
In the old code, we have i which is the color table index,
https://github.com/vim/vim/blob/fa228f716a4b63bf508887a49ce56bf4c07364d3/src/syntax.c#L7795
and idx which is an offset into HL_TABLE
https://github.com/vim/vim/blob/fa228f716a4b63bf508887a49ce56bf4c07364d3/src/syntax.c#L7803
In the new version, that code has been lifted out to become lookup_color, with i being renamed to idx. The original idx is clobbered.
The original idx could be passed as a parameter easily enough from do_highlight, but this may not make sense for all the new calls to lookup_color in color2index.

@sdt
I can't reproduce the issue on my macOS, but following your investigation, we have
diff --git a/src/proto/syntax.pro b/src/proto/syntax.pro
index 33b8b80f5..f1efde71d 100644
--- a/src/proto/syntax.pro
+++ b/src/proto/syntax.pro
@@ -23,7 +23,7 @@ void ex_syntime(exarg_T *eap);
 char_u *get_syntime_arg(expand_T *xp, int idx);
 void init_highlight(int both, int reset);
 int load_colors(char_u *name);
-int lookup_color(int idx, int foreground);
+int lookup_color(int hl_idx, int idx, int foreground);
 void do_highlight(char_u *line, int forceit, int init);
 void free_highlight(void);
 void restore_cterm_colors(void);
diff --git a/src/syntax.c b/src/syntax.c
index e026c4400..8e8a760b0 100644
--- a/src/syntax.c
+++ b/src/syntax.c
@@ -7278,7 +7278,7 @@ static int color_numbers_8[28] = {0, 4, 2, 6,
  * color_names[].
  */
     int
-lookup_color(int idx, int foreground)
+lookup_color(int hl_idx, int idx, int foreground)
 {
     int		color = color_numbers_16[idx];
     char_u	*p;
@@ -7301,11 +7301,11 @@ lookup_color(int idx, int foreground)
 	     * colors (on some terminals, e.g. "linux") */
 	    if (color & 8)
 	    {
-		HL_TABLE()[idx].sg_cterm |= HL_BOLD;
-		HL_TABLE()[idx].sg_cterm_bold = TRUE;
+		HL_TABLE()[hl_idx].sg_cterm |= HL_BOLD;
+		HL_TABLE()[hl_idx].sg_cterm_bold = TRUE;
 	    }
 	    else
-		HL_TABLE()[idx].sg_cterm &= ~HL_BOLD;
+		HL_TABLE()[hl_idx].sg_cterm &= ~HL_BOLD;
 	}
 	color &= 7;	/* truncate to 8 colors */
     }
@@ -7857,7 +7857,7 @@ do_highlight(
 		    break;
 		}

-		color = lookup_color(i, key[5] == 'F');
+		color = lookup_color(idx, i, key[5] == 'F');
 	    }

 	    /* Add one to the argument, to avoid zero.  Zero is used for

Will you try this patch to see if it fixes the issue for you?  Note that the patch was made against HEAD.

@sdt

The original idx could be passed as a parameter easily enough from do_highlight, but this may not make sense for all the new calls to lookup_color in color2index.

Ah,  I missed it.  Let me take back the patch.  That's wrong.  Sorry for the noise.

@nuko8 I tried a similar patch locally, but changing
if (foreground) to if (foreground && (hl_idx >= 0))
and for the other calls, passing -1 for hl_idx.
That fixes the issue for me, but  I have no idea what is valid for a real hl_idx.

@sdt
Interesting.  I was just about sending the following when I got your message.  Somehow, we are working with the same idea :)

Since color2index() only needs to know the index of a given color, it is unnecessary for it to access to HL_TABLE().   So, when lookup_color() is called from color2index(), there's no need to refer to the index of HL_TABLE() at all.
So, using -1 as a means to skip access to HL_TABLE(), a possible quick fix would be this.

I'd like to hear your opinion on that.

That's more or less what I was experimenting with.
I don't have a working build machine available until tomorrow, so I won't be able to actually test that, but it's the same logic I had. I'll test it for real in the morning.
Thanks for looking into this @nuko8 !

@sdt
Thanks to you, we now know the cause of the trouble.  Also, it seems that you are familiar with the code base.  So if you get a better solution, or find anything to fix or improve in the patch, please consider sending us your own patch.   I'm wondering why you didn't do so ;-)

Stephen Thirlwall wrote:

I see the problem, but I'm not sure on what the solution might be.
In the old code, we have i which is the color table index,
https://github.com/vim/vim/blob/fa228f716a4b63bf508887a49ce56bf4c07364d3/src/syntax.c#L7795
and idx which is an offset into HL_TABLE
https://github.com/vim/vim/blob/fa228f716a4b63bf508887a49ce56bf4c07364d3/src/syntax.c#L7803
In the new version, that code has been lifted out to become
lookup_color, with i being renamed to idx. The original idx is
clobbered.
The original idx could be passed as a parameter easily enough from
do_highlight, but this may not make sense for all the new calls to
lookup_color in color2index.

Thanks for pinpointing the problem.  The terminal code didn't use the
bold flag, that should be fixed as well.
--
GUARD #1:  What -- a swallow carrying a coconut?
ARTHUR:    It could grip it by the husk!
GUARD #1:  It's not a question of where he grips it!  It's a simple question
of weight ratios!  A five ounce bird could not carry a 1 pound
coconut.
The Quest for the Holy Grail (Monty Python)
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

@brammool - I can confirm 12d853f works for me. Thanks!
@nuko8 - I'm actually 100% unfamiliar with the code base - I just got lucky with git bisect. It took a bit of staring at that diff to work out what had actually changed.

FreeBSD just pushed out vim/vim-lite 8.0.0867 packages, and I can now confirm the problem is gone with the introduction of 12d853f / 8.0.0831. Thanks everyone!


Feature/245 confirm attendance

Confirm your attendance:
Fixes #248, #249, #250
Figma URL
https://www.figma.com/file/TU0ycyxLagQ8xio2GhfDKqMj/Registration-system-desktop?node-id=638%3A7
Card pops up when you have been accepted

Clicking on it brings you to this page

Validation: you must accept the liability

Redirect to home page when successful, removal of card.

Check the following:

[ ] User cannot access page unless they are confirmed
[ ] Card is added once user has accepted
[ ] User must accept waiver
[ ] Database is updated
[ ] Card is removed once user has confirmed
[ ] No regression

Yeah it's technically centered, it's just that Theatre is too long to fit on the edge. The page looks pretty clunky, imo. I'm game to receive re-designs.

yeah I'm down to have design look at it. I was mistaken on the closing date for applications so I just threw something together hella hasty to get it done.

Should we leave this open until further notice then?

Should we leave this open until further notice then?

For a day or two yeah. I think even with applications closing later than I thought we might do a round of acceptances before they close.

Lmk

@loreina can I merge this ?

@krubenok we need https://mchacks.ca/liability

@loreina waiting on the PR approval for the liability page on the McHacks site.
https://github.com/hackmcgill/mchacks6/pull/135


Raise an exception if JSON generation capability doesn't exist

AFJSONEncode() will create an exception if it cannot find a way to generate JSON, but it never raises the exception.

Saving me from my amateur hour mistakes once again. Thanks for the patch :)


⚠ ClamAV has degraded performance

In acf547e, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 74 ms

Resolved: ClamAV performance has improved in eeeaf2d.


Support macos stone-prover binaries

Added a new asset in https://github.com/zksecurity/stone-cli/releases/tag/v0.1.0-alpha for macos-aarch64

This is also not touched by this PR, but:
The download_executables starts by checking if all the files exists, if so, it returns:
fn download_executables(config: &Config) {
    let download_dir = Path::new(env!("HOME")).join(&config.download_dir);
    if !download_dir.exists() {
        std::fs::create_dir_all(&download_dir).expect("Failed to create download directory");
    }

    if config
        .file_names
        .iter()
        .all(|filename| download_dir.join(filename).exists())
    {
        return;
    }

    ...
}

This is an issue, because the files might exist, but not be "valid" due to two issues:

If validate_unpacked_files(&download_dir, &config.file_names, &sha256_sums); fails. In which case the files are still left in the correct location. Running the download_executables again makes return and hence the files which (may) have failed the fingerprint validation are used.

If set_execute_permissions fails. In which case the files are left unexecutable.

The current approach also has issues when the tool is updated: the files for the old prover might still be on disk, preventing an update.
It might be useful to explore a "content addressable" approach: where the file names are the SHA256 hashes, i.e. stone-prover-d8cb6bab6576674d7d8ee986fe0da2598ee8c546517c997980eae6725d0ad017 which enables several different version of the binaries to exists on disk without interfering with each other. Checking for the existence of the files corresponds to checking for a specific version of all the binaries. You can then point at the specific version used by setting the environment variables.
When checking for them, make sure that they are also set executable.
Probably also a good idea to write the files to a temporary directory first, then validate the fingerprints and only then write them to the destination. That way we also avoid leaving artifacts on disk if we fail.

Maybe we should treat: https://github.com/starkware-libs/cairo/releases/download/v2.6.3/release-x86_64-unknown-linux-musl.tar.gz the same as the stone prover/verifier. After all, it's just another file we need to download and decompress into a directory, maybe we can unify the logic.

Not really touched by this PR, but is is possible to get rid of the last: std::process::Command::new("cp") and std::process::Command::new("rm") calls?

I think we need these? So when we clone the cairo-vm repo, we copy out the cairo1-run directory and remove the rest because it's not part of the module for some reason (https://github.com/lambdaclass/cairo-vm/tree/main/cairo1-run)

Maybe we should treat: https://github.com/starkware-libs/cairo/releases/download/v2.6.3/release-x86_64-unknown-linux-musl.tar.gz the same as the stone prover/verifier. After all, it's just another file we need to download and decompress into a directory, maybe we can unify the logic.

I think there's enough divergences (no validation, no permission change, copying inner directory) to separate them for readability?

This is also not touched by this PR, but:
The download_executables starts by checking if all the files exists, if so, it returns:
fn download_executables(config: &Config) {
    let download_dir = Path::new(env!("HOME")).join(&config.download_dir);
    if !download_dir.exists() {
        std::fs::create_dir_all(&download_dir).expect("Failed to create download directory");
    }

    if config
        .file_names
        .iter()
        .all(|filename| download_dir.join(filename).exists())
    {
        return;
    }

    ...
}

This is an issue, because the files might exist, but not be "valid" due to two issues:

If validate_unpacked_files(&download_dir, &config.file_names, &sha256_sums); fails. In which case the files are still left in the correct location. Running the download_executables again makes return and hence the files which (may) have failed the fingerprint validation are used.
If set_execute_permissions fails. In which case the files are left unexecutable.

The current approach also has issues when the tool is updated: the files for the old prover might still be on disk, preventing an update.
It might be useful to explore a "content addressable" approach: where the file names are the SHA256 hashes, i.e. stone-prover-d8cb6bab6576674d7d8ee986fe0da2598ee8c546517c997980eae6725d0ad017 which enables several different version of the binaries to exists on disk without interfering with each other. Checking for the existence of the files corresponds to checking for a specific version of all the binaries. You can then point at the specific version used by setting the environment variables.
When checking for them, make sure that they are also set executable.
Probably also a good idea to write the files to a temporary directory first, then validate the fingerprints and only then write them to the destination. That way we also avoid leaving artifacts on disk if we fail.
EDIT: Maybe we should do this in a separate PR.

Great points, created an issue to track this.

LGTM, are we ready to merge?