Error:
I just checked the audit report by using npm audit command in my react app and I got these below vulnerabilities in my audit report
**minimatch** <3.0.5
Severity: high
minimatch ReDoS vulnerability - https://github.com/advisories/GHSA-f8q6-p94x-37v3
fix available via `npm audit fix`
node_modules/recursive-readdir/node_modules/minimatch
recursive-readdir 1.2.0 - 2.2.2
Depends on vulnerable versions of minimatch
node_modules/recursive-readdir
**nth-check** <2.0.1
Severity: high
Inefficient Regular Expression Complexity in nth-check - https://github.com/advisories/GHSA-rp65-9cf3-cjxr
fix available via `npm audit fix --force`
Will install react-scripts#2.1.3, which is a breaking change
node_modules/svgo/node_modules/nth-check
css-select <=3.1.0
Depends on vulnerable versions of nth-check
node_modules/svgo/node_modules/css-select
svgo 1.0.0 - 1.3.2
Depends on vulnerable versions of css-select
node_modules/svgo
#svgr/plugin-svgo <=5.5.0
Depends on vulnerable versions of svgo
node_modules/#svgr/plugin-svgo
#svgr/webpack 4.0.0 - 5.5.0
Depends on vulnerable versions of #svgr/plugin-svgo
node_modules/#svgr/webpack
react-scripts >=2.1.4
Depends on vulnerable versions of #svgr/webpack
node_modules/react-scripts
8 high severity vulnerabilities
Related
I've got XCode 12.5 up and running on macOS 11.3 (M1 chip) in Github Actions as a self-hosted runner.
While my macOS workflow is able to find gl.h in the github-hosted machine just fine, my own self-hosted one reports this:
CMake Error at /Users/administrator/actions-runner/_work/Mudlet/Qt/5.14.2/clang_64/lib/cmake/Qt5Gui/Qt5GuiConfigExtras.cmake:9 (message):
Error: Failed to find "gl.h" in
"/System/Library/Frameworks/OpenGL.framework/Headers;/System/Library/Frameworks/AGL.framework/Headers".
Call Stack (most recent call first):
/Users/administrator/actions-runner/_work/Mudlet/Qt/5.14.2/clang_64/lib/cmake/Qt5Gui/Qt5GuiConfig.cmake:202 (include)
3rdparty/vcpkg/scripts/buildsystems/vcpkg.cmake:555 (_find_package)
/Users/administrator/actions-runner/_work/Mudlet/Qt/5.14.2/clang_64/lib/cmake/Qt5Widgets/Qt5WidgetsConfig.cmake:94 (find_package)
3rdparty/vcpkg/scripts/buildsystems/vcpkg.cmake:555 (_find_package)
/Users/administrator/actions-runner/_work/Mudlet/Qt/5.14.2/clang_64/lib/cmake/Qt5UiTools/Qt5UiToolsConfig.cmake:219 (find_package)
3rdparty/vcpkg/scripts/buildsystems/vcpkg.cmake:555 (_find_package)
3rdparty/edbee-lib/edbee-lib/CMakeLists.txt:177 (FIND_PACKAGE)
The code responsible is this line:
FIND_PACKAGE(Qt5UiTools REQUIRED)
What could be the reason that gl.h is not locatable?
I got this problem when I updated to MacOS Big Sur (11.6.2) when trying to make a qt app.
This was the error I got:
CMake Error at /usr/local/Qt-5.5.1/lib/cmake/Qt5Gui/Qt5GuiConfigExtras.cmake:9 (message):
Failed to find "gl.h" in
"/System/Library/Frameworks/OpenGL.framework/Headers;/System/Library/Frameworks/AGL.framework/Headers".
Call Stack (most recent call first):
/usr/local/Qt-5.5.1/lib/cmake/Qt5Gui/Qt5GuiConfig.cmake:139 (include)
My google-fu found this from 2019 [https://github.com/ziglang/zig/issues/2208]
https://github.com/ziglang/zig/issues/2208 :
The new path to the framework is:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks
I looked, and gl.h was found in several places, including OpenGL.framework.
As a work-around, I changed the library path in /usr/local/Qt-5.5.1/lib/cmake/Qt5Gui/Qt5GuiConfigExtras.cmake:9 from:
set(_GL_INCDIRS "/System/Library/Frameworks/OpenGL.framework/Headers" "/System/Library/Frameworks/AGL.framework/Headers")
to:
set(_GL_INCDIRS "/System/Library/Frameworks/OpenGL.framework/Headers" "/System/Library/Frameworks/AGL.framework/Headers" "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks")
running on macOS 11.3 (M1 chip) in Github Actions as a self-hosted runner.
Try again with the latest version of self-hosted runners, since (Aug. 2022):
GitHub Actions: Self-hosted runners now support Apple M1 hardware
Actions runner support for Apple silicon hardware, such as the M1 chip, is now generally available.
This provides teams with the capability to run self-hosted macOS workflows in a macOS ARM64 runtime.
Now the Actions runner supports M1 and the ARM64 runtime meaning developers can run it on their own M1 or M2 hardware.
Based on initial testing, there are currently two issues to be aware of:
macOS ARM64 does not support node12.
Therefore, the runner will automatically use node16 to execute any javascript Action written for node12.
All actions provided by GitHub are compatible with the runner except for a known issue with setup-python. The fix for that can be tracked here.
For additional information on how to set up a self-hosted macOS ARM64 runner, please refer to our documentation.
If you have any feedback or questions for Actions self-hosted Apple silicon support, you can submit an issue in the runner repository.
Am setting up a small project build, which is in .Net Core. dotnet build fails everytime with below log:
2019-10-03T21:31:54.5434435Z ##[section]Starting: dotnet build
2019-10-03T21:31:54.5559431Z ==============================================================================
2019-10-03T21:31:54.5559511Z Task : .NET Core
2019-10-03T21:31:54.5559544Z Description : Build, test, package, or publish a dotnet application, or run a custom dotnet command
2019-10-03T21:31:54.5559595Z Version : 2.158.0
2019-10-03T21:31:54.5559626Z Author : Microsoft Corporation
2019-10-03T21:31:54.5559679Z Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli
2019-10-03T21:31:54.5559712Z ==============================================================================
2019-10-03T21:31:55.3428758Z [command]C:\windows\system32\chcp.com 65001
2019-10-03T21:31:55.3566253Z Active code page: 65001
2019-10-03T21:31:55.5334629Z [command]C:\hostedtoolcache\windows\dotnet\dotnet.exe build d:\a\r1\a\MyTool\DataFactory\CustomActivities\MyTool\MyTool.csproj --no-restore
2019-10-03T21:31:55.5534100Z ##[error]Error: There was an error when attempting to execute the process 'C:\hostedtoolcache\windows\dotnet\dotnet.exe'. This may indicate the process failed to start. Error: spawn C:\hostedtoolcache\windows\dotnet\dotnet.exe ENOENT
2019-10-03T21:31:55.5546833Z ##[error]Dotnet command failed with non-zero exit code on the following projects : d:\a\r1\a\MyTool\DataFactory\CustomActivities\MyTool\MyTool.csproj
2019-10-03T21:31:55.5625878Z ##[section]Finishing: dotnet build
I have now added a dotnet SDK activity to load 2.2.x version and then then an explicit dotnet restore step (even though its not needed technically as build should do a restore too). But, the restore step passes, but it fails every time in the build step.
Some partial logs from the restore process are shown below -
2019-10-03T21:30:25.5826687Z ##[section]Starting: dotnet restore
2019-10-03T21:30:25.5942577Z ==============================================================================
2019-10-03T21:30:25.5942669Z Task : .NET Core
2019-10-03T21:30:25.5942702Z Description : Build, test, package, or publish a dotnet application, or run a custom dotnet command
2019-10-03T21:30:25.5942756Z Version : 2.158.0
2019-10-03T21:30:25.5942787Z Author : Microsoft Corporation
2019-10-03T21:30:25.5942837Z Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli
2019-10-03T21:30:25.5942869Z ==============================================================================
2019-10-03T21:30:27.1500592Z [command]C:\windows\system32\chcp.com 65001
2019-10-03T21:30:27.7292436Z Active code page: 65001
2019-10-03T21:30:27.7296084Z SYSTEMVSSCONNECTION exists true
2019-10-03T21:30:28.0692275Z SYSTEMVSSCONNECTION exists true
2019-10-03T21:30:28.5211540Z SYSTEMVSSCONNECTION exists true
2019-10-03T21:30:28.5240738Z Saving NuGet.config to a temporary config file.
2019-10-03T21:30:28.5284543Z Saving NuGet.config to a temporary config file.
2019-10-03T21:30:28.5338058Z [command]C:\hostedtoolcache\windows\dotnet\dotnet.exe restore d:\a\r1\a\MyTool\DataFactory\CustomActivities\MyTool\MyTool.csproj --configfile d:\a\_temp\Nuget\tempNuGet_05ce1f4cc83beb812b37be120d7010969ab1a363.config --verbosity Detailed
2019-10-03T21:30:31.1552382Z
2019-10-03T21:30:31.1633338Z Welcome to .NET Core!
2019-10-03T21:30:31.1633445Z ---------------------
2019-10-03T21:30:31.1633487Z Learn more about .NET Core: https://aka.ms/dotnet-docs
2019-10-03T21:30:31.1633556Z Use 'dotnet --help' to see available commands or visit: https://aka.ms/dotnet-cli-docs
2019-10-03T21:30:31.1633582Z
2019-10-03T21:30:31.1633618Z Telemetry
2019-10-03T21:30:31.1633654Z ---------
2019-10-03T21:30:31.1633712Z The .NET Core tools collect usage data in order to help us improve your experience. The data is anonymous and doesn't include command-line arguments. The data is collected by Microsoft and shared with the community. You can opt-out of telemetry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true' using your favorite shell.
2019-10-03T21:30:31.1633881Z
2019-10-03T21:30:31.1633924Z Read more about .NET Core CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry
2019-10-03T21:30:31.1684350Z
2019-10-03T21:30:31.1686360Z Configuring...
2019-10-03T21:30:31.1686911Z --------------
2019-10-03T21:30:31.1687446Z A command is running to populate your local package cache to improve restore speed and enable offline access. This command takes up to one minute to complete and only runs once.
2019-10-03T21:30:44.4629886Z Decompressing .......... 13256 ms
2019-10-03T21:31:36.6357349Z Expanding .......... 51984 ms
2019-10-03T21:31:38.0761886Z
2019-10-03T21:31:38.0762691Z ASP.NET Core
2019-10-03T21:31:38.0762874Z ------------
2019-10-03T21:31:38.0763054Z Successfully installed the ASP.NET Core HTTPS Development Certificate.
2019-10-03T21:31:38.0763284Z To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only). For establishing trust on other platforms refer to the platform specific documentation.
2019-10-03T21:31:38.0763446Z For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.
2019-10-03T21:31:38.4176357Z Build started 10/3/2019 9:31:38 PM.
2019-10-03T21:31:38.9605866Z 0>Resolving SDK 'Microsoft.NET.Sdk'...
2019-10-03T21:31:38.9816247Z Property reassignment: $(MSBuildProjectExtensionsPath)="d:\a\r1\a\MyTool\DataFactory\CustomActivities\MyTool\obj\" (previous value: "obj\") at C:\hostedtoolcache\windows\dotnet\sdk\2.2.402\Current\Microsoft.Common.props (56,5)
2019-10-03T21:31:38.9833374Z Property reassignment: $(MSBuildAllProjects)=";C:\hostedtoolcache\windows\dotnet\sdk\2.2.402\Sdks\Microsoft.NET.Sdk\Sdk\Sdk.props;C:\hostedtoolcache\windows\dotnet\sdk\2.2.402\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.props" (previous value: ";C:\hostedtoolcache\windows\dotnet\sdk\2.2.402\Sdks\Microsoft.NET.Sdk\Sdk\Sdk.props") at C:\hostedtoolcache\windows\dotnet\sdk\2.2.402\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.props (15,5)
2019-10-03T21:31:38.9949011Z Property reassignment: $(MSBuildAllProjects)=";C:\hostedtoolcache\windows\dotnet\sdk\2.2.402\Sdks\Microsoft.NET.Sdk\Sdk\Sdk.props;C:\hostedtoolcache\windows\dotnet\sdk\2.2.402\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.props;C:\hostedtoolcache\windows\dotnet\sdk\2.2.402\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.DefaultItems.props" (previous value: ";C:\hostedtoolcache\windows\dotnet\sdk\2.2.402\Sdks\Microsoft.NET.Sdk\Sdk\Sdk.props;C:\hostedtoolcache\windows\dotnet\sdk\2.2.402\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.props") at C:\hostedtoolcache\windows\dotnet\sdk\2.2.402\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.DefaultItems.props (21,5)
...
...
...
2019-10-03T21:31:47.9997847Z Generating MSBuild file d:\a\r1\a\MyTool\DataFactory\CustomActivities\MyTool\MyTool\GDPR.OutputProvider\obj\GDPR.OutputProvider.csproj.nuget.g.props.
2019-10-03T21:31:47.9998017Z Generating MSBuild file d:\a\r1\a\MyTool\DataFactory\CustomActivities\MyTool\MyTool\GDPR.OutputProvider\obj\GDPR.OutputProvider.csproj.nuget.g.targets.
2019-10-03T21:31:48.0229473Z Writing assets file to disk. Path: d:\a\r1\a\MyTool\DataFactory\CustomActivities\MyTool\MyTool\GDPR.OutputProvider\obj\project.assets.json
2019-10-03T21:31:48.0229714Z Checking compatibility of packages on .NETStandard,Version=v2.0.
2019-10-03T21:31:48.0229774Z Checking compatibility for GDPR.Output.IO 1.0.0 with .NETStandard,Version=v2.0.
2019-10-03T21:31:48.0229817Z Checking compatibility for NETStandard.Library 2.0.3 with .NETStandard,Version=v2.0.
2019-10-03T21:31:48.0229859Z Checking compatibility for GDPR.Common 1.0.0 with .NETStandard,Version=v2.0.
2019-10-03T21:31:48.0229916Z Checking compatibility for GDPR.Logger 1.0.0 with .NETStandard,Version=v2.0.
2019-10-03T21:31:48.0229955Z Checking compatibility for GDPR.ObjectModel 1.0.0 with .NETStandard,Version=v2.0.
2019-10-03T21:31:48.0229996Z Checking compatibility for WindowsAzure.Storage 9.3.3 with .NETStandard,Version=v2.0.
2019-10-03T21:31:48.0230054Z Checking compatibility for Microsoft.NETCore.Platforms 1.1.0 with .NETStandard,Version=v2.0.
2019-10-03T21:31:48.0230299Z Checking compatibility for Microsoft.Azure.KeyVault 3.0.3 with .NETStandard,Version=v2.0.
2019-10-03T21:31:48.0230341Z Checking compatibility for Microsoft.Azure.Management.KeyVault 2.4.3 with .NETStandard,Version=v2.0.
2019-10-03T21:31:48.0230394Z Checking compatibility for Microsoft.Azure.Services.AppAuthentication 1.0.3 with .NETStandard,Version=v2.0.
2019-10-03T21:31:48.0230457Z Checking compatibility for Microsoft.IdentityModel.Clients.ActiveDirectory 5.0.5 with .NETStandard,Version=v2.0.
2019-10-03T21:31:48.0230500Z Checking compatibility for Microsoft.Rest.ClientRuntime.Azure.Authentication 2.4.0 with .NETStandard,Version=v2.0.
2019-10-03T21:31:48.0230543Z Checking compatibility for System.Security.Cryptography.X509Certificates 4.3.2 with .NETStandard,Version=v2.0.
...
...
...
2019-10-03T21:31:54.4289388Z All packages and projects are compatible with .NETCoreApp,Version=v2.1.
2019-10-03T21:31:54.4454996Z Committing restore...
2019-10-03T21:31:54.4459080Z Generating MSBuild file d:\a\r1\a\MyTool\DataFactory\CustomActivities\MyTool\obj\MyTool.csproj.nuget.g.props.
2019-10-03T21:31:54.4460039Z Generating MSBuild file d:\a\r1\a\MyTool\DataFactory\CustomActivities\MyTool\obj\MyTool.csproj.nuget.g.targets.
2019-10-03T21:31:54.4461496Z Writing assets file to disk. Path: d:\a\r1\a\MyTool\DataFactory\CustomActivities\MyTool\obj\project.assets.json
2019-10-03T21:31:54.4567260Z Writing cache file to disk. Path: d:\a\r1\a\MyTool\DataFactory\CustomActivities\MyTool\obj\MyTool.csproj.nuget.cache
2019-10-03T21:31:54.4573630Z Restore completed in 4.12 sec for d:\a\r1\a\MyTool\DataFactory\CustomActivities\MyTool\MyTool.csproj.
2019-10-03T21:31:54.4661557Z
2019-10-03T21:31:54.4662703Z NuGet Config files used:
2019-10-03T21:31:54.4663349Z d:\a\_temp\Nuget\tempNuGet_05ce1f4cc83beb812b37be120d7010969ab1a363.config
2019-10-03T21:31:54.4664039Z
2019-10-03T21:31:54.4664744Z Feeds used:
2019-10-03T21:31:54.4665067Z https://api.nuget.org/v3/index.json
2019-10-03T21:31:54.4785886Z
2019-10-03T21:31:54.4786633Z Installed:
2019-10-03T21:31:54.4796944Z 7 package(s) to d:\a\r1\a\MyTool\DataFactory\CustomActivities\MyTool\MyTool\MyTool.Logger\MyTool.Logger.csproj
2019-10-03T21:31:54.4803020Z 32 package(s) to d:\a\r1\a\MyTool\DataFactory\CustomActivities\MyTool\MyTool\MyTool.Common\MyTool.Common.csproj
2019-10-03T21:31:54.4803472Z 33 package(s) to d:\a\r1\a\MyTool\DataFactory\CustomActivities\MyTool\MyTool\MyTool.OutputProvider\MyTool.OutputProvider.csproj
2019-10-03T21:31:54.4803792Z 34 package(s) to d:\a\r1\a\MyTool\DataFactory\CustomActivities\MyTool\MyTool\MyTool.Output.IO\MyTool.Output.IO.csproj
2019-10-03T21:31:54.4804056Z 33 package(s) to d:\a\r1\a\MyTool\DataFactory\CustomActivities\MyTool\MyTool\MyTool.SearchFilter\MyTool.SearchFilter.csproj
2019-10-03T21:31:54.4804362Z 32 package(s) to d:\a\r1\a\MyTool\DataFactory\CustomActivities\MyTool\MyTool\MyTool.PiiData\MyTool.PiiData.csproj
2019-10-03T21:31:54.4805159Z 42 package(s) to d:\a\r1\a\MyTool\DataFactory\CustomActivities\MyTool\MyTool\MyTool.SearchHandler\MyTool.SearchHandler.csproj
2019-10-03T21:31:54.4805573Z 42 package(s) to d:\a\r1\a\MyTool\DataFactory\CustomActivities\MyTool.App\MyTool.App.csproj
2019-10-03T21:31:54.4805849Z 46 package(s) to d:\a\r1\a\MyTool\DataFactory\CustomActivities\MyTool\MyTool.csproj
2019-10-03T21:31:54.4806121Z Done executing task "RestoreTask".
2019-10-03T21:31:54.4806389Z 1>Done building target "Restore" in project "MyTool.csproj".
2019-10-03T21:31:54.4806658Z 1>Done Building Project "d:\a\r1\a\MyTool\DataFactory\CustomActivities\MyTool\MyTool.csproj" (Restore target(s)).
2019-10-03T21:31:54.5031887Z
2019-10-03T21:31:54.5032209Z Build succeeded.
2019-10-03T21:31:54.5032251Z 0 Warning(s)
2019-10-03T21:31:54.5032319Z 0 Error(s)
2019-10-03T21:31:54.5032343Z
2019-10-03T21:31:54.5032377Z Time Elapsed 00:00:16.08
2019-10-03T21:31:54.5417968Z ##[section]Finishing: dotnet restore
Any clues what could be going wrong?
This was happening because I had something in the 'Working Directory'. I just cleared the "Working directory" field. Before I had set it to the subfolder containing the .csproj file which was incorrect. The working directory should be the root.
I've upgraded two instances of Artifactory to 6.9.0 version. One of them works without issue(OpenJDK 1.8.131 on centos 7.4), but I see error in the artifactory.log on another instance(OpenJDK version "1.8.0_151" on OEL 6.9):
2019-04-11 08:10:49,379 [art-exec-15] [ERROR] (o.a.s.a.ArchiveIndexerImpl:162) - Failed to index 'repository-name:com/service/service/0.14.2.1154/service-0.14.2.1154.jar': Unexpected record signature: 0X622F2123
I've tried to switch artifactory to Oracle JDK 1.8.0_121 and OpenJDK 11.0.2 - it didn't help.
p.s.
REST API and Artifactory GUI return artifacts without any issue.
The issue isn't reproduced on small jars without dependencies.
I have updated my gnat to the latest version from AdaCore and trying to rebuild the latest AWS (Ada Web Server) also downloaded from AdaCore. I got some errors when building:
aws-services-web_block-context.ads:106:21: argument of pragma "SUPPRESS" is not valid check name
aws-services-web_block-context.ads:106:21: argument of pragma "SUPPRESS" is not valid check name
compilation of aws-services-web_block-context.adb failed
compilation of aws-services-web_block-registry.adb failed
gprbuild: *** compilation phase failed
make: *** [build-native] Error 4
What could have been wrong? Or, have I overlook something?
Thanks.
Adrian
The check that is invalid is Tampering_Check, which is to do with the resource-intensive ARM-specified checks on improper use of Containers (basically, is one part of the code trying to change the structure of a Container that another is already using?)
I don’t know why you’ve had this problem: both GNAT GPL 2016 and FSF GCC 6.1.0 are OK with the pragma. Are you sure you’re using the latest compiler?
One other thing to watch out for is that the master branch at Github may rely on compiler features not available in compiler releases available to unsupported customers; if using GNAT GPL 2016, maybe the gpl-2016 branch would be safer, if not up to date.
On some of our servers collective.monkeypatch does not work:
Unable to detect Zope version. Please make sure you have Zope 2.10.4 or newer installed.
2011-03-24 10:17:13 ERROR collective.monkeypatcher Could not patch because version not recognized. Wanted: [2, 13, 9], Installed: []
2011-03-24 10:17:13 INFO collective.monkeypatcher Preconditions for patching scope <class 'z3c.form.form.BaseForm'> not met (Zope2-=2.13.999)!
2011-03-24 10:17:13 ERROR collective.monkeypatcher Could not patch because version not recognized. Wanted: [2, 13, 9], Installed: []
2011-03-24 10:17:13 INFO collective.monkeypatcher Preconditions for patching scope <class 'z3c.form.group.GroupForm'> not met (Zope2-=2.13.999)!
We have tried the some buildout on different computers and cannot come up with reliable pattern why it is failing (probably something egg and version pindown related)
What could be the issue and how to
The Unable to detect Zope version. Please make sure you have Zope 2.10.4 or newer installed. comes from older Plone versions (version 3.0 and earlier, it was removed in the 3.1 line). It uses the old-style App.version_txt.getZopeVersion API to read a version.txt file from the Zope2 module directory, but that is not always written. I do not see it in my Zope2 installs installed with the plone.recipe.zope2install recipe in any case. This log message is otherwise harmless provided you do use Zope 2.10.4 or newer.
With the advent of a proper Zope2 egg, Plone now uses the pkg_resources module to make this test and in Zope 2.12 the getZopeVersion API uses pkg_resources internally as well. The collective.monkeypatcher precondition test also uses pkg_resources to introspect package versions.
From your Unable to detect Zope version log entry I infer that you are using an older Plone version (3.0 or older) and thus you are most likely using Zope 2.10. Zope 2.10 is not an egg, so there is no egg metadata for pkg_resources to get a version from. Thus the version test fails for any Zope version before 2.12.
The obvious work-around is to not use the package defining the monkeypatch on Zope servers older than 2.12. But you can also generate a fake egg with the version information included with the plone.recipe.zope2install recipe:
[zope2]
recipe = plone.recipe.zope2install
...
additional-fake-eggs =
Zope2 = 2.10.11
Fake eggs provide enough metadata for pkg_resources to get a version number, but the zope2install recipe writes a default Zope2 fake egg with a 0.0 version. By defining the fake egg with a version number you end up with pkg_resources giving you enough information to satisfy the precondition. You may have to upgrade your plone.recipe.zope2install version, I see some refactoring and bug-fixes have been applied to the way fake eggs are generated that may affect you.
I think the problem is in the preconditions attribute of your monkeypatch directive.
See documentation at http://pypi.python.org/pypi/collective.monkeypatcher