vs-mad-remote build failed with error CordovaModuleLoadError 4.1.2 - visual-studio-cordova

When I use vs-mda-remote to test cordova on mac, it failed with an error:
error CordovaModuleLoadError 4.1.2
and when I use vs-mda-remote test, the error is:
error CordovaModuleLoadError 4.3.0
vs-mda-remote
this start the server ok.
And I try the cordova, it can build success. Following is the full output:
New build request submitted:
/build/tasks?command=build&vcordova=4.1.2&cfg=release
{ 'accept-language': 'zh-CN',
host: '192.168.1.244:3000',
connection: 'keep-alive',
'transfer-encoding': 'chunked' }
New build request submitted for cordovaVersion: 4.1.2; buildCommand: build; configuration: release
Build will be executed under: /Users/czcz1024/remote-builds/builds/610
Saving build request payload to : /Users/czcz1024/remote-builds/builds/610
Saved upload to /Users/czcz1024/remote-builds/builds/610/upload_610.tgz
Extracting /Users/czcz1024/remote-builds/builds/610/upload_610.tgz to /Users/czcz1024/remote-builds/builds/610/cordovaApp...
POST /build/tasks?command=build&vcordova=4.1.2&cfg=release 202 2291ms - 495b
GET /build/tasks/610 200 2ms - 495b
Extracted app contents from uploaded build request to /Users/czcz1024/remote-builds/builds/610/cordovaApp. Requesting build.
Taking 610 as current build
Building cordova app BlankCordovaApp1 at appDir /Users/czcz1024/remote-builds/builds/610/cordovaApp
Opened build log file /Users/czcz1024/remote-builds/builds/610/build.log
GET /build/tasks/610 200 1ms - 585b
Done building 610 : error CordovaModuleLoadError [ '4.1.2' ]
Done with currentBuild. Checking for next build in queue.
GET /build/tasks/610 200 1ms - 621b
GET /build/tasks/610/log 200 6ms
and follow is output run test
New build request submitted:
/build/tasks?vcordova=4.3.0&cfg=release&command=build&options=--emulator
{ host: 'localhost:3000',
connection: 'close',
'transfer-encoding': 'chunked' }
New build request submitted for cordovaVersion: 4.3.0; buildCommand: build; configuration: release
Build will be executed under: /Users/czcz1024/remote-builds/builds/611
Saving build request payload to : /Users/czcz1024/remote-builds/builds/611
Saved upload to /Users/czcz1024/remote-builds/builds/611/upload_611.tgz
Extracting /Users/czcz1024/remote-builds/builds/611/upload_611.tgz to /Users/czcz1024/remote-builds/builds/611/cordovaApp...
POST /build/tasks?vcordova=4.3.0&cfg=release&command=build&options=--emulator 202 217ms - 505b
Extracted app contents from uploaded build request to /Users/czcz1024/remote-builds/builds/611/cordovaApp. Requesting build.
Taking 611 as current build
Building cordova app HelloCordova at appDir /Users/czcz1024/remote-builds/builds/611/cordovaApp
Opened build log file /Users/czcz1024/remote-builds/builds/611/build.log
Done building 611 : error CordovaModuleLoadError [ '4.3.0' ]
Done with currentBuild. Checking for next build in queue.
GET /build/tasks/611 200 1ms - 627b
what's wrong?

This might be a permissions issue with your .npm folder where the new version of vs-mda-remote tries to install the Cordova package.
Can you try to run the following 2 commands:
$ sudo npm cache clear
$ sudo chown -R `whoami` ~/.npm
And then restart your vs-mda-remote server?

Related

Deleting artifacts with JFrog CLI gives "200 OK", but artifacts are not deleted

I have created an AQL that gives me a number of artifacts I want to delete from Artifactory. I can run a search command with the jfrog-cli on it, and get the correct list of artifacts:
jfrog rt s --spec search-aql.json
When I try to delete the same artifacts with the same AQL, everything seems fine:
The artifacts are listed
I get a questions of whether to delete them or not.
I answer yes, and the command goes on to log the deletion of each item.
Each item seems to be returned and printed to my console, followed by this message:
[Error] Artifactory response: 200 OK
Binaries are also printed to the console, so the console output is really messy.
In the end, I get a summary:
{
"status": "failure",
"totals": {
"success": 0,
"failure": 68
}
}
[Error] Artifactory response: 200 OK
With the same user, I can delete individual artifacts using the REST API, so the user does have the necessary rights to do deletion.
I am on version 1.38.2 of the JFrog CLI and 7.2.1 of Artifactory.
Can anybody help me understand what is wrong or how to debug this problem?
Update 2020/08/06:
When setting the log level to debug as suggested by #Prostagma, I get two extra lines of logging for each artifact. Here is an example of logging for two artifacts:
[Info] [Thread 1] Deleting <path>/<artifact>.jar.sha512
[Debug] Sending HTTP DELETE request to: https://repo.enonic.com/<path>/<artifact>.jar.sha512
[Error] Artifactory response: 200 OK
<sha512 hash>
[Info] [Thread 0] Deleting <path>/<artifact>.jar
[Debug] Sending HTTP DELETE request to: https://repo.enonic.com/<path>/<artifact>.jar
[Error] Artifactory response: 200 OK
<binary contents of <artifact>.jar
More detailed answer to whomever encounter this issue in the future -
By diving into the code we can see that the CLI expects to get status 204 from Artifactory after deletion:
https://github.com/jfrog/jfrog-client-go/blob/v0.12.0/artifactory/services/delete.go#L110
In some installations, there may be a proxy that changes the response codes, for example when Artifactory returns 204, it may change the status code to 200.
Please make sure that your proxy doesn't change the status codes returned from Artifactory.

I am having an issue recursively pulling a folder from Artifactory using JFrog CLI

I am using an Artifactory server. I am trying to store a folder of third party files in my repo.
I was able to upload a zipfile and explode it so I have my files in MY_REPO/MY_FOLDER/
I am trying to recursively download the contents of the folder using:
jfrog rt dl --recursive MY_REPO/MY_FOLDER
I have enabled debug and I get:
[Info] Searching items to download...
[Debug] Searching Artifactory using AQL query:
items.find({"repo": "MY_REPO","path": {"$ne": "."},"$or": [{"$and":[{"path": {"$match": "MY_FOLDER"},"name": {"$match": "*"}}]},{"$and":[{"path": {"$match": "MY_FOLDER/*"},"name": {"$match": "*"}}]}]}).include("name","repo","path","actual_md5","actual_sha1","size","type","property")
[Error] Artifactory response: 405 Method Not Allowed
{
"status": "failure",
"totals": {
"success": 0,
"failure": 0
}
}
[Error] Download finished with errors. Please review the logs
I have tried variations of MY_FOLDER, MY_FOLDER/, MY_FOLDER/. and with/without recursive. I get the same error.
I know I have permissions because I can upload a file:
jfrog rt u TEST_FILE MY_FOLDER
succeeds just fine. But I can't turn around and pull it down:
jfrog rt dl MY_FOLDER/TEST_FILE
results in:
[Info] Searching items to download...
[Debug] Searching Artifactory using AQL query:
items.find({"repo": "MY_REPO","$or": [{"$and":[{"path": {"$match": "."},"name": {"$match": "MY_FILE"}}]}]}).include("name","repo","path","actual_md5","actual_sha1","size","type","property")
[Error] Artifactory response: 405 Method Not Allowed
{
"status": "failure",
"totals": {
"success": 0,
"failure": 0
}
}
[Error] Download finished with errors. Please review the logs
I'm not certain what isn't working, there's nothing on StackOverflow, JFrog dox or elsewhere with issues using jfrog cli. :(
My jfrog-cli.conf looks like this:
{
"artifactory": [
{
"url": "https://SITE_NAME:PORT_NUM/artifactory/list/MY_REPO/",
"user": "USERNAME",
"serverId": "MY_REPO",
"isDefault": true,
"apiKey": "API_KEY_FROM_ARTIFACTORY"
}
],
"Version": "1"
}
UPDATED
I was running version 1.22.1 for Windows 64-bit. I am now using jfrog cli version 1.34.1 for Windows 64-bit. Per first comment I updated to the latest binary and tried running a search, both with and without MY_FOLDER:
jfrog rt s TEST_FILE and
jfrog rt s MY_FOLDER/TEST_FILE
Both return the same results. I enabled DEBUG and with the newer binary I actually seem to get two errors. The older binary just reported the 405 error. The newer one reports a 404 (Not Found) then reports the error as a 405 Method Not Allowed.
[Debug] Sending usage info...
[Info] Searching artifacts...
[Debug] Searching Artifactory using AQL query:
items.find({"$or":[{"$and":[{"repo":"TEST_FILE","path":{"$match":"*"},"name":{"$match":"*"}}]}]}).include("name","repo","path","actual_md5","actual_sha1","size","type","modified","created","property")
[Debug] Sending HTTP POST request to: https://SITE_NAME:8443/artifactory/list/MY_REPO/api/search/aql
[Debug] Sending HTTP GET request to: https://SITE_NAME:8443/artifactory/list/MY_REPO/api/system/version
[Debug] Artifactory response: 404 Not Found
{
"errors": [
{
"status": 404,
"message": "File not found."
}
]
}
[Error] Artifactory response: 405 Method Not Allowed
Which is still odd because I'm looking for a file I just uploaded. I even deleted the uploaded file and re-uploaded to verify the newer cli can still upload files. I tried a wildcard search to find all files but it returned the same error.
I can also see the file where it is supposed to be using the Artifactory web interface, and download the file and delete it. So Artifactory knows it's there and I have access to it. :-/
The url in your configuration should only contain the base url of Artifactory, i.e: "SITE_NAME:PORT_NUM/artifactory".
You should provide the directory path in the upload and download commands.
Use the ping command to verify your setup works, then progress from there.
BTW: The reason the upload works but download fails is by coincidence. The upload command just uses the upload REST API which expects a path (which you provided in your config), but the download command first sends a search request that does not expect a path, so it fails.

Source file not available anymore

I'm facing something new in my experience. An updated Yocto environment fails to build while fetching MariaDB:
WARNING: mariadb-5.5.64-r0 do_fetch: Failed to fetch URL https://downloads.mariadb.org/f/mariadb-5.5.64/source/mariadb-5.5.64.tar.gz, attempting MIRRORS if available
ERROR: mariadb-5.5.64-r0 do_fetch: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export DBUS_SESSION_BUS_ADDRESS="unix:abstract=/tmp/dbus-BIEhFRRkoA"; export SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"; export PATH="/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/sysroots-uninative/x86_64-linux/usr/bin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/layers/openembedded-core/scripts:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot-native/usr/bin/arm-openstlinux_eglfs-linux-gnueabi:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot/usr/bin/crossscripts:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot-native/usr/sbin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot-native/usr/bin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot-native/sbin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/recipe-sysroot-native/bin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/layers/openembedded-core/bitbake/bin:/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/hosttools"; export HOME="/home/osboxes"; /usr/bin/env wget -t 2 -T 30 --passive-ftp --no-check-certificate -P /local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/downloads 'https://downloads.mariadb.org/f/mariadb-5.5.64/source/mariadb-5.5.64.tar.gz' --progress=dot -v failed with exit code 8, output:
--2019-11-03 12:10:45-- https://downloads.mariadb.org/f/mariadb-5.5.64/source/mariadb-5.5.64.tar.gz
Resolving downloads.mariadb.org (downloads.mariadb.org)... 116.203.207.31, 2a01:4f8:c2c:b04e::1
Connecting to downloads.mariadb.org (downloads.mariadb.org)|116.203.207.31|:443... connected.
HTTP request sent, awaiting response... 302 FOUND
Location: http://ftp.hosteurope.de/mirror/mariadb.org//mariadb-5.5.64/source/mariadb-5.5.64.tar.gz [following]
--2019-11-03 12:10:46-- http://ftp.hosteurope.de/mirror/mariadb.org//mariadb-5.5.64/source/mariadb-5.5.64.tar.gz
Resolving ftp.hosteurope.de (ftp.hosteurope.de)... 80.237.136.138, 2a01:488:10:1::50ed:888a
Connecting to ftp.hosteurope.de (ftp.hosteurope.de)|80.237.136.138|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2019-11-03 12:10:46 ERROR 404: Not Found.
ERROR: mariadb-5.5.64-r0 do_fetch: Fetcher failure for URL: 'https://downloads.mariadb.org/f/mariadb-5.5.64/source/mariadb-5.5.64.tar.gz'. Unable to fetch URL from any source.
ERROR: mariadb-5.5.64-r0 do_fetch: Function failed: base_do_fetch
ERROR: Logfile of failure stored in: /local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/build-openstlinuxeglfs-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-openstlinux_eglfs-linux-gnueabi/mariadb/5.5.64-r0/temp/log.do_fetch.11382
ERROR: Task (/local/STM32MP15-Ecosystem-v1.1.0/Distribution-Package/openstlinux-4.19-thud-mp1-19-10-09/layers/meta-openembedded/meta-oe/recipes-dbs/mysql/mariadb_5.5.64.bb:do_fetch) failed with exit code '1'
Now I see the URLs are hardcoded into: layers/meta-openembedded/meta-oe/recipes-dbs/mysql/mariadb.inc:
SUMMARY = "A robust, scalable, and reliable SQL server"
HOMEPAGE = "http://mariadb.org"
SECTION = "libs"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
SRC_URI = "https://downloads.mariadb.org/f/${BP}/source/${BP}.tar.gz \
file://fix-cmake-module-path.patch \
file://remove-bad-path.patch \
file://fix-mysqlclient-r-version.patch \
file://my.cnf \
file://mysqld.service \
file://install_db.service \
file://install_db \
file://mysql-systemd-start \
file://configure.cmake-fix-valgrind.patch \
file://fix-a-building-failure.patch \
file://change-cc-to-cc-version.patch \
file://0001-disable-ucontext-on-musl.patch \
"
Hence, I tried to retrieve the same file (mariadb-5.5.64.tar.gz) on the Internet and I found this:
https://downloads.mariadb.org/f/mariadb-5.5.64/source/mariadb-5.5.64.tar.gz/from/http%3A//ftp.hosteurope.de/mirror/archive.mariadb.org/?serve
that seems very close to the one above, but the working one has another path as suffix.
I don't understand if they (the mariadb maintainers) changed the URLs or there is an error in the meta-openembedded recipe.
The maintainers of FOSS software, in this case the MariaDB Foundation, usually don't make promises that download URLS will remain unchanged. MariaDB uses a scheme to help downloaders find a nearby mirror site, and that's what you found.
Those mirrorfinders rely on stuff like http redirect operations. Browsers are good at handling those operations. Downloading code built into other programs may not be.
You may find it helpful to edit that URL in that recipe to point to the exact ftp file you need. It appears to be in this ftp folder.
http://ftp.hosteurope.de/mirror/archive.mariadb.org/mariadb-5.5.64/source/

Error making request to CodeCommit: Could not retrieve

I have pushed my last work to the repository, however, when I try to deploy, I get this error:
$ eb deploy myapp -v
Password:
INFO: Deploying code to myapp in region us-east-1
INFO: Getting version label from git with git-describe
INFO: Pushing local code to codecommit with git-push
INFO: Creating AppVersion app-V-2_0-90-g57b9-181013_080409
ERROR: InvalidParameterValueError - "Error making request to CodeCommit: Could not retrieve 57b9246856a66460a7d04161d3f107f0553ac6ce (Service: AWSCodeCommit; Status Code: 400; Error Code: CommitIdDoesNotExistException; Request ID: 6d67928b-cea5-11e8-8620-d3a635300337)"
How can I get more details about that InvalidParameterValueError as in the error above?
What does CommitIdDoesNotExistException mean? I already pushed my latest commit.
Any idea?

Firebase serve not working

I've been migrating to Firebase 3.0, and with the new changes, we have to use firebase serve on the CLI for local development, and I believe this defaults to port 5000. However, after going through the init process, running firebase serve doesn't do anything after "Starting Firebase development server..." even with specifying port 5000. Attempted fixes:
Tried with other ports, like 5001
Reinstalled Node (4.x and 6.x)
Reinstalled NPM
Removed firebase-cli (since firebase-tools is now being used)
Reinstalled firebase-tools with npm
Tweaked firebase init endlessly
Tried on different user accounts on my computer
Restarted computer
Checked that port 5000 was free by $lsof -i tcp:5000
Tested address variants like localhost:5000 and like 127.x and 192.x
Here is the debug log:
[debug] ----------------------------------------------------------------------
[debug] Command: /usr/local/bin/node /usr/local/bin/firebase serve -p 5000 --debug
[debug] CLI Version: 3.0.0
[debug] Platform: darwin
[debug] Node Version: v6.2.0
[debug] Time: Sun May 22 2016 01:29:59 GMT+0200 (CEST)
[debug] ----------------------------------------------------------------------
[debug]
[info] Starting Firebase development server...
[info]
[info] Project Directory: /Users/user/Documents/localdev/spfwork
Any thoughts on how to fix?
Thank you for your help.
Fixed - firebase serve from firebase-tools (npm) was missing a logger for some errors, which I added on a pull request here: https://github.com/firebase/firebase-tools/pull/143
My error was that localhost was not starting for some reason, so I changed the command to firebase serve -p 5000 -o 127.0.0.1, and specifying the listen port allowed the server to start successfully.
For reference, the error was Error: getaddrinfo ENOTFOUND localhost
You could just change your /etc/hosts file and use firebase serve normally.
To do this:
Launch Terminal
Type sudo nano /etc/hosts and press Return
Enter your admin password Paste
Paste
##
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
Save the file by pressing Ctrl + O
Exit with Ctrl + X
This should fix it.
See this for more
If Firebase cannot find the 'Public' folder, this error might show up. In that case, the error can be resolved by putting index.html and other static files and app assets of the website within the public folder, and executing firebase deploy at the Firebase CLI again.

Resources