Unable to set-up Libre office development environment - development-environment

I'm trying to setup up LoDe in Windows 10, where I'm installing it on the D:/ drive.
I'm following this link - https://wiki.documentfoundation.org/Development/lode and whenever I 'run' the ./setup command It freezes at - Resolving www.nasm.us
Though I have checked with the ./setup --prereq and cat README that I meet with all the perquisites. Here's the text from Cygwin.bat window
[username]#DESKTOP-[no.] /cygdrive/d/Files/Libre_office/lode
$ ./setup
Check directory 'packages' ... : Exist
Check directory 'opt' ... : Exist
Check directory 'ext_tar' ... : Exist
Check directory 'adm' ... : Exist
Check directory 'tb' ... : Exist
git repo '/cygdrive/d/Files/Libre_office/lode/adm/buildbot' exist
ant already installed
junit Already Installed
Check directory '/cygdrive/d/Files/Libre_office/lode/opt/bin' ... : Exist
--2018-03-25 13:09:03-- http://www.nasm.us/pub/nasm/releasebuilds/2.11.06/win32/nasm-2.11.06-win32.zip
Resolving www.nasm.us (www.nasm.us)... 198.137.202.136, 2607:7c80:54:e::136
Connecting to www.nasm.us (www.nasm.us)|198.137.202.136|:80... failed: Connection timed out.
Connecting to www.nasm.us (www.nasm.us)|2607:7c80:54:e::136|:80... failed: Network is unreachable.
/cygdrive/d/Files/Libre_office/lode/bin/utils_Cygwin.sh: line 35: module: parameter null or not set
Note: My internet is working perfectly and there are no speed fluctuations or anything.

nasm.us seems to be down
edit "lode\bin\utils_Cygwin.sh"
replace
local pack_file="nasm-2.11.06-win32.zip"
local pack_dir="nasm-2.11.06"
local http_file="http://www.nasm.us/pub/nasm/releasebuilds/2.11.06/win32/nasm-2.11.06-win32.zip"
with
local pack_file="nasm-2.12.02-win32.zip"
local pack_dir="nasm-2.12.02"
local http_file="http://mirrors.kodi.tv/build-deps/win32/nasm-2.12.02-win32.zip"

Related

How to force OpenAPI Generator CLI to use pre-downloaded .jar file?

I have installed (via npm) openapi-generator-cli on my WSL running Ubuntu 22.04 image, with correctly configured HTTP_PROXY and HTTPS_PROXY environment variables.
The problem is, running any command (including sudo openapi-generator-cli help) results in OAG-CLI attempting to download the .jar file from maven.org, which end with connection getting refused for unknown reason (SSL cert not listed as trusted? WSL-exclusive bug? corporate proxy having an edge case?).
Instead of dealing with all that, I realised I can just download the latest (as per official website) .jar file:
https://repo1.maven.org/maven2/org/openapitools/openapi-generator-cli/6.2.1/openapi-generator-cli-6.2.1.jar
via browser and place it manually for OAG-CLI to use.
I have edited the auto-generated openapitools.json just so:
{
"$schema": "node_modules/#openapitools/openapi-generator-cli/config.schema.json",
"spaces": 2,
"generator-cli": {
"version": "6.2.1",//same version as .jar
"storageDir": "."//see below
}
}
Unfortunately, despite placing two copies of the .jar file (one named openapi-generator-cli-6.2.1.jar, one named openapi-generator-cli.jar) in both the "current" folder and /usr/libs/openapi, and trying the following values for storageDir:
.
./
/usr/libs/openapi
/usr/libs/openapi/
~/usr/libs/openapi
~/usr/libs/openapi/
every single run of sudo openapi-generator-cli help resulted in an immediate Downloading 6.2.1 ... message (followed by connection refused error some time later).
What else do I need to do to make OAG-CLI use the .jar within storageDir instead of trying to download a new copy?
(Answer containing just the structure and contents of a folder created by "storageDir": "~/foo" would allow me to reverse-engineer a working setup.)

VS Code on Chromebook Penguin with Remote SSH: Could not establish conntection to the "servername", the VS Code Server failled to start

I installed VS code on Penguin on an Acer Chromebook R11.
I followed the steps for Debian here : https://code.visualstudio.com/docs/setup/linux
It works like a charm but I need to connect to my remote dev server using the official extension RemoteSSH by Microsoft.
Then I configured a .ssh folder for the user with correct permissions : https://gist.github.com/grenade/6318301
Now I get :
Could not establish conntection to the "servername", the VS Code Server failled to start
The detailled log is :
[11:39:39.572] Resolver error: The VS Code Server failed to start
[11:39:39.609] TELEMETRY: {"eventName":"resolver","properties":{"outcome":"failure","reason":"ExitCode","askedPw":"0","askedPassphrase":"1","asked2fa":"0","askedHostKey":"0","gotUnrecognizedPrompt":"0","remoteInConfigFile":"1"},"measures":{"resolveAttempts":1,"exitCode":32,"retries":1}}
[11:39:39.620] ------
I don't have any idea of what it could be. Do you have one ?
I was having a similar issue and I resolved it by deleting the ".vscode-server" directory that was created on my server. It's a hidden directory that is created in the home directory (you can use "ls -la" to display all the files I believe). My hunch is that some incorrect data is being cached there so deleting the directory will give you a clean slate.
After deleting, you can try connecting again through remote-ssh on vscode.

Puppet Does not load class in custom module

A beginner environment with Puppet(3.8.4)+Apache(2.2.15)+Passenger on CentOS6.5
An agent run returns with
Error: /File[/var/lib/puppet/lib]: Could not evaluate: Could not retrieve
information from environment production source(s)
puppet://puppetmaster/plugins
Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
Puppet::Parser::AST::Resource failed with error ArgumentError: Could not
find declared class mediawiki at
/etc/puppet/environments/production/manifests/nodes.pp:10 on node wikitest
This is sequence of installing the module:
$>sudo puppet module generate my-mediawiki --environment production
$>sudo mv my-mediawiki mediawiki (just renaming the folder)
$sudo puppet module list
/etc/puppet/modules (no modules installed)
/usr/share/puppet/modules (no modules installed)
I have tried adding $confdir/environments/production/modules to environment.conf of the production environment and
to the basemodulepath in puppet.conf as the first entry, but it doesn't seem to be looking there.
$confdir/environments/production/modules/mediawiki/manifests/init.pp has the empty class declaration. '$confdir/environments/production/nodes.pp`
has the class statements in both nodes and both have the same error.
I've already tried:
1) removing the module and trying again, with all the puppet service stopped/started etc
2) there are no spelling or quotation mark errors
3) I've modified metadata.json in the mediawiki folder to be same as folder name just in case that mattered, but no luck.
4) Certificates are fine, communication is fine. I have another class defined as resource within the nodes.pp file and that runs fine.
Any help appreciated!

How to open Virtual Box on Windows 10

I am unable to access the virtual box that I initialized with the "vagrant up" command. I now get this:
[C:\web\Homestead]vagrant global-status
id name provider state directory
------------------------------------------------------------------------
13650ef default virtualbox running C:/web/Homestead
The above shows information about all known Vagrant environments
on this machine. This data is cached and may not be completely
up-to-date. To interact with any of the machines, you can go to
that directory and run Vagrant, or you can use the ID directly
with Vagrant commands from any directory. For example:
"vagrant destroy 1a2b3c4d"
[C:\web\Homestead]vagrant ssh 13650ef
C:/web/Homestead/Vagrantfile:4: warning: already initialized constant
....
The provider 'virtualbox' that was requested to back the machine
'default' is reporting that it isn't usable on this system. The
reason is shown below:
The executable 'cygpath' Vagrant is trying to run was not
found in the %PATH% variable. This is an error. Please verify
this software is installed and on the path.
I am running Windows 10 and set my environment variables, as follows:
Path c:\php;C:\Program Files\Oracle\VirtualBox;
C:\Program Files\Git\usr\bin;C:\cygwin64;
C:\Users\Kevin\AppData\Roaming\npm
The cygpath file it seeks is clearly under both c:\Program Files\Git\usr\bin and under C:\cygwin64.
I tried to access the virtual box through Putty, but got the simple message "connection refused". I have used Puttygen to convert the ssh keys to Putty ppk files.
I have tried to retrace my steps initializing the virtual box, but I fail to see how to step forward and open the box.
Should I destroy my virtual box and start over?
Try to change the PATH paths with 'Program Files' to Progra~1 paths or to wrap each path item with double-quotes, e.g.:
Path c:\php;"C:\Program Files\Oracle\VirtualBox"; "C:\Program
Files\Git\usr\bin";C:\cygwin64; C:\Users\Kevin\AppData\Roaming\npm
or
Path c:\php;C:\Progra~1\Oracle\VirtualBox;
C:\Progra~1\Git\usr\bin;C:\cygwin64;
C:\Users\Kevin\AppData\Roaming\npm

Vagrant for web server with shared folders: Apache breaks file permissions if it tries to stat a file before it exists

I'm not sure if this is an issue with vagrant, virtualbox or a configuration issue inside the box itsef, however:
Using the following setup: Apache is running in the guest with its server root set to /srv/http, this is a synched folder which points to ./public_html on the host.
While most of the time it works as expected, the following steps causes an issue
1) Navigate to a file that doesn't exist localhost:8080/test2.css -- shows a 404 error as expected but correctly connects to the guest which is serving the error
2) Create test2.css with some content and place it in public_html
3) Reload localhost:8080/test2.css -- Still shows a 404 error even though the file now exists
4) To debug, run vagrant ssh and then ls /srv/http. Which shows:
ls: cannot access test2.css: No such file or directory
So it's seeing the file, sort of but it shows without any permissions:
-????????? ? ? ? ? test2.css
-rw-rw-r-- 1 vagrant 7 Oct 23 11:13 test3.css
If I then re-save the file as test3.css, a file that hasn't yet been accessed it works perfectly. E.g. on the host, save the file I had open as test3.css and then navigate to it, it works as expected!
Any ideas? On why this might be?
In short: If apache has tried to read a file that doesn't exist, creating that file will then cause it to have invalid permissions. If apache has never tried to read the file before, it can be created and work as expected.
Thanks for any help, I'm really confused by this!
This turned out to be a kernel bug on the guest. Upgrading to 4.2.4 using the same Vagrant/Virtualbox/Guest Modules solved the issue.