I actually found the answer to this question already, and just want to document my finding.
First of all, this problem is not specific to building the leveldown module for Windows PouchDB. From what I have read online, it is a fairly common problem.
It has to do with the fact that nw-gyp somehow forgot the target version of NW between the nw-gyp configure and nw-gyp build command. When this happens, a TyperError: Invalid Version: undefined would be thrown.
The solution is actually very simple, all you need to do is to set --target= again when you do nw-gyp build, like this:
nw-gyp configure --target=0.47.0
nw-gyp build --target=0.47.0
Related
I'm trying to setup Facebook Duckling on Windows 10.
When I execute: stack exec duckling-example-exe it produces the following error:
duckling-example-exe.EXE: /etc/zoneinfo/: getDirectoryContents:findFirstFile: does not exist (The system cannot find the path specified.)
I don't understand why I'm getting this error since I followed the recommendation on this GitHub thread which suggests replacing "/usr/share/zoneinfo/" in Duckling/exe/ExampleMain.hs with a link to a folder containing the zoneinfo files. You can see I replaced the path as suggested in the screenshot below:
I also tried adding a double slash as seen below - but it didn't help:
I tried with forward slash instead but this didn't help either:
Moreover, I don't understand where the path: /etc/zoneinfo/ is coming from, if the path is no longer present in ExampleMain.hs? Where is the compiler pulling the path from?
Thanks!
You need to run stack exec duckling-example-exe in the directory where the stack.yaml and project.yaml files of the duckling source code is that you are trying to modify. Otherwise it will use the version of duckling from stackage without your changes.
Before start describing how I'm getting this error, here is some important information:
It is essential the usage of the module-info.java in my project since jpackage won't work without using it.
I'm using SDK 14.0.2 (this is the minimum version that enables the usage of package)
Every comment will be appreciated; although, if you're going to comment something related to using a specific VM argument, I ask you to press ctrl+F to check if I'm already using the argument you're going to suggest -since there's a bunch of VM arguments in my build.gradle-
Ok, let's take a look about my issue:
First, focus on the VM argument below:
"--add-opens=java.base/java.lang.reflect=com.jfoenix",
If I don't use this argument, the following error pops up when the program runs:
java.lang.reflect.InaccessibleObjectException: Unable to make boolean java.lang.reflect.AccessibleObject.setAccessible0(boolean)
accessible: module java.base does not "opens java.lang.reflect" to module com.jfoenix
IMPORTANT -> This is how my view shows without using the mentioned VM argument (let's call it image 1):
https://snipboard.io/QJ5Fdc.jpg
"Ok, so why don't you just use the VM argument?"
Great question! Alright, let's add it to my VM arguments and run the program once again.
After doing so, this is how my view looks like right now (let's call it image 2): https://snipboard.io/fbhGxw.jpg
Great! This is exactly how my view should be (note that considering it worked as expected, I've got no errors this time).
So, with everything working, I can finally move on and run my jpackage gradle task. After doing so, things stop making sense, since after executing my program through a .exe (generated by jpackage) my view looks like the "image 1" view, regardless the fact that my project is working properly when I run it with the "run" gradle task.
Any thoughts on why is this happening? (My guess is that my module-info.java is the key to solve it, since every time I remove an "opens" statement, e.g.: "opens my.package.name to javafx.fxml", the program gets me almost the equal error).
Let me know whether any code samples will be needed. All assistance will be appreciated. Thanks!
edit: related GitHub issue: enter link description here
I don't know how the jpackage gradle task works, I use the jpackage tool inside the jdk via console and I used this arguments when creating the package
--java-options "--add-opens com.gluonhq.scenebuilder.kit/com.oracle.javafx.scenebuilder.kit.util.control.paintpicker=javafx.fxml --add-opens com.gluonhq.scenebuilder.kit/com.oracle.javafx.scenebuilder.kit.util.control.paintpicker.colorpicker=javafx.fxml"
In there I opened the PaintPicker from scene builder kit to javafx.fxml
As you can see I had to open two packages (they were really five but its too much to put in here) and you have to specify --add-opens for each package to open
I'm putting the code y used to package the application using jpackage
jpackage.exe
--module-path
.;D:\builds\ikonlibrowser\target\ikonlibrowser.jar;
D:\builds\ikonlibrowser\libs\icons\ikonli-antdesignicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-bootstrapicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-boxicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-bpmn-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-captainicon-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-carbonicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-codicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-coreui-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-dashicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-devicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-elusive-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-entypo-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-evaicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-feather-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-fileicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-fluentui-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-fontawesome-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-fontawesome5-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-fontelico-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-foundation-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-hawcons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-icomoon-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-ionicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-ionicons4-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-jamicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-ligaturesymbols-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-lineawesome-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-linecons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-maki-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-maki2-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-mapicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-material-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-material2-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-materialdesign-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-materialdesign2-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-medicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-metrizeicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-microns-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-ociicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-octicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-openiconic-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-paymentfont-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-prestashopicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-remixicon-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-runestroicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-simpleicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-simplelineicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-subway-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-themify-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-typicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-unicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-weathericons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-websymbols-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-whhg-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-win10-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-zondicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\scenebuilder-kit-16.0.0.jar;
D:\builds\ikonlibrowser\libs\jfoenix-9.0.10.jar
D:\builds\ikonlibrowser\libs\ikonli-core-12.2.0.jar;
D:\builds\ikonlibrowser\libs\ikonli-javafx-12.2.0.jar
--module jcc.app.ikonlibrowser/jcc.app.ikonlibrowser.Main
--name "Ikonli Browser" -d D:\builds\ikonlibrowser
--win-dir-chooser
--input D:\builds\ikonlibrowser\app
--vendor jCC
--app-version "1.0.0"
--java-options
"--add-opens com.gluonhq.scenebuilder.kit/com.oracle.javafx.scenebuilder.kit.util.control.paintpicker=javafx.fxml
--add-opens com.gluonhq.scenebuilder.kit/com.oracle.javafx.scenebuilder.kit.util.control.paintpicker.colorpicker=javafx.fxml
--add-opens com.gluonhq.scenebuilder.kit/com.oracle.javafx.scenebuilder.kit.util.control.paintpicker.rotator=javafx.fxml
--add-opens com.gluonhq.scenebuilder.kit/com.oracle.javafx.scenebuilder.kit.util.control.paintpicker.slider=javafx.fxml
--add-opens com.gluonhq.scenebuilder.kit/com.oracle.javafx.scenebuilder.kit.util.control.paintpicker.gradientpicker=javafx.fxml"
Of course this is only one line.
Now i'll explain it step by step:
--module-path This argument is used to specify the path for all the modules your app uses. Including the application .jar
--module This argument specifies the main class of the application. Putting first the module name and then the class full name.
--name This is to specify the app name.
-d Specifies the output path.
--win-dir-chooser Gives the option to select the installation path when installing the packaged app
--input Specifies a folder containing the external resources for your app
--vendor The vendor's name. Maybe your name
--app-version The version of your application
--java-options The jvm options
I hope it works for you, sorry for the delay.
I am a newbie in go and go-swagger. I am following steps in Simple Server tutorial in goswagger.io.
I am using Ubuntu 18.04, swagger v0.25.0 and go 1.15.6.
Following the same steps, there are a few differences of the files generated. For instance, goswagger.io's has find_todos_okbody.go and get_okbody.go in models but mine does not. Why is that so?
Link to screenshot of my generated files vs
Link to screenshot of generated files by swagger.io
Starting the server as written in the tutorial go install ./cmd/todo-list-server/ gives me the following error. Can anyone please help with this?
# my_folder/swagger-todo-list/restapi
restapi/configure_todo_list.go:41:8: api.TodosGetHandler undefined (type *operations.TodoListAPI has no field or method TodosGetHandler)
restapi/configure_todo_list.go:42:6: api.TodosGetHandler undefined (type *operations.TodoListAPI has no field or method TodosGetHandler)
The first step in goswagger.io todo-list is swagger init spec .... Which directory should I run this command in? I ran it in a newly created folder in my home directory. However, from the page, it shows the path to be ~/go/src/github.com/go-swagger/go-swagger/examples/tutorials/todo-list. I am not sure whether I should use go get ..., git clone ... or create those folders. Can someone advise me?
Thanks.
This is likely the documentation lagging behind the version of the code that you are running. As long as it compiles, the specific files the tool generates isn't so crucial.
This is a compilation error. When you do go install foo it will try to build the foo package as an executable and then move that to your GOPATH/bin directory. It seems that the generated code in restapi/configure_todo_list.go isn't correct for the operations code generated.
All you need to run this tutorial yourself is an empty directory and the swagger tool (not its source code). You run the commands from the root of this empty project. In order not to run into GOPATH problems I would initialise a module with go mod init todo-list-example before doing anything else.
Note that while the todo-list example code exists inside the go-swagger source, it's there just for documenting example usage and output.
What I would advice for #2 is to make sure you're using a properly released version of go-swagger, rather than installing from the latest commit (which happens when you just do a go get), as I have found that to be occasionally unstable.
Next, re-generate the entire server, but make sure you also regenerate restapi/configure_todo_list.go by passing --regenerate-configureapi to your swagger generate call. This file isn't always refreshed because you're meant to modify it to configure your app, and if you changed versions of the tool it may be different and incompatible.
If after that you still get the compilation error, it may be worth submitting a bug report at https://github.com/go-swagger/go-swagger/issues.
Thanks #EzequielMuns. The errors in #2 went away after I ran go get - u -f ./... as stated in
...
For this generation to compile you need to have some packages in your GOPATH:
* github.com/go-openapi/runtime
* github.com/jessevdk/go-flags
You can get these now with: go get -u -f ./...
I think it's an error of swagger code generation. You can do as folloing to fix this:
delete file configure_todo_list.go;
regenerate code.
# swagger generate server -A todo-list -f ./swagger.yml
Then, you can run command go install ./cmd/todo-list-server/, it will succeed.
The autofunction works perfectly on my local machine but on server it does not show anything. I check the log and find the following thing,
WARNING: autodoc: failed to import function blablabla; the following exception was raised: No module named 'numpy'.
I suppose installing packages is not a must on sphinx. I only need sphinx to read my docstring and generate documentation.
Well, after several hours of investigation I am able to answer my question. Using autodoc_mock_imports does the trick.
I need to configure WireGuard to bring up a VPN on boot on an Embedded Linux device.
My recipe installs a /etc/wireguard/wg0.conf pretty much like the examples found through the Internet.
Then I try to enable the service on SystemD like this on my wireguard.bb:
SYSTEMD_SERVICE = "wg-quick#wg0.service"
SYSTEMD_AUTO_ENABLE = "enable"
But bitbake throws me an error:
ERROR: Function failed: SYSTEMD_SERVICE_my-conf value wg-quick#wg0.service does not exist
I checked the temporary directory and file wg0.conf appears in the correct places but it seems that bitbake's SYSTEMD_SERVICE doesn't know how to expand the "wg0" after # sign.
If I try without the interface name (wg0):
SYSTEMD_SERVICE = "wg-quick#.service"
Bitbake is happy and finalizes my recipe, but it is not what systemd is expecting. Starting a service without an interface makes no sense...
Then I tried another approach and split the "wireguard" package itself from the configuration ("wireguard-conf" package) and added DEPENDS and RDEPENDS on "wireguard".
This got even worse since my wireguard-conf.bb recipe does not contain a "wg-quick#.service" file (it comes from the dependency "wireguard").
Well,
I don't know how to properly fix it and any suggestions will be highly appreciated.
Additional Info
I am using Yocto 2.0.3 in this project (with no hope of updating it).
Thanks to #TomasNovotny comments I managed to compare my "systemd.bbclas" against Github and noticed a change in systemd_populate_packages() that seems to solve the problem.
It works in newer OpenEmbedded (looks like in krogoth, version 2.1 released Apr 2016) and it is introduced by this commit. It works for me in rocko (version 2.4 released Oct 2017). According to j4x's comment, it doesn't work in jethro (version 2.0, Nov 2015).
For older (and currently unsupported OpenEmbeddeds) you can try to backport the patch or handle the symlinks for enabling the service in do_install().
Also please note that SYSTEMD_SERVICE_${PN} variable is package specific, so the _${PN} suffix has to be added (see manual).
I've also tried to enable OpenVPN with my profile (in Yocto rocko) without success.
Finally, I've made it working by providing OpenVPN recipe extension instead of custom one. So, the openvpn_%.bbappend file looks like:
inherit systemd
SYSTEMD_SERVICE_${PN} = "openvpn#clientprofile.service"
SYSTEMD_AUTO_ENABLE = "enable"
do_install_append() {
install -d ${D}${sysconfdir}/openvpn/
ln -sf /data/etc/openvpn/clientprofile.conf ${D}${sysconfdir}/openvpn/clientprofile.conf
}
As you can see, I'm using a symlink to my profile instead of the normal file. You can install a normal OpenVPN profile file instead of making symlink and it also works fine.