I Just built Nodejs and installed 0.10.6 then uninstalled yo+grunt-cli+bower+generator-webapp and reinstalled to latest using npm -g,
yo webapp
But now live reload doesnt work, cant see any errors either in chrome devtools
yo -v: 1.0beta5
grunt-cli v0.1.8 and grunt v0.4.1
bower -v: 0.9.2
node -v: 0.10.6
npm -v: 1.2.18
grunt server shows the watch task: time + the name of file changed
tried : changing the port number in Gruntfile to.. LIVERELOAD_PORT = 34729; nogo :(
my older webapp projects still work fine
Lost..
Thanks
--------------------- UPDATE
1. moved lrSnippet to 1st position in Grunfile.js
2. in index.js moved
end.call(res, res.data, encoding);
outside the if Block
Now it works Partially :
summary :
1. changes to index.html > reloads ok
2. changes to main.scss > reloads ok
3. changes to my.sass > Not OK
after 3rd step
1. changes to index.html > Not OK
2. changes to main.scss > Not OK
4. changes to hello.coffe > Not OK
After step 4
1. changes to index.html > ok
2. changes to main.scss > ok
//------------------------------------- index.html
Changes to index.html
reload ok
grunt server window logs change and issues reload command
grunt server window grab =
Running "watch" task
Waiting...OK
>> File "app/index.html" changed.
Running "watch" task
... Reload app/index.html ...
Completed in 0.002s at Sat May 18 2013 12:47:58 GMT+0530 (IST) - Waiting...
//------------------------------------- main.scss
Changes to main.scss
reload ok
grunt server window grab =
>> File "app/styles/main.scss" changed.
Running "compass:server" (compass) task
overwrite .tmp/styles/main.css
unchanged app/styles/my.sass
Running "watch" task
Completed in 1.906s at Sat May 18 2013 12:48:24 GMT+0530 (IST) - Waiting...
OK
>> File ".tmp/styles/main.css" changed.
Running "watch" task
... Reload .tmp/styles/main.css ...
Completed in 0.002s at Sat May 18 2013 12:48:24 GMT+0530 (IST) - Waiting...
//------------------------------------- my.sass
changes to my.sass
reload not ok (not reloading)
grunt server window grab =
Running "watch" task
Waiting...OK
>> File "app/styles/my.sass" changed.
Running "compass:server" (compass) task
unchanged app/styles/main.scss
unchanged .tmp/images/generated/design-s65ab268e46.png
overwrite .tmp/styles/my.css
Running "watch" task
Completed in 0.602s at Sat May 18 2013 13:00:19 GMT+0530 (IST) - Waiting...
//-------------------------------------
After the my.sass is changed
changes made to index.html or main.scss r not shown in grunt server window
the Watch command doesnt log anything.
changes r not reloaded
//-------------------------------------
Restarted Grunt Server
//------------------------------------- hello.coffee
grunt server window grab =
OK
>> File "app/scripts/hello.coffee" changed.
Running "coffee:dist" (coffee) task
File .tmp/scripts/hello.js created.
Running "watch" task
Completed in 0.011s at Sat May 18 2013 13:34:56 GMT+0530 (IST) - Waiting...
//-------------------------------------
There is a bug with the current livereload/yo setup. Here are the details alongside a fix for the problematic dependency (connect-livereload).
https://github.com/yeoman/generator-webapp/issues/63
Three things which you can make sure to diagnose the issue further.
Make sure you're on the latest version npm update -g yo
You shouldn't be using LiveReload plugin explicitly, it conflicts with Yeoman watch command while running
Your port (in gruntfile.js) might be using by some other process, try to exit from the terminal, change the port and it see it works or not.
The problem is yeoman doesn't change the port automatically in the current version, that's where it stopped working if you close it forcefully in the current terminal session.
The same issue has been discussed here - https://github.com/yeoman/yeoman/issues/938
If you still see the issue then try to run the following command and past the output here.
yo --version && echo $PATH $NODE_PATH && node -e 'console.log(process.platform, process.versions)' && cat Gruntfile.js
A commit was made to solve this problem.
https://github.com/yeoman/generator-webapp/pull/67
We'll see an update soon I guess.
in the meantime what you can do is modify your Gruntfile.js. Look near the line 61 for the connect option for livereload and replace the configuration for this snippet.
livereload: {
options: {
middleware: function (connect) {
return [
lrSnippet,
mountFolder(connect, '.tmp'),
mountFolder(connect, yeomanConfig.app)
];
}
}
},
Also, is a good idea to update the module connect-livereload to 0.1.4.
Just run npm install connect-livereload on your project directory.
I added live reload as an option under watch in the Gruntfile.js:
watch: {
options: {
nospawn: true,
livereload: true
},
Setting the livereload:port instead of livereload:options:port worked for me:
livereload: {
port: 35728
}
Related
Having a lot of trouble installing mysql 5.7 on Mac Mojave, (ran 'brew install mysql#5.7')
on initial install, got msg saying postinstall was not completed successfully (please see msg below).
So, after I delete everything in the directory /usr/local/var/mysql (which mysql says is not empty), I STILL get same message when re-running postinstall command ... (which is quite annoying seems MySQL is populating the data dir then complaining it is not empty?!)
[08:02:48][~/tmp]#brew postinstall mysql#5.7
==> Postinstalling mysql#5.7
==> /usr/local/Cellar/mysql#5.7/5.7.28/bin/mysqld --initialize-insecure --user=gert --basedir=/usr/local/Cellar/mysql#5.7/5.7.28 --datadir=/usr/local/var/my Last 15 lines from /Users/gert/Library/Logs/Homebrew/mysql#5.7/post_install.01.mysqld: 2019-12-09 08:03:39 +0200
/usr/local/Cellar/mysql#5.7/5.7.28/bin/mysqld
--initialize-insecure
--user=gert
--basedir=/usr/local/Cellar/mysql#5.7/5.7.28
--datadir=/usr/local/var/mysql
--tmpdir=/tmp
2019-12-09T06:03:39.151987Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use
--explicit_defaults_for_timestamp server option (see documentation for more details). 2019-12-09T06:03:39.154025Z 0
[ERROR] --initialize specified but the data directory has files in it. Aborting. 2019-12-09T06:03:39.154074Z 0 [ERROR] Aborting
Trying to start mysql as root gives error:
[08:04:41][~/tmp]#sudo /usr/local/opt/mysql#5.7/bin/mysql.server start
Password: Starting MySQL ..... ERROR! The server quit without updating
PID file (/var/run/mysqld/mysqld.pid).
Banging head against wall for days now trying to follow StackOverflow posts MySql server startup error 'The server quit without updating PID file ', none of which is working ...
My my.cnf:
[mysqld]
# Only allow connections from localhost
#bind-address = 127.0.0.1
#SO posts said to comment out the above ...
pid-file = /var/run/mysqld/mysqld.pid #Checked, this folder + file exists, with write permissions
Try using a data dir away from the mysql directory i.e if mysql is in /usr/local/mysql, use the data dir as /var/data.
root#photon [ /var ]# /usr/local/mysql/bin/mysqld --initialize-insecure --user=mysql --datadir=/var/data
2020-02-22T21:42:27.121230Z 0 [System] [MY-013169] [Server] /usr/local/mysql/bin/mysqld (mysqld 8.0.19) initializing of server in progress as process 820
2020-02-22T21:42:35.018238Z 5 [Warning] [MY-010453] [Server] root#localhost is created with an empty password ! Please consider switching off the --initialize-insecure option.
So I am trying to run Karma tests for an Angular 6 application on a docker image with Centos 7.5 using a pipeline for GitLab CI.
The problem is
30 08 2018 07:09:55.222:WARN [launcher]: ChromeHeadless have not
captured in 60000 ms, killing.
30 08 2018 07:09:55.244:INFO [launcher]: Trying to start ChromeHeadless again (1/2).
30 08 2018 07:10:55.264:WARN [launcher]: ChromeHeadless have not captured in 60000 ms, killing.
30 08 2018 07:10:55.277:INFO [launcher]: Trying to start ChromeHeadless again (2/2).
30 08 2018 07:11:55.339:WARN [launcher]: ChromeHeadless have not captured in 60000 ms, killing.
30 08 2018 07:11:55.355:ERROR [launcher]: ChromeHeadless failed 2 times (timeout). Giving up.
ERROR: Job failed: exit code 1
I run the tests with ng test --browsers ChromeHeadlessNoSandbox --watch=false --code-coverage
Karma conf :
browsers: ['Chrome', 'ChromeHeadlessNoSandbox'],
customLaunchers: {
ChromeHeadlessNoSandbox: {
base: 'ChromeHeadless',
flags: [
'--no-sandbox',
'--disable-setuid-sandbox',
'--disable-gpu',
'--remote-debugging-port=9222',
],
},
},
Also on the Image the docker file I install the latest chrome stable:
RUN wget https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm
RUN yum -y localinstall google-chrome-stable_current_x86_64.rpm && yum clean all
Do you have any idea about why its giving timeout? In the local environment, it runs perfectly.
I have resolved the same issue. My test suits runs perfectly in my local machine but when running these tests in a docker container, it fails due to connection timeout. (i'm using Gitlab runner also, and My docker image is based on circleci/node:8.9.2-browsers)
After investigating this issue, i found that the chrome bin variable path was missed in the docker file. so i fixed the issue by adding:
export CHROME_BIN=/usr/bin/google-chrome
to my .gitlab-ci.yml in before_script
# TESTING
unit_test_client:
stage: test
before_script:
- export CHROME_BIN=/usr/bin/google-chrome
script:
- npm run test:client
You can also fix your issue by setting the CHROME_BIN by
process.env.CHROME_BIN='/usr/bin/google-chrome' in the top of your karma config file.
In this case, you need to handle the case that you are running the test in your local machine, probably it should match the same chrome path
We had the same issue and resolved it by adding the following flag in the karma.config.js
headlessChrome: {
base: "ChromeHeadless",
flags: [
"--no-sandbox",
"--no-proxy-server",
"--disable-web-security",
"--disable-gpu",
"--js-flags=--max-old-space-size=8196", // THIS LINE FIXED IT!!!
],
You might want to check the console output before Karma attempts to launch the browser. I got stuck for hours on constant timeouts when there were invalid import paths in my Angular application. Karma prints such errors in the console but continues by launching the browsers as if the errors had no importance. This is a bit misleading, but worth checking before blaming the browsers.
Second, machine performance: Every once in a while you might get a timeout at the first launch attempt, but the next attempt will then liekly succeed. Dockerization might decrease your performance, but not much. A headless Chrome should run fast even with minimal setup.
If your browser would not be installed or addressable, then there should be some output regarding that as well.
Hi i solved this issue this way:
In my case the client had a proxy-blocker to manage the networking configurations. So i provided the proxy as server in the customLauncher flag and works perfectly, but only in the pipeline, locally the tests stopped. but it's just take off the proxy that runs locally.
Before: This way the tests runs locally, but do not works in the jenkins pipeline (npm run test)
browsers: ['MyChromeHeadless'],
customLaunchers: {
MyChromeHeadless: {
base: 'ChromeHeadless',
flags: [
'--no-sandbox',
'--proxy-auto-detect'
]
}
}
After: This way the tests runs in the pipeline, but do not works locally cuz i'm not under the client networking with access to the proxy provied, if you are, should work.
browsers: ['MyChromeHeadless'],
customLaunchers: {
MyChromeHeadless: {
base: 'ChromeHeadless',
flags: [
'--no-sandbox',
'--proxy-bypass-list=*',
'--proxy-server=http://proxy.your.company'
]
}
}
Is there a way to use node-inspector to debug unit tests with Jest? It would be nice to step through sometimes to see why tests are failing
I have tried a few ways
node-debug jest --runInBand
from the as well as starting up the inspector first eg
$ node-inspector
$ node --debug-brk .\node_modules\jest-cli --runInBand
and then navigate to http://127.0.0.1:8080/debug?port=5858
I have found that occasionally (1 in 10 or so times), the debugger opens the jest src files and its possible to debug them. Generally though, the scripts in the debugger only contain a 'no domain' folder and another irrelevant folder.
Also the test scripts themselves are never loaded in the debugger.
Has anyone tried this before?
Looks like the issue is that jest is using harmonize, which spawns a child process to ensure that the --harmony option is used.
harmonize/harmonize.js, lines 30-35
var node = child_process.spawn(process.argv[0], ['--harmony'].concat(process.argv.slice(1)), {});
node.stdout.pipe(process.stdout);
node.stderr.pipe(process.stderr);
node.on("close", function(code) {
process.exit(code);
});
I was able to successfully debug jest tests (although tests that use JSX transforms are incredibly slow) by commenting out the code that jest is using to spawn the harmonized process.
node_modules/jest-cli/bin/jest.js, last lines of the file:
if (require.main === module) {
//harmonize(); <--- comment out
_main(function (success) {
process.exit(success ? 0 : 1);
});
}
Then you can run:
$ node-debug --nodejs --harmony ./node_modules/jest-cli/bin/jest.js --runInBand
Jest relies on the --harmony flag being there, so that's why we need to add it back with --nodejs --harmony. We also add --runInBand so that the tests run in sequence, not in parallel.
This opens up the web debugger, and you can debug the tests, although it can be pretty slow to get to the test you want. Please comment if anyone knows a way to make this faster, and I'll update my answer.
You can add this to your package.json to make it easier to kick off:
...
scripts: {
"test": "jest",
"test-debug": "node-debug --nodejs --harmony ./node_modules/jest-cli/bin/jest.js --runInBand"
}
...
Of course, main concern with this solution is the editing of the jest source code. Will think about how to make a pull request to make this stick.
Created Github Issue Here: https://github.com/facebook/jest/issues/152
This is now officially supported with Node >= 6.3.
Quoting Jest documentation:
Place a debugger; statement in any of your tests, and then, in your project's directory, run:
node --debug-brk --inspect ./node_modules/.bin/jest -i [any other arguments here]
This will output a link that you can open in Chrome. After opening that link, the Chrome Developer Tools will be displayed, and a breakpoint will be set at the first line of the Jest CLI script (this is done simply to give you time to open the developer tools and to prevent Jest from executing before you have time to do so). Click the button that looks like a "play" button in the upper right hand side of the screen to continue execution. When Jest executes the test that contains the debugger statement, execution will pause and you can examine the current scope and call stack.
Note: the -i cli option makes sure Jest runs test in the same process rather than spawning processes for individual tests. Normally Jest parallelizes test runs across processes but it is hard to debug many processes at the same time.
More information on the V8 inspector can be found here: https://nodejs.org/api/debugger.html#debugger_v8_inspector_integration_for_node_js
Using Node 7.4.0, Jest 18.x, and the jest-environment-node-debug package (from this comment), it's now possible to use the chrome devtools to debug Jest tests:
$ npm install -D jest-environment-node-debug
$ node --inspect-brk ./node_modules/.bin/jest -i --env jest-environment-node-debug
Here's a Gruntfile.js config to automate #Sean's answer with Grunt.
grunt testd
OR
grunt testd --tests=MyTestName
OR
grunt testd --tests=MyTestName,AnotherTestName
Requires "node-inspector" (must be installed globally to get the node-debug bin in your path), "lodash", "jest-cli" and "grunt-shell" node modules.
var _ = require('lodash');
var commaSplitToRegex = function(input) {
return _.map(input.split(','), function(part) {
return '(' + part + ')';
}).join('|');
};
var getTestRegex = function(tests) {
if (tests) {
return '.*' + commaSplitToRegex(tests) + '.*';
}
return '.*';
}
module.exports = function(grunt) {
grunt.loadNpmTasks('grunt-shell');
grunt.initConfig({
shell: {
jestd: {
command: function() {
var testsRegex = getTestRegex(grunt.option('tests'));
var cmd = 'node-debug --nodejs --harmony ./node_modules/jest-cli/bin/jest.js --runInBand --config="test_utils/jest.json"';
if (testsRegex) {
cmd += ' "' + testsRegex + '"';
}
return cmd;
}
},
monkeypatchjest: {
command: 'sed -i.bak s\\/harmonize\\(\\)\\;\\/\\\\/\\\\/wtf\\/g ./node_modules/jest-cli/bin/jest.js'
},
unmonkeypatchjest: {
command: 'sed -i.bak s\\/\\\\/\\\\/wtf\\/harmonize\\(\\)\\;\\/g ./node_modules/jest-cli/bin/jest.js'
}
}
});
grunt.registerTask('testd', 'Run tests with debugger.', ['shell:monkeypatchjest', 'shell:jestd']);
};
I have an angular project build with yeoman, talking to a rails api backend.
Everything works fine, except that grunt tasks are very slow.
When I run grunt server --verbose:
Execution Time (2014-01-15 13:37:55 UTC)
loading tasks 14.3s ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 26%
server 1ms 0%
preprocess:multifile 11ms 0%
clean:server 13ms 0%
concurrent:server 34.3s ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 63%
autoprefixer 1ms 0%
autoprefixer:dist 369ms ▇ 1%
connect:livereload 17ms 0%
watch 5.8s ▇▇▇▇▇▇▇▇▇ 11%
Total 54.8s
Some of my Gruntfile:
'use strict';
module.exports = function (grunt) {
require('time-grunt')(grunt);
require('load-grunt-tasks')(grunt);
require('time-grunt')(grunt);
grunt.initConfig({
...
});
grunt.loadNpmTasks('grunt-preprocess');
grunt.registerTask('server', function (target) {
if (target === 'dist') {
return grunt.task.run(['build', 'connect:dist:keepalive']);
}
grunt.task.run([
'preprocess:multifile',
'clean:server',
'concurrent:server',
'autoprefixer',
'connect:livereload',
'watch'
]);
});
grunt.registerTask('test', [
'clean:server',
'concurrent:test',
'autoprefixer',
'connect:test'
//'karma'
]);
grunt.registerTask('build', [
'preprocess:multifile',
'clean:dist',
'useminPrepare',
'concurrent:dist',
'autoprefixer',
'concat',
'copy:dist',
'cdnify',
'ngmin',
'cssmin',
'uglify',
'rev',
'usemin'
]);
grunt.registerTask('default', [
'jshint',
'test',
'build'
]);
};
Size of project:
vagrant#vm ~code/myapp/app/scripts
$> find -name "*.js" | xargs cat | wc -l
10209
I am running on MacOS 10.8 with i7 processor, 16GB ram, SSD... It is normal that is takes so long ? What makes the grunt task (and especially "loading tasks") so slow ?
Note: I am ssh'd inside a vagrant machine and running the grunt commands from there. If I run the grunt command on my native system, it's much faster (loading tasks takes 1.6s instead of 14.3).
So the shared filesystem might be an issue. But why...
I had exactly same problem with Vagrant and Yeomans angular-generator. After running grunt serve it took almost 30 seconds to compile sass, restart server etc.
I already used NFS but it was still slow. Then I tried jit-grunt, just-in-time grunt loader. I replaced load-grunt-tasks with jit-grunt and everything is now a lot faster.
Here's a good article about JIT-Grunt:
https://medium.com/written-in-code/ced193c2900b
I am using grunt inside a Vagrant virtualbox. (ubuntu 12.04). My native files are on my host machine (OSx). Because the grunt tasks are io-intensive, and they are run through file sharing, this make them quite slow.
This can be improved by adding nfs to Vagrant (http://docs.vagrantup.com/v2/synced-folders/nfs.html). This will make Vagrant share files with nfs instead of the default Vagrant file sharing. It will be a bit faster, but not much.
For comparison, on my machine:
For running the subtask loading grunt tasks
natively: 1.2s
with nfs: 4s
vagrant file sharing: 16s
If only a specific task is taking a lot of time, this specific task might be the problem. To troubleshoot, use time-grunt: https://npmjs.org/package/time-grunt.
I've had issues as well, and have found:
nospawn: true
To be the fastest option. I went from ~20s to ~1s to concat, minify, and uglify JS.
I had the same problem with Yeoman's ngbp generator and Vagrant. Even with nfs, a simple change on a template took about 30s to be seen in the browser.
Using jit-grunt caused time to be reduced to 10s. After using spawn:false, even though there was no reduction at the first load, changes took less than 1s (0.086s) to propagate to the browser! (Yes!)
The changes I've made to Gruntfile.js:
I commented all the grunt.loadNpmTasks but grunt.loadNpmTasks('grunt-contrib-watch') [That's because of a task rename ngbp does later on];
I added require('jit-grunt')(grunt); after grunt.loadNpmTasks('grunt-contrib-watch');
I added spawn: false to delta: { options: {livereload: true, spawn: false} ...}.
I compiled CouchDB and installed. It seems to work great except when I use views on the database, then it just spins the wheel and nothing happens and the cpu load spikes to 100% and slowly it eats away all memory and starts to swap a lot which in return increases the cpu load.
I have tried both with the js-1.70-12 that comes with centos 6.4, as well as build and install my own js-1.85-1. All erlang packages are installed from epel :
erlang-crypto-R14B-04.2.el6.x86_64
erlang-syntax_tools-R14B-04.2.el6.x86_64
erlang-mnesia-R14B-04.2.el6.x86_64
erlang-ssl-R14B-04.2.el6.x86_64
erlang-cosProperty-R14B-04.2.el6.x86_64
erlang-asn1-R14B-04.2.el6.x86_64
erlang-cosEventDomain-R14B-04.2.el6.x86_64
erlang-eunit-R14B-04.2.el6.x86_64
erlang-erl_docgen-R14B-04.2.el6.x86_64
erlang-toolbar-R14B-04.2.el6.x86_64
erlang-debugger-R14B-04.2.el6.x86_64
erlang-tools-R14B-04.2.el6.x86_64
erlang-typer-R14B-04.2.el6.x86_64
erlang-megaco-R14B-04.2.el6.x86_64
erlang-oauth-1.1.1-1.el6.x86_64
erlang-stdlib-R14B-04.2.el6.x86_64
erlang-hipe-R14B-04.2.el6.x86_64
erlang-kernel-R14B-04.2.el6.x86_64
erlang-runtime_tools-R14B-04.2.el6.x86_64
erlang-snmp-R14B-04.2.el6.x86_64
erlang-public_key-R14B-04.2.el6.x86_64
erlang-inets-R14B-04.2.el6.x86_64
erlang-ibrowse-2.2.0-4.el6.x86_64
erlang-cosEvent-R14B-04.2.el6.x86_64
erlang-cosNotification-R14B-04.2.el6.x86_64
erlang-edoc-R14B-04.2.el6.x86_64
erlang-otp_mibs-R14B-04.2.el6.x86_64
erlang-cosFileTransfer-R14B-04.2.el6.x86_64
erlang-cosTransactions-R14B-04.2.el6.x86_64
erlang-inviso-R14B-04.2.el6.x86_64
erlang-jinterface-R14B-04.2.el6.x86_64
erlang-erl_interface-R14B-04.2.el6.x86_64
erlang-diameter-R14B-04.2.el6.x86_64
erlang-gs-R14B-04.2.el6.x86_64
erlang-tv-R14B-04.2.el6.x86_64
erlang-appmon-R14B-04.2.el6.x86_64
erlang-odbc-R14B-04.2.el6.x86_64
erlang-wx-R14B-04.2.el6.x86_64
erlang-et-R14B-04.2.el6.x86_64
erlang-observer-R14B-04.2.el6.x86_64
erlang-sasl-R14B-04.2.el6.x86_64
erlang-dialyzer-R14B-04.2.el6.x86_64
erlang-common_test-R14B-04.2.el6.x86_64
erlang-os_mon-R14B-04.2.el6.x86_64
erlang-examples-R14B-04.2.el6.x86_64
erlang-compiler-R14B-04.2.el6.x86_64
erlang-erts-R14B-04.2.el6.x86_64
erlang-xmerl-R14B-04.2.el6.x86_64
erlang-orber-R14B-04.2.el6.x86_64
erlang-cosTime-R14B-04.2.el6.x86_64
erlang-ssh-R14B-04.2.el6.x86_64
erlang-docbuilder-R14B-04.2.el6.x86_64
erlang-percept-R14B-04.2.el6.x86_64
erlang-parsetools-R14B-04.2.el6.x86_64
erlang-ic-R14B-04.2.el6.x86_64
erlang-pman-R14B-04.2.el6.x86_64
erlang-webtool-R14B-04.2.el6.x86_64
erlang-test_server-R14B-04.2.el6.x86_64
erlang-reltool-R14B-04.2.el6.x86_64
erlang-R14B-04.2.el6.x86_64
erlang-mochiweb-1.4.1-5.el6.x86_64
Every thing configures and makes and installs as expected. You can dump data into the database, you can create documents and all that. But I can not run any view, temporary or not.
The only error I see in the logs is like this one, and it is a lot of these errors :
[Sun, 18 Aug 2013 23:10:38 GMT] [error] [<0.124.0>] {error_report,<0.30.0>,
{<0.124.0>,crash_report,
[[{initial_call,
{mochiweb_socket_server,init,['Argument__1']}},
{pid,<0.124.0>},
{registered_name,[]},
{error_info,
{exit,eaddrinuse,
[{gen_server,init_it,6},
{proc_lib,init_p_do_apply,3}]}},
{ancestors,
[couch_secondary_services,couch_server_sup,
<0.31.0>]},
{messages,[]},
{links,[<0.93.0>]},
{dictionary,[]},
{trap_exit,true},
{status,running},
{heap_size,987},
{stack_size,24},
{reductions,459}],
[]]}}
But I have no idea what they mean.
Do I need to compile and install erlang as well ? All the above packages or just erlang ?
Your compilation and installation looks fine. At least your error (note: eaddrinuse in traceback) is about that there is some process that listens same address and port as your CouchDB try to. Check other listening processes with netstat -anp command or change CouchDB's listen port to different.