CentOS build issues (may deal with proxies)

Hey Calamari folks,
I've tried to work this out on my own, but I'm kinda at the end of my rope here. To start off, I've considered swapping over to the Vagrant build configuration, but I'm intending to actively develop on Calamari for a number of months and would prefer to work within a standard CentOS environment.
I'm using Centos7, and your step by step guide for Fedora 20 was quite helpful:
yum install nodejs npm ruby make git
npm install -g grunt-cli
download and install rubygems
gem install compass
checkout the code git clone git@github.com:ceph/calamari-clients.git
cd into calamari-clients folder
to build: make build-real
Problems didn't really crop up until I actually tried to build. I'm building behind HP's corporate firewall, so I need to deal with a proxy. Here are the places that I've defined a proxy:

The bash environment variables (http_proxy, https_proxy, HTTP_PROXY, HTTPS_PROXY)

I made them part of the base bash environment variables in /etc/bashrc

The git global proxies

both git config --global http.proxy and https.proxy
a bonus config point via git config --global url."https://".insteadOf git://

Each individual .bowerrc file

proxy and https-proxy

npm proxies

proxy, http-proxy, and https-proxy

I had been running make build-real, but the build consistently failed. I'll post images a bit farther down. So, I took a look at the makefile to double-check that running sudo make build in each individual directory would be effectively the same as running sudo make build-real at the base directory (calamari-clients). So, I went and built dashboard, admin, and login. All three seem to have worked correctly (there's a dist directory in each of those three directories). The manage directory is the area where I'm consistently having problems. The compass.dist task runs, but then things fall off the wagon a bit:

The "pre-build test failed, compiling from source..." lines take a few minutes to come out, and then another five minutes or so to get the ETIMEDOUT lines, which still seem to indicate some sort of success. We sit and wait at the screen above for a solid ten minutes. In that time, the system becomes semi-unresponsive. Before we get to that point, I ran a 'ps aux | grep node'. I didn't count the processes, but there are quite a few running simultaneously. The mouse cursor moves, but nothing else works (second terminals don't respond to text input or mouse clicks, for instance). Then, I get this:

Any idea what to make of this? I took a look at the Gruntfile.js in the manage directory and saw that the concurrent:dist task deals with compass (unless I'm totally misinterpreting the Gruntfile). My thought is that this all stems from the ETIMEDOUT messages, but I don't know enough about calamari's build process to know for sure. I tracked down a stackoverflow post that seemed to have potential, but either I can't figure out the right way to define the HP proxy in the proxies: json entry or that's not my problem spot. http://stackoverflow.com/questions/24821833/how-do-i-configure-grunt-connect-proxy-behind-a-firewall
Sorry for the long post. Any help or pointers in the right direction would be greatly appreciated. Also, at some point I'd like to add to at least the .bowerrc files to help out anyone who might deal with proxies in the future like me...having a couple of commented out lines for proxies along with some documentation on what proxies need to be set would've saved me a few trips to the Google search bar.
Joe

@joehandzik can you provide the full build output instead of screenshot?
Also in the calamar-clients directory, Edit the Makefile and modify UI_SUBDIRS = manage. Then run make clean-real && make build-real and provide the output.
Debug mode can be enabled by modifying Makefile.sub and changing grunt --no-color build to grunt --no-color --debug build

Hey @kmkanagaraj, I have the build output but I'd argue it's less useful than the screenshots I sent over, since the machine gets in such a nasty state that it stops updating the file I'm piping the logs out to. If you have a better idea for how to capture more data, I'm all ears.
I enabled the debug flag, the verbose flag, and went and ran 'npm config set strict-ssl false' for good measure. I also manually used npm install to install the gifsicle, jpegtran, optipng, and phantomjs components based on references to the first three being near the theoretical problem area and on grepping through the manage directory for "Error: connect ETIMEDOUT" and seeing references to phantomjs's README. None of it seems to have changed behavior at all. And yes, I am running the 'make clean-real' command before attempting to build.
Debug output from 'make build-real' is as follows:
building ui
set -e ;
for d in manage; do
echo $d; cd $d; make build; cd .. ;
done
manage
make[1]: Entering directory `/home/jhandz/calamari-clients/manage'
npm install --loglevel warn
npm WARN package.json<EMAIL_ADDRESS>No repository field.

<EMAIL_ADDRESS>postinstall /home/jhandz/calamari-clients/manage/node_modules/gifsicle
node lib/install.js

✔ gifsicle pre-build test passed successfully

<EMAIL_ADDRESS>install /home/jhandz/calamari-clients/manage/node_modules/phantomjs
node install.js

Download already available at /home/jhandz/calamari-clients/manage/node_modules/phantomjs/phantomjs/phantomjs-1.9.8-linux-x86_64.tar.bz2
Extracting tar contents (via spawned process)
Removing /home/jhandz/calamari-clients/manage/node_modules/phantomjs/lib/phantom
Copying extracted folder /home/jhandz/calamari-clients/manage/node_modules/phantomjs/phantomjs/phantomjs-1.9.8-linux-x86_64.tar.bz2-extract-1421965720551/phantomjs-1.9.8-linux-x86_64 -> /home/jhandz/calamari-clients/manage/node_modules/phantomjs/lib/phantom
Removing /home/jhandz/calamari-clients/manage/node_modules/phantomjs/phantomjs/phantomjs-1.9.8-linux-x86_64.tar.bz2-extract-1421965720551
Writing location.js file
Done. Phantomjs binary available at /home/jhandz/calamari-clients/manage/node_modules/phantomjs/lib/phantom/bin/phantomjs
bower --allow-root --config.interactive=false install
grunt --no-color saveRevision
Running "saveRevision" task
Running "git-describe:git.js" (git-describe) task
Git Revision: v<IP_ADDRESS>-55-cfbc8bf-dirty

v<IP_ADDRESS>-55-cfbc8bf-dirty

Done, without errors.
Execution Time (2015-01-22 22:28:52 UTC)
git-describe:git.js  1.8s  ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 100%
Total 1.8s
grunt --no-color --debug --verbose build
Initializing
Command-line options: --no-color, --debug=1, --verbose
Reading "Gruntfile.js" Gruntfile...OK
Registering Gruntfile tasks.
Registering "grunt-autoprefixer" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-autoprefixer/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-autoprefixer/package.json...OK
Loading "autoprefixer.js" tasks...OK

autoprefixer

Registering "grunt-bower-requirejs" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-bower-requirejs/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-bower-requirejs/package.json...OK
Loading "bower-requirejs.js" tasks...OK

bower

Registering "grunt-concurrent" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-concurrent/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-concurrent/package.json...OK
Loading "concurrent.js" tasks...OK

concurrent

Registering "grunt-connect-proxy" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-connect-proxy/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-connect-proxy/package.json...OK
Loading "connect_proxy.js" tasks...OK

configureProxies

Registering "grunt-contrib-clean" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-clean/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-clean/package.json...OK
Loading "clean.js" tasks...OK

clean

Registering "grunt-contrib-coffee" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-coffee/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-coffee/package.json...OK
Loading "coffee.js" tasks...OK

coffee

Registering "grunt-contrib-compass" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-compass/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-compass/package.json...OK
Loading "compass.js" tasks...OK

compass

Registering "grunt-contrib-concat" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-concat/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-concat/package.json...OK
Loading "concat.js" tasks...OK

concat

Registering "grunt-contrib-connect" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-connect/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-connect/package.json...OK
Loading "connect.js" tasks...OK

connect

Registering "grunt-contrib-copy" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-copy/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-copy/package.json...OK
Loading "copy.js" tasks...OK

copy

Registering "grunt-contrib-cssmin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-cssmin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-cssmin/package.json...OK
Loading "cssmin.js" tasks...OK

cssmin

Registering "grunt-contrib-htmlmin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-htmlmin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-htmlmin/package.json...OK
Loading "htmlmin.js" tasks...OK

htmlmin

Registering "grunt-contrib-imagemin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-imagemin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-imagemin/package.json...OK
Loading "imagemin.js" tasks...OK

imagemin

Registering "grunt-contrib-jshint" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-jshint/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-jshint/package.json...OK
Loading "jshint.js" tasks...OK

jshint

Registering "grunt-contrib-symlink" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-symlink/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-symlink/package.json...OK
Loading "symlink.js" tasks...OK

symlink

Registering "grunt-contrib-uglify" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-uglify/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-uglify/package.json...OK
Loading "uglify.js" tasks...OK

uglify

Registering "grunt-contrib-watch" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-watch/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-watch/package.json...OK
Loading "watch.js" tasks...OK

watch

Registering "grunt-docco" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-docco/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-docco/package.json...OK
Loading "docco.js" tasks...OK

docco

Registering "grunt-git-describe" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-git-describe/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-git-describe/package.json...OK
Loading "git-describe.js" tasks...OK

git-describe

Registering "grunt-google-cdn" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-google-cdn/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-google-cdn/package.json...OK
Loading "cdnify.js" tasks...OK

cdnify

Registering "grunt-karma" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-karma/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-karma/package.json...OK
Loading "grunt-karma.js" tasks...OK

karma

Registering "grunt-newer" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-newer/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-newer/package.json...OK
Loading "newer.js" tasks...OK

any-newer, newer, newer-reconfigure, newer-timestamp

Registering "grunt-ngmin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-ngmin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-ngmin/package.json...OK
Loading "ngmin.js" tasks...OK

ngmin

Registering "grunt-requirejs" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-requirejs/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-requirejs/package.json...OK
Loading "require.js" tasks...OK

requirejs

Registering "grunt-rev" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-rev/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-rev/package.json...OK
Loading "rev.js" tasks...OK

rev

Registering "grunt-svgmin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-svgmin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-svgmin/package.json...OK
Loading "svgmin.js" tasks...OK

svgmin

Registering "grunt-usemin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-usemin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-usemin/package.json...OK
Loading "usemin.js" tasks...OK

usemin, useminPrepare
Initializing config...OK
Loading "Gruntfile.js" tasks...OK
build, default, docs, saveRevision, serve, server, test

Running tasks: build
Running "build" task
[D] Task source: /home/jhandz/calamari-clients/manage/Gruntfile.js
Running "clean:dist" (clean) task
[D] Task source: /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-clean/tasks/clean.js
Verifying property clean.dist exists in config...OK
Files: [no src]
Options: force=false, no-write=false
Options: force=false, no-write=false
Running "symlink" task
[D] Task source: /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-symlink/tasks/symlink.js
Running "symlink:fonts" (symlink) task
[D] Task source: /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-symlink/tasks/symlink.js
Verifying property symlink.fonts exists in config...OK
Files: app/bower_components/font-awesome/fonts -> app/fonts
Options: overwrite
Deleting app/fonts...OK
Linking (dir) app/fonts -> bower_components/font-awesome/fonts...OK

Created 1 symbolic links.

Running "saveRevision" task
[D] Task source: /home/jhandz/calamari-clients/manage/Gruntfile.js
Running "git-describe" task
[D] Task source: /home/jhandz/calamari-clients/manage/node_modules/grunt-git-describe/tasks/git-describe.js
Running "git-describe:git.js" (git-describe) task
[D] Task source: /home/jhandz/calamari-clients/manage/node_modules/grunt-git-describe/tasks/git-describe.js
Verifying property git-describe.git.js exists in config...OK
File: [no files]
Options: cwd=".", template="{%=tag%}-{%=since%}-{%=object%}{%=dirty%}", failOnError=false
Flags: commitish=undefined, cwd=".", template="{%=tag%}-{%=since%}-{%=object%}{%=dirty%}", failOnError=false
Spawning
Flags: cmd="git", args=["describe","--tags","--always","--long","--dirty"], opts={"cwd":"."}
Git Revision: v<IP_ADDRESS>-55-cfbc8bf-dirty
Writing app/scripts/git.js...OK

v<IP_ADDRESS>-55-cfbc8bf-dirty

Running "useminPrepare" task
[D] Task source: /home/jhandz/calamari-clients/manage/node_modules/grunt-usemin/tasks/usemin.js
Running "useminPrepare:html" (useminPrepare) task
[D] Task source: /home/jhandz/calamari-clients/manage/node_modules/grunt-usemin/tasks/usemin.js
Verifying property useminPrepare.html exists in config...OK
Files: app/index.html -> html
Options: dest="dist"
Going through app/index.html to update the config
Looking for build script HTML comment blocks
Configuration is now:
concat:
{ generated:
{ files:
[ { dest: '.tmp/concat/styles/vendor.css',
src: [ 'app/bower_components/bootstrap/dist/css/bootstrap.css' ] },
{ dest: '.tmp/concat/styles/main.css',
src: [ '{.tmp,app}/styles/main.css' ] } ] } }
uglify:
{ dist:
{ options: { mangle: false, beautify: true },
files: { '<%= yeoman.dist %>/scripts/main.js': [ '.tmp/concat/scripts/main.js' ] } } }
cssmin:
{ generated:
{ files:
[ { dest: 'dist/styles/vendor.css',
src: [ '.tmp/concat/styles/vendor.css' ] },
{ dest: 'dist/styles/main.css',
src: [ '.tmp/concat/styles/main.css' ] } ] } }
Running "concurrent:dist" (concurrent) task
[D] Task source: /home/jhandz/calamari-clients/manage/node_modules/grunt-concurrent/tasks/concurrent.js
Verifying property concurrent.dist exists in config...OK
Files: [no src] -> dist
Options: limit=16
Initializing
Command-line options: --no-color, --debug=1, --verbose

Reading "Gruntfile.js" Gruntfile...OK

Registering Gruntfile tasks.

Registering "grunt-autoprefixer" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-autoprefixer/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-autoprefixer/package.json...OK
Loading "autoprefixer.js" tasks...OK
+ autoprefixer

Registering "grunt-bower-requirejs" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-bower-requirejs/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-bower-requirejs/package.json...OK
Loading "bower-requirejs.js" tasks...OK
+ bower

Registering "grunt-concurrent" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-concurrent/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-concurrent/package.json...OK
Loading "concurrent.js" tasks...OK
+ concurrent

Registering "grunt-connect-proxy" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-connect-proxy/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-connect-proxy/package.json...OK
Loading "connect_proxy.js" tasks...OK
+ configureProxies

Registering "grunt-contrib-clean" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-clean/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-clean/package.json...OK
Loading "clean.js" tasks...OK
+ clean

Registering "grunt-contrib-coffee" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-coffee/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-coffee/package.json...OK
Loading "coffee.js" tasks...OK
+ coffee

Registering "grunt-contrib-compass" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-compass/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-compass/package.json...OK
Loading "compass.js" tasks...OK
+ compass

Registering "grunt-contrib-concat" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-concat/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-concat/package.json...OK
Loading "concat.js" tasks...OK
+ concat

Registering "grunt-contrib-connect" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-connect/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-connect/package.json...OK
Loading "connect.js" tasks...OK
+ connect

Registering "grunt-contrib-copy" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-copy/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-copy/package.json...OK
Loading "copy.js" tasks...OK
+ copy

Registering "grunt-contrib-cssmin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-cssmin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-cssmin/package.json...OK
Loading "cssmin.js" tasks...OK
+ cssmin

Registering "grunt-contrib-htmlmin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-htmlmin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-htmlmin/package.json...OK
Loading "htmlmin.js" tasks...OK
+ htmlmin

Registering "grunt-contrib-imagemin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-imagemin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-imagemin/package.json...OK
Loading "imagemin.js" tasks...OK
+ imagemin

Registering "grunt-contrib-jshint" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-jshint/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-jshint/package.json...OK
Loading "jshint.js" tasks...OK
+ jshint

Registering "grunt-contrib-symlink" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-symlink/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-symlink/package.json...OK
Loading "symlink.js" tasks...OK
+ symlink

Registering "grunt-contrib-uglify" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-uglify/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-uglify/package.json...OK
Loading "uglify.js" tasks...OK
+ uglify

Registering "grunt-contrib-watch" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-watch/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-watch/package.json...OK
Loading "watch.js" tasks...OK
+ watch

Registering "grunt-docco" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-docco/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-docco/package.json...OK
Loading "docco.js" tasks...OK
+ docco

Registering "grunt-git-describe" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-git-describe/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-git-describe/package.json...OK
Loading "git-describe.js" tasks...OK
+ git-describe

Registering "grunt-google-cdn" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-google-cdn/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-google-cdn/package.json...OK
Loading "cdnify.js" tasks...OK
+ cdnify

Registering "grunt-karma" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-karma/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-karma/package.json...OK
Loading "grunt-karma.js" tasks...OK
+ karma

Registering "grunt-newer" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-newer/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-newer/package.json...OK
Loading "newer.js" tasks...OK
+ any-newer, newer, newer-reconfigure, newer-timestamp

Registering "grunt-ngmin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-ngmin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-ngmin/package.json...OK
Loading "ngmin.js" tasks...OK
+ ngmin

Registering "grunt-requirejs" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-requirejs/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-requirejs/package.json...OK
Loading "require.js" tasks...OK
+ requirejs

Registering "grunt-rev" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-rev/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-rev/package.json...OK
Loading "rev.js" tasks...OK
+ rev

Registering "grunt-svgmin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-svgmin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-svgmin/package.json...OK
Loading "svgmin.js" tasks...OK
+ svgmin

Registering "grunt-usemin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-usemin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-usemin/package.json...OK
Loading "usemin.js" tasks...OK
+ usemin, useminPrepare
Initializing config...OK
Loading "Gruntfile.js" tasks...OK
+ build, default, docs, saveRevision, serve, server, test

Running tasks: copy:styles

Running "copy:styles" (copy) task
[D] Task source: /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-copy/tasks/copy.js
Verifying property copy.styles exists in config...OK
Options: processContent=false, processContentExclude=[]
Options: processContent=false, processContentExclude=[]

Done, without errors.

Initializing
Command-line options: --no-color, --debug=1, --verbose

Reading "Gruntfile.js" Gruntfile...OK

Registering Gruntfile tasks.

Registering "grunt-autoprefixer" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-autoprefixer/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-autoprefixer/package.json...OK
Loading "autoprefixer.js" tasks...OK
+ autoprefixer

Registering "grunt-bower-requirejs" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-bower-requirejs/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-bower-requirejs/package.json...OK
Loading "bower-requirejs.js" tasks...OK
+ bower

Registering "grunt-concurrent" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-concurrent/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-concurrent/package.json...OK
Loading "concurrent.js" tasks...OK
+ concurrent

Registering "grunt-connect-proxy" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-connect-proxy/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-connect-proxy/package.json...OK
Loading "connect_proxy.js" tasks...OK
+ configureProxies

Registering "grunt-contrib-clean" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-clean/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-clean/package.json...OK
Loading "clean.js" tasks...OK
+ clean

Registering "grunt-contrib-coffee" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-coffee/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-coffee/package.json...OK
Loading "coffee.js" tasks...OK
+ coffee

Registering "grunt-contrib-compass" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-compass/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-compass/package.json...OK
Loading "compass.js" tasks...OK
+ compass

Registering "grunt-contrib-concat" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-concat/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-concat/package.json...OK
Loading "concat.js" tasks...OK
+ concat

Registering "grunt-contrib-connect" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-connect/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-connect/package.json...OK
Loading "connect.js" tasks...OK
+ connect

Registering "grunt-contrib-copy" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-copy/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-copy/package.json...OK
Loading "copy.js" tasks...OK
+ copy

Registering "grunt-contrib-cssmin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-cssmin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-cssmin/package.json...OK
Loading "cssmin.js" tasks...OK
+ cssmin

Registering "grunt-contrib-htmlmin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-htmlmin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-htmlmin/package.json...OK
Loading "htmlmin.js" tasks...OK
+ htmlmin

Registering "grunt-contrib-imagemin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-imagemin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-imagemin/package.json...OK
Loading "imagemin.js" tasks...OK
+ imagemin

Registering "grunt-contrib-jshint" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-jshint/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-jshint/package.json...OK
Loading "jshint.js" tasks...OK
+ jshint

Registering "grunt-contrib-symlink" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-symlink/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-symlink/package.json...OK
Loading "symlink.js" tasks...OK
+ symlink

Registering "grunt-contrib-uglify" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-uglify/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-uglify/package.json...OK
Loading "uglify.js" tasks...OK
+ uglify

Registering "grunt-contrib-watch" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-watch/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-watch/package.json...OK
Loading "watch.js" tasks...OK
+ watch

Registering "grunt-docco" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-docco/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-docco/package.json...OK
Loading "docco.js" tasks...OK
+ docco

Registering "grunt-git-describe" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-git-describe/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-git-describe/package.json...OK
Loading "git-describe.js" tasks...OK
+ git-describe

Registering "grunt-google-cdn" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-google-cdn/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-google-cdn/package.json...OK
Loading "cdnify.js" tasks...OK
+ cdnify

Registering "grunt-karma" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-karma/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-karma/package.json...OK
Loading "grunt-karma.js" tasks...OK
+ karma

Registering "grunt-newer" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-newer/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-newer/package.json...OK
Loading "newer.js" tasks...OK
+ any-newer, newer, newer-reconfigure, newer-timestamp

Registering "grunt-ngmin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-ngmin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-ngmin/package.json...OK
Loading "ngmin.js" tasks...OK
+ ngmin

Registering "grunt-requirejs" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-requirejs/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-requirejs/package.json...OK
Loading "require.js" tasks...OK
+ requirejs

Registering "grunt-rev" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-rev/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-rev/package.json...OK
Loading "rev.js" tasks...OK
+ rev

Registering "grunt-svgmin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-svgmin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-svgmin/package.json...OK
Loading "svgmin.js" tasks...OK
+ svgmin

Registering "grunt-usemin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-usemin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-usemin/package.json...OK
Loading "usemin.js" tasks...OK
+ usemin, useminPrepare
Initializing config...OK
Loading "Gruntfile.js" tasks...OK
+ build, default, docs, saveRevision, serve, server, test

Running tasks: svgmin

Running "svgmin" task
[D] Task source: /home/jhandz/calamari-clients/manage/node_modules/grunt-svgmin/tasks/svgmin.js

Running "svgmin:dist" (svgmin) task
[D] Task source: /home/jhandz/calamari-clients/manage/node_modules/grunt-svgmin/tasks/svgmin.js
Verifying property svgmin.dist exists in config...OK
Options: (none)

Done, without errors.

Initializing
Command-line options: --no-color, --debug=1, --verbose

Reading "Gruntfile.js" Gruntfile...OK

Registering Gruntfile tasks.

Registering "grunt-autoprefixer" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-autoprefixer/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-autoprefixer/package.json...OK
Loading "autoprefixer.js" tasks...OK
+ autoprefixer

Registering "grunt-bower-requirejs" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-bower-requirejs/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-bower-requirejs/package.json...OK
Loading "bower-requirejs.js" tasks...OK
+ bower

Registering "grunt-concurrent" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-concurrent/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-concurrent/package.json...OK
Loading "concurrent.js" tasks...OK
+ concurrent

Registering "grunt-connect-proxy" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-connect-proxy/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-connect-proxy/package.json...OK
Loading "connect_proxy.js" tasks...OK
+ configureProxies

Registering "grunt-contrib-clean" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-clean/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-clean/package.json...OK
Loading "clean.js" tasks...OK
+ clean

Registering "grunt-contrib-coffee" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-coffee/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-coffee/package.json...OK
Loading "coffee.js" tasks...OK
+ coffee

Registering "grunt-contrib-compass" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-compass/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-compass/package.json...OK
Loading "compass.js" tasks...OK
+ compass

Registering "grunt-contrib-concat" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-concat/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-concat/package.json...OK
Loading "concat.js" tasks...OK
+ concat

Registering "grunt-contrib-connect" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-connect/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-connect/package.json...OK
Loading "connect.js" tasks...OK
+ connect

Registering "grunt-contrib-copy" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-copy/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-copy/package.json...OK
Loading "copy.js" tasks...OK
+ copy

Registering "grunt-contrib-cssmin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-cssmin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-cssmin/package.json...OK
Loading "cssmin.js" tasks...OK
+ cssmin

Registering "grunt-contrib-htmlmin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-htmlmin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-htmlmin/package.json...OK
Loading "htmlmin.js" tasks...OK
+ htmlmin

Registering "grunt-contrib-imagemin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-imagemin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-imagemin/package.json...OK
Loading "imagemin.js" tasks...OK
+ imagemin

Registering "grunt-contrib-jshint" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-jshint/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-jshint/package.json...OK
Loading "jshint.js" tasks...OK
+ jshint

Registering "grunt-contrib-symlink" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-symlink/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-symlink/package.json...OK
Loading "symlink.js" tasks...OK
+ symlink

Registering "grunt-contrib-uglify" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-uglify/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-uglify/package.json...OK
Loading "uglify.js" tasks...OK
+ uglify

Registering "grunt-contrib-watch" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-watch/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-watch/package.json...OK
Loading "watch.js" tasks...OK
+ watch

Registering "grunt-docco" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-docco/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-docco/package.json...OK
Loading "docco.js" tasks...OK
+ docco

Registering "grunt-git-describe" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-git-describe/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-git-describe/package.json...OK
Loading "git-describe.js" tasks...OK
+ git-describe

Registering "grunt-google-cdn" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-google-cdn/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-google-cdn/package.json...OK
Loading "cdnify.js" tasks...OK
+ cdnify

Registering "grunt-karma" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-karma/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-karma/package.json...OK
Loading "grunt-karma.js" tasks...OK
+ karma

Registering "grunt-newer" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-newer/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-newer/package.json...OK
Loading "newer.js" tasks...OK
+ any-newer, newer, newer-reconfigure, newer-timestamp

Registering "grunt-ngmin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-ngmin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-ngmin/package.json...OK
Loading "ngmin.js" tasks...OK
+ ngmin

Registering "grunt-requirejs" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-requirejs/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-requirejs/package.json...OK
Loading "require.js" tasks...OK
+ requirejs

Registering "grunt-rev" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-rev/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-rev/package.json...OK
Loading "rev.js" tasks...OK
+ rev

Registering "grunt-svgmin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-svgmin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-svgmin/package.json...OK
Loading "svgmin.js" tasks...OK
+ svgmin

Registering "grunt-usemin" local Npm module tasks.
Reading /home/jhandz/calamari-clients/manage/node_modules/grunt-usemin/package.json...OK
Parsing /home/jhandz/calamari-clients/manage/node_modules/grunt-usemin/package.json...OK
Loading "usemin.js" tasks...OK
+ usemin, useminPrepare
Initializing config...OK
Loading "Gruntfile.js" tasks...OK
+ build, default, docs, saveRevision, serve, server, test

Running tasks: compass:dist

Running "compass:dist" (compass) task
[D] Task source: /home/jhandz/calamari-clients/manage/node_modules/grunt-contrib-compass/tasks/compass.js
Verifying property compass.dist exists in config...OK
File: [no files]
Options: sassDir="app/styles", cssDir=".tmp/styles", generatedImagesDir="dist/images/generated", imagesDir="app/images", javascriptsDir="app/scripts", fontsDir="app/styles/fonts", importPath="app/bower_components", httpImagesPath="/images", httpGeneratedImagesPath="/images/generated", httpFontsPath="/styles/fonts", relativeAssets=false, assetCacheBuster=false
Options: sassDir="app/styles", cssDir=".tmp/styles", imagesDir="app/images", javascriptsDir="app/scripts", fontsDir="app/styles/fonts", importPath="app/bower_components", relativeAssets=false, time
directory .tmp/styles
    write .tmp/styles/main.css (1.41s)

Done, without errors.
    ⚠ pre-build test failed, compiling from source...
    ⚠ pre-build test failed, compiling from source...
    ⚠ pre-build test failed, compiling from source...
    ✖ { [Error: connect ETIMEDOUT] code: 'ETIMEDOUT', errno: 'ETIMEDOUT', syscall: 'connect' }
    ✔ optipng built successfully!
    ✖ { [Error: connect ETIMEDOUT] code: 'ETIMEDOUT', errno: 'ETIMEDOUT', syscall: 'connect' }
    ✔ jpegtran built successfully!
    ✖ { [Error: connect ETIMEDOUT] code: 'ETIMEDOUT', errno: 'ETIMEDOUT', syscall: 'connect' }
    ✔ gifsicle built successfully!

It seems like some of the build is parallel, which may be making the debug process harder. Is there a smart way to serialize the build completely (regardless of completion time as long as it's no longer than an hour)?

The issue is occurring only in the manage app. You can follow these steps to narrow down.

Edit Makefile and change UI_SUBDIRS = manage admin login dashboard  to UI_SUBDIRS = manage . By doing this, you will be building only the manage app

To disable concurrent build, Edit manage/Gruntfile.js and change following block

    // Run some tasks in parallel to speed up the build process
    concurrent: {
      options: {
        limit: 1,
        logConcurrentOutput: true
      },
      server: [
        'compass:server',
        'copy:styles'
      ],
      test: [
        'compass',
        'copy:styles'
      ],
      dist: [
        'compass:dist',
        'copy:styles',
        'imagemin',
        'svgmin'
      ]
    },

Btw, it did not take too much time to compile for me.


Support for .doc extensions

Are you planning to offer .doc support in addition to the current .docx support?

created PR https://github.com/microsoft/markitdown/pull/36

Patiently waiting for good news.


Project: LMS Integration - GSoC'21 Ayan Biswas

TBD

Coverage decreased (-2.3%) to 82.465% when pulling 4ccecf124b92c13f8c24b24150dbf97866fb85dc on lms-lti into 1e0321ca4d3a69966b71a315dc7efb274c81b9eb on master.


Moving the foldamers.py stub file that was messing things up.

Description
Remove that stub foldamers.py file from the cookie cutter that was messing up imports. That's it.

Codecov Report

Merging #40 into master will increase coverage by 0.02%.
The diff coverage is n/a.


Support modified funding payment calc

Blocked by: https://github.com/vegaprotocol/vega/issues/10656
The Chore
This is changing
Tasks

[ ] Will have a new market param (presumably in "Funding" section) which needs to be supported and get some tooltips

[ ] scaling_factor: optional scaling factor applied to funding payment.
[ ] rate_lower_bound: optional lower bound applied to funding payment such that the resulting funding rate will never be lower than the specified value.
[ ] rate_upper_bound: optional upper bound applied to funding payment such that the resulting funding rate will never be greater than than the specified value.

Additional details / background info
Thread https://vegaprotocol.slack.com/archives/CLFN5CUMT/p1704214242174609

@JonRay15 @barnabee Is there anything else to consider here with regard to where we display these values? For example on the funding payments chart? Or is it only required in the market info tab

Hold this off until we're confident Core have pusged the above fix to testnet


Update values.yaml

Update of the description of the operator

Closing in favor of https://github.com/kube-reporting/metering-operator/pull/1303


Fix: Loader doesn't filter asset list recursively

Changelog Description
Since OP 3.15.0 Loader doesn't filter asset list recursively
Testing notes:

Open Loader
Try to filter by typing words

I found out it's broken on other places too. Would it be ok if I would create new PR?

I found out it's broken on other places too. Would it be ok if I would create new PR?

@iLLiCiTiT, sure, the goal is for it to work, no matter who does it :)

Made PR fixing also other places https://github.com/ynput/OpenPype/pull/4597 @Tilix4 thanks for spotting and reporting the issue.


Filter Selector Dynamic Updates

Which package?
None
What's the problem this feature will solve?
Following this documentation link - I'd like to request the ability to have filter dropdown/selector values update dynamically while the filter is running.
As a hypothetical example - if I have a revenue dashboard displaying performance across a few companies, I may have dashboard with filters for Company Name (with values [Company 1, Company 2, etc]) and Business Unit Name. Currently, if I were to filter to a specific Company, The BU names list shown for the second filter would should all BU names in the dataset. Ideally, it'd update to only filter amongst the BU names in the filtered dataset.
In cases where the option cardinality is small , the current state doesn't pose much of a headache. This becomes a worse experience in higher-cardinality settings.
Describe the solution you'd like
I really like the current way of specifying filters and even options. Maybe as one potential argument options in a selector, if specifying a string you can then 'link' filters as needed?
Alternative Solutions
Have not explored many alternative options with more vanilla dash.
Additional context
https://vizro.readthedocs.io/en/stable/pages/user-guides/data/?h=filter#filter-update-limitation
Code of Conduct

[X] I agree to follow the  Code of Conduct.

Hello @mkretsch327 ! First of all, it's so great to see you here 😃
You are right, current default filter couldn't handle the higher-cardinality settings well. This is a feature we'd love to offer natively via Vizro Filter soon, so thanks for raising your interest in this feature. It highlights the importance of addressing this feature request.
Before we have the feature released, now you can achieve similar behavior by directly leveraging Dash. See what @petar-qb suggested in this issue: https://github.com/mckinsey/vizro/issues/180#issuecomment-1830318509
Let us know whether it works in your use case.

Thanks Lingyi! Great that our paths cross once more :) . The solution in that linked PR (180) worked great for what I needed.


Orphan processes from tests

Environment data

VS Code version: 1.24.0
Extension version (available under the Extensions sidebar): 2018.5.0
OS and version: macOS 10.12.6
Python version (& distribution if applicable, e.g. Anaconda): 3.6.5
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): pipenv
Relevant/affected Python packages and their versions: multiprocessing

Actual behavior
When using multiprocessing to spawn processes in unittests, if those processes are not killed in code, the processes remain alive even when the tests are stopped in vscode.
Expected  behavior
I would expect the processes to be killed when I stop the tests in vscode, just like how they would be killed if I ran the test in the terminal and killed the test with Ctrl-C
Steps to reproduce:

Write a unit test file that spawns processes with no logic to kill them
Run the test from vscode
Stop the test from vscode
Check Activity Monitor to see spawned processes still alive.

Logs
Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)
The logs only have pylint output. It's not related to the bug and I don't want to share my logs here.
Output from Console under the Developer Tools panel (toggle Developer Tools on under Help)
notificationsAlerts.ts:40 Error: Cannot read property 'parentTestFile' of undefined
	at options.testsToRun.testFunction.forEach.testFn (/Users/wesley/.vscode/extensions/ms-python.python-2018.5.0/out/client/unittests/unittest/runner.js:125:106)
	at Array.forEach (native)
	at server.start.then.port (/Users/wesley/.vscode/extensions/ms-python.python-2018.5.0/out/client/unittests/unittest/runner.js:124:49)
	at <anonymous>
	at process._tickCallback (internal/process/next_tick.js:109:7)
e.onDidNotificationChange @ notificationsAlerts.ts:40
notificationsAlerts.ts:40 Error: Cannot read property 'parentTestFile' of undefined
	at options.testsToRun.testFunction.forEach.testFn (/Users/wesley/.vscode/extensions/ms-python.python-2018.5.0/out/client/unittests/unittest/runner.js:125:106)
	at Array.forEach (native)
	at server.start.then.port (/Users/wesley/.vscode/extensions/ms-python.python-2018.5.0/out/client/unittests/unittest/runner.js:124:49)
	at <anonymous>
	at process._tickCallback (internal/process/next_tick.js:109:7)
e.onDidNotificationChange @ notificationsAlerts.ts:40

The debugger currently doesn't support subprocesses, but that work is planned at some point.

@brettcannon this isn't a debugger issue. I believe the problem is, when the tests are stopped we aren't killing any child processes that are spawned. The old debugger does this, I guess we need to do the same thing here as well.

@DonJayamanne, are you saying the extension should do this or the debugger should?

On second thought, I don't think its up to the extension to kill child processes.
We're merely running the tests using the standard test runner (unittest, pytest, nose).
@WesleyYue If you were to run the tests manually (from the terminal), do the child processes get killed, I doubt it.

It's been a while since I filed the bug so I don't remember the details.

How are you stopping the tests through the extension?

I believe I did it through the menu. I start the tests with "Python: Run current unit test file" or something to that nature and then once the tests are running there is an option to stop the tests from the menu. I can double check these things tonight. Is there any other detail that might be helpful that I could try to find out tonight?

I wrote that, so I'd imagine SIGINT'ing the tests in the terminal does indeed kill the child processes.

If I'm not mistaken this is not true.
As mentioned earlier please confirm the child processes die when running tests through the terminal,
I'm closing this issue, please reopen if you able to reproduce this issue in a terminal.


Update DPS to Use Streamer Client Library Instead of GCP Streamer for Execution State Sync

Problem Definition
This Epic is concerned with the Streaming Client Library & DPS, a part of the Flow Access Node Refactoring. It is related to issue #2466.
The Flow Data Provisioning Service has a Live Binary for live sporks and Indexer for past sporks. It stores indexed data in a Badger database, which can be accessed by block height. It does so by acting as an unstaked consensus follower and downloading block execution records from a Google Cloud Storage bucket – which is constantly updated by an Execution Node.
With the development of the Execution Data Sync engine on the Access Node/Observer Service and streaming functionality of the Execution Data API, this implementation is outdated.
Proposed Solution
Since the Observer Service, Access Node, and Consensus Follower Library are all abstracted; DPS must be updated to reflect these changes.
DPS should use the Streaming Client Library to register itself as an execution data consumer/subscriber with the Execution Data API on an Access Node or an Observer. It should no longer use GCP Streamer to draw from a Google Cloud Bucket.
Step Definitions
•	Update Flow DPS Live Binary to pull block execution records from the Streaming Client Library instead of a Google Cloud Bucket through GCP Streamer.
•	Update Flow DPS Indexer to pull block execution records from the Streaming Client Library instead of a Google Cloud Bucket through GCP Streamer.
•	Update DPS Execution Tracker to receive block execution records from the Streaming Client Library instead of a Google Cloud Bucket through GCP Streamer.
Definition of Done
•	DPS no longer uses GCP Streamer or pulls from a Google Cloud Bucket
•	DPS instead initializes a Streaming Client Library and requests a network key for a host AN or Observer
•	DPS registers itself as an execution data consumer/subscriber to an Execution Data API
•	DPS receives catch-up execution data from the Execution Data API through the Streaming Client Library
•	DPS Live Binary pulls current spork data from Execution Data API
•	DPS Indexer pulls past spork data from Execution Data API
•	Streaming Client Library sends execution data in order of seal
•	Streaming Client Library calls callback for all registered finalization listeners

Blocked by https://github.com/onflow/flow-go/issues/2465


eslint-plugin unit tests aren't running on js - pullrequest

Due to the fact that they exist under the tools/ directory under the repo. The get-prpackageproperties exclusively finds packages under sdk, and as such we're never adding eslint-plugin to the package list for testing.
We have ways to counteract this in Language-Settings for this repo, need to execute on that.

js - eslint-plugin - ci wasn't actually running of of a ci.yml automation before. That tells me that disabling it was overaggressive, as it is checking something that isn't supported as a real package. I simply re-enabled the build definition.


Question: NaN canonicalization

Is there a way to enable the canonicalization of NaNs? As I see it is supported by the underlying library https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.cranelift_nan_canonicalization but I was not able to use it using this .NET package.

Unfortunately that setting is not exposed via Wasmtime's C API at the moment, so the .NET API can't expose it.
Would you mind filing an issue with the wasmtime repo to add it to the C API? Once that is fixed, I will expose it in the .NET API for you to use.
Thanks!

@peterhuene I have updated C API in his PR https://github.com/bytecodealliance/wasmtime/pull/4154, please check

@mralexes thanks again for implementing this! The feature should be available if you do a clean build of the latest out of the main branch.
When Wasmtime publishes a new version, I'll likewise publish a new package to NuGet with the feature.


Concern regarding headers changes in repo

i want to reflect some possible vulnearib:)lty issue in while deploying it on https , i need to get advice on places in code where i can do such changes

Hi, maybe this is some generic gradio thing.  Is there some specific problem with the info?


Add support for keepTypes on simplify.claims

I think that providing the value type on rich value claims could be beneficial.
For example:
const simplifiedClaims = wdk.simplify.claims(entity.claims, { keepType: true });

"P279": [ { "type": "wikibase-entityid", "value": "Q340169" } ]

thanks! merged and published as v5.10.0


python3 support, howto install using virtualenv

Might have missed a few places that's still not python3 compatible. Also fixed some syntax errors that I found while doing this.

Hey @sovaa - this is amazing! Thank you so much for your phenomenal work in updating Backdoorme to be Python 3.5 compatible, and for all of the miscellaneous fixes! We don't necessarily want to lose Python 2.7 compatibility - could your pull be modified to maintain backwards compatibility? Beyond the raw_input() -> input() and str() changes, overall the majority of the changes look to be backwards compatible already!
Thanks so much for your hard work and we look forward to including this in Backdoorme!

Happy to help out @Kkevsterrr! The input() is from the six package using from six.moves import input, not the new built-in method of python 3, so it's compatible. There were a few places left that were not compatible though, so I've fixed those. Seems like most things are working fine now in both 3.5 and 2.7. I had to include a check for six.PY3 for the str() change though.

@sovaa - This is really awesome! @Kkevsterrr and I have talked about it and we're really excited about someone else helping out with the project!
I've done a little testing myself and I haven't found any problems so far! I'll keep digging around but you've really reinvigorated the project!
We want to include a little shoutout to you on the readme somewhere - would you be ok with that? Again, thanks so much for everything you've done!

@ecthros sure. :) It's an interesting project, might contribute some more later on.


Formatting of SBH results table

In GitLab by @nwalczak on Jul 2, 2019, 11:00
This table gets used in the sidebar for the analyze function, and in the Add to SynbioHub dialog.  For analyze, the link column is too wide and causes the link buttons to get cutoff.  The SynbioHub add dialog has also been widened, but the link table has a hardcoded width that wasn't updated.

In GitLab by @nwalczak on Jul 2, 2019, 11:00
created branch 68-formatting-of-sbh-results-table

In GitLab by @nwalczak on Jul 2, 2019, 11:00
mentioned in merge request !20

In GitLab by @nwalczak on Jul 2, 2019, 11:12
closed via commit b668911b861aadae17793943e83e290e0141cad1

In GitLab by @nwalczak on Jul 2, 2019, 11:12
closed via merge request !20

In GitLab by @nwalczak on Jul 3, 2019, 14:26
mentioned in commit b668911b861aadae17793943e83e290e0141cad1


Return nil when xml-rpc returns an empty array.

SoftLayer_Network_Storage::removeAccessFromHost or removeAccessFromHost return SoftLayer_Network_Storage_Allowed_Host. However, when the return value is empty and xml-rpc is used, SL API returns empty array <array> </data></array> not empty struct and it causes unmarshal errors.
The following logic returns nil when val is not an array but the XML entry is an empty array. This PR is related to the issue https://github.com/softlayer/terraform-provider-softlayer/issues/132

@minsikl What is the complete XML response from SoftLayer? and what is the SL data structure being used on the client side to decode the XML?

@renier Here is an example:
Request:
POST /xmlrpc/v3/SoftLayer_Network_Storage HTTP/1.1
<?xml version="1.0" encoding="UTF-8"?><methodCall><methodName>removeAccessFromHostList</methodName><params><param><value><struct><member><name>headers</name><value><struct><member><name>authenticate</name><value><struct><member><name>username</name><value><string>abc</string></value></member><member><name>apiKey</name><value><string>abc</string></value></member></struct></value></member><member><name>SoftLayer_Network_StorageInitParameters</name><value><struct><member><name>id</name><value><int>22303335</int></value></member></struct></value></member></struct></value></member></struct></value></param><param><value><array><data><value><struct><member><name>id</name><value><int>73259895</int></value></member><member><name>objectType</name><value><string>SoftLayer_Network_Subnet_IpAddress</string></value></member></struct></value></data></array></value></param></params></methodCall>

Response:
<?xml version="1.0" encoding="utf-8"?>
<params>
 <param>
  <value>
   <array>
    <data>
     <value>
      <array>
       <data/>
      </array>
     </value>
    </data>
   </array>
  </value>
 </param>
</params>

@minsikl Was this the error you were getting? error: type mismatch - can't unmarshal struct to slice

@renier Yes.

When getting any other array response, the organization is different:
 <?xml version="1.0" encoding="utf-8"?>
<params>
<param>
 <value>
  <array>
   <data>
    <value>
     <struct>
      <member>
       <name>domain</name>
       <value>
        <string>ms.com</string>
       </value>
      </member>
      <member>
       <name>hostname</name>
       <value>
        <string>stgtest</string>
       </value>
      </member>
     </struct>
    </value>
    <value>
     <struct>
      <member>
       <name>domain</name>
       <value>
        <string>ms.com</string>
       </value>
      </member>
      <member>
       <name>hostname</name>
       <value>
        <string>storagetest</string>
       </value>
      </member>
     </struct>
    </value>
   </data>
  </array>
 </value>
</param>
</params>

There is no second-level nested array as in the other example above. This makes it a bug in SLAPI XMLRPC, as for empty array responses it adds an empty array as a first element of a first-level array (i.e. [][]struct instead of []struct).
By the time the error happens, the code has already walked the response value down to the first element type of the provided slice, and the incoming data still has a second-level array to decode which causes the mismatch.
I'm trying to see if there is a more subtle way to work around this.

@minsikl Check the branch unexpected-array-embeds. It seems to work for me.  You can use the following to test:
package main

import (
	"fmt"

	"github.com/renier/xmlrpc"
	"github.com/softlayer/softlayer-go/datatypes"
)

const input = `<?xml version="1.0" encoding="utf-8"?>
<params>
 <param>
  <value>
   <array>
    <data>
     <value>
      <array>
       <data/>
      </array>
     </value>
    </data>
   </array>
  </value>
 </param>
</params>`

func main() {
	var allowedHosts []datatypes.Network_Storage_Allowed_Host

	response := xmlrpc.NewResponse([]byte(input), 200)
	err := response.Unmarshal(&allowedHosts)
	if err != nil {
		fmt.Println(err.Error())
	}

	fmt.Println(len(allowedHosts), allowedHosts)
}

@renier I checked unexpected-array-embeds branch and acceptance test for softlayer storage in terraform-softlayer provider worked.


Alternative to provider.when...

Looking for an alternative to

@override
  Widget build(BuildContext context) {
     final _user = useProvider(MyUserProvider);
       ...
return _user.when(data: data, loading: loading, error: error)

for most of my components
I want to use sth like
final _user = useProvider(MyUserProvider);
// then
return Text(_user.name)

directly because the firebase user data stream is already in the tree and can never be null or have an error.
MyUserProvider is a Stream

Can I use a ChangeNotifier to achieve this ?
How else can I achieve this ?

You could do:
final user = useProvider(myProvider).data?.value;

where data will be null during load/errors.


Implement code splitting

Ref #568
Copy of https://github.com/tahowallet/dapp/pull/583 without image optimization

I would close it. Seems like we are good without it


IKEA Trådfri on/off switch appears as a light in HomeKit

Hello,
I have a IKEA Trådfri on/off switch connected to a Hue bridge v2 (I have no Trådfri gateway). Homebridge-hue recognizes the device but exposes it to HomeKit as a light. Strangely Alexa recognizes the same device as a plug. Would it be possible to expose the IKEA Trådfri on/off switch as a plug to HomeKit?
Thank you!

I have a IKEA Trådfri on/off switch

What device is that?  Do you mean the Trådfri Control Outlet?
To expose /lights and/or /groups resources as Outlet, create a resourcelink on the Hue bridge.  See https://github.com/ebaauw/homebridge-hue/releases/tag/v0.10.0.

What device is that? Do you mean the Trådfri Control Outlet?

Yes, that's it!
Thank you! I have created a resourcelink and now it shows up as and outlet.

Why does Homebridge-hue no longer try to determine whether a /lights resource should be exposed as an Outlet service to HomeKit? I'm interested in restoring this functionality so everything works without having to create a resource link. At present, installing the default config and saying "Hey Siri, turn all the lights on" results in every smart plug in the home switching on, which is not a sensible default.

Simply put: because that turned out to be unfeasible.  Too many devices report the wrong device type and get incorrectly exposed: lights as Outlet or outlets and wired switches as Lightbulb.  You might actually use a plug or wired wall switch to control a light, wanting to expose it as Lightbulb.  And then there’s no easy way to deal with heterogenous groups.


Shift moves AgentFollower faster

Describe the new feature you'd like
The agent follower is too slow. Life is short
Make it go really fast when shift is held

Duplicate of #99


refactored CSVPrinterTest.java PerformanceTest.java and PerformanceTe…

…st.java

Codecov Report

Merging #318 (f0b436e) into master (1842b78) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #318   +/-   ##
=========================================
  Coverage     97.87%   97.87%
  Complexity      549      549
=========================================
  Files            11       11
  Lines          1178     1178
  Branches        204      204
=========================================
  Hits           1153     1153
  Misses           13       13
  Partials         12       12

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

-1, this looks messy to me.

-1: this looks like changes for changes sake.

Closing: no reply.


Add Tunnelmole as an open source alternative to ngrok

I've noticed you have ngrok as the suggested tunnelling solution in your README. However, it has a few issues

Its closed source and proprietary. Because you can't review the source code, you can never be 100% sure what you are really installing
You can't self host ngrok

So, i'd like to update your docs to add tunnelmole. It has the following advantages

Its fully open source with a permissive MIT license
Optionally, Tunnelmole can be self hosted with the Tunnelmole Service. Otherwise it will use the default service at tunnelmole.com.

Here's the difference in terms of set up and usage
Ngrok
First download and install from ngrok.com
ngrok http 3000

Tunnelmole
Various installation options including npm, copy and paste shell one liner, building from source etc available in the README
For example, you can install with curl -O https://install.tunnelmole.com/12dg6/install && sudo bash install then run
tunnelmole 3000

There are a few options here

Do nothing, keeping ngrok as the only tunnelling option
Replace ngrok with Tunnelmole
Add Tunnelmole as an additional option

Let me know your preference and if you'd like me to make a PR with the changes.

I'd be happy to see a PR that has Tunnelmole as an additional option.


Distributed index processing

Is your feature request related to a problem? Please describe.
Indexing as of now is pretty slow on cheap hardware, at least if you have millions of links.  Apparently it's being worked on, but there's always room for improvement :wink:
Describe the solution you'd like
Create an API that allows clients to log in and lend processing power to the indexing process. Specifically: The client requests a batch of unprocessed documents, the server sends the batch and then waits for the client to upload the finished batch.
Case example: My project runs on a cheap server that only just indexed 1M links (out of 50M, with more to come). Me and a contributor would like to use our desktops for indexing, but the only way to do so is by stopping the indexing, downloading the DB and starting Meilisearch locally, then uploading the DB again, which only one of us can do at a time.
Describe alternatives you've considered
#410 could work - We could run Meilisearch on other machines just for indexing purposes, they don't need to answer any requests. The comment mentioning https://github.com/tikv/tikv is also interesting.

Hey @MCOfficer,
I think this is not the intended use case of MeiliSearch, but maybe you can use the snapshots to do that. Maybe you can use a bigger machine to do the indexing. Note that the indexing process is improving a lot and you will maybe be able to index this massive number of documents on your cheap server, in the next version of the engine.
Thank you anyway for the feedback.

This was to be expected, but it can't hurt to ask. I will look into snapshots, and i'm eagerly awaiting  the indexing overhaul ;)


Table content with multiple class

If I have a tr["warning"] work with td[class=danger] but doesn't work with td[class=success]
`

1
2
3

4
5
6

`
https://jsfiddle.net/3wkqy9xL/
Any advice?

Please don't use the issue tracker for how-to questions.
Also, shohldn't you use tr.warning and td.danger and td.success anx not tr["warning"] or td[class=danger] or td[class=success]

The Contributing Guidelines say:

Please do not use the issue tracker for personal support requests. Stack
Overflow (twitter-bootstrap-3 tag), Slack or IRC are better places to get help.

Please close this. Thanks!


Widget descriptionIcon "after" not showing

Package
filament/filament
Package Version
v3 beta4
Laravel Version
10.15
Livewire Version
3
PHP Version
8.2
Problem description
in StatsOverviewWidget

Expected behavior
show description icon color
Steps to reproduce
// from doc
  Card::make('Unique views', '192.1k')
                ->icon('heroicon-o-currency-dollar')
                ->description('asd')
                ->descriptionIcon('heroicon-m-arrow-trending-up')
                ->descriptionColor('success')

Reproduction repository

Relevant log output
No response

It's by design and this has been the same in v2.

the issue is due to prop renamed from :name to :icon for filament::icon component. fixed in the linked PR


(YAML) Handling of ''

Highlight.js seems to treat '\' in YAML as escaping the ' but with ' quoting the backslash does not escape the apostrophe in YAML.

Can anything be escaped in single quoted YAML strings?

Can anything be escaped in single quoted YAML strings?

https://yaml.org/spec/1.2.2/#single-quoted-style covers this. The apostrophe can be escaped by doubling it. That's it.


Create CODEOWNERS

Description

Release required?

[ ] No release
[ ] Patch release (x.x.X)
[ ] Minor release (x.X.x)
[ ] Major release (X.x.x)

Release notes content

Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
/run pipeline

Checklist for reviewers

[ ] If relevant, a test for the change is included or updated with this PR.
[ ] If relevant, documentation for the change is included or updated with this PR.

For mergers

Use a conventional commit message to set the release level. Follow the guidelines.
Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
Use the Squash and merge option.

Using https://github.com/terraform-ibm-modules/terraform-ibm-scc-workload-protection-agent/pull/104


Allows to specify source_ranges for cluster traffic firewall rule

This fixes https://github.com/hashicorp/terraform-google-consul/issues/45
Feel free to comment.

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement
Learn more about why HashiCorp requires a CLA and what the CLA includes
Have you signed the CLA already but the status is still pending? Recheck it.


Adding support for Inline Code and reading action source from URL

Closes #745
Closes #622
This PR includes following changes:

Error out if function and code both exists for an action.
Error out if runtime is missing when action code is specified.
Validate runtime, if specified runtime is part of the supported runtimes, else if default runtime can be retrieved based on the what is specified.
Added unit tests for these checks.
Added support of reading action file content over HTTP or HTTPS.
When function is set to remote URL, error out of URL is pointing to a remote directory instead of an action file.
Updated runtime errors to little more meaningful.
Updated manifest_parser unit testing to make sure we add a check on error from ComposeActionsFromAllPackages()
Fixed many unit tests in manifest_parser_test.go which were not running before this commit.

Failing at undeploy, looking into it.


[Perf] Include GA versions of core package

@gearama

I'm not sure what this actually means (source -> 1|source) but it seems benign.

This string is a regex to select which package versions to run.  Adding 1 includes the 1.X.Y versions of azure-core-cpp.


Fixing reference to the removed cdk.AwsRegion() construct

Pull Request Checklist

[x] Testing

Unit test added
CLI change?: coordinate update of integration tests with team
cdk-init template change?: coordinated update of integration tests with team

[x] Docs

jsdocs: All public APIs documented
README: README and/or documentation topic updated

[ ] Title and Description

Change type: title prefixed with fix, feat will appear in changelog
Title: use lower-case and doesn't end with a period
Breaking?: last paragraph: "BREAKING CHANGE: <describe what changed + link for details>"
Issues: Indicate issues fixed via: "Fixes #xxx" or "Closes #xxx"

[ ] Sensitive Modules (requires 2 PR approvers)

IAM Policy Document (in @aws-cdk/aws-iam)
EC2 Security Groups and ACLs (in @aws-cdk/aws-ec2)
Grant APIs (only if not based on official documentation with a reference)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.

The edited file doesn't exist anymore so I'm closing this PR. @Doug-AWS will take it to the new docs location.


Two questions that I hope to consult with you

Thank you very much for your sharing. I have two questions that I hope to consult with you.
1.If I would like to incorporate a validation set into your code, how should the code be modified?
2.When I change the BATCH_SIZE to 2 or 3, I encounter the following error. How should I modify the code to avoid such errors?
Traceback (most recent call last):   File "c:/Users/PC/Documents/Code/Sam_LoRA-main/train.py", line 59, in <module>     stk_gt, stk_out = utils.stacking_batch(batch, outputs)   File "c:\Users\PC\Documents\Code\Sam_LoRA-main\src\utils.py", line 101, in stacking_batch     stk_gt = torch.stack([b["ground_truth_mask"] for b in batch], dim=0) RuntimeError: stack expects each tensor to be equal size, but got [300, 450] at entry 0 and [500, 600] at entry 1
Thank you very much！

Hi, happy that you are interested.

An approach is to split the training dataset into a train set and validation set. You could then create a function to evaluate the validation set like in the ./inference_eval.py (line 35 to 51) with the score you want. Finally print/plot the train loss and validation loss to save the best checkpoint.

You will need to add a padding (zero padding will work).I used a batch size of 1 so the stacking of tensors wasn’t a problem. However when you go into a larger batch size, the stacking will need the height width dimensions to be equal. The labels in the dataset are not the same size so will need to crop the images (the original ones) or add a transformation in the dataloader process that will crop, center all the images so that you will only need to stack. You can add the transformation in the DatasetSegmentation object in src/dataloader.py class.

Hope it helps.

Hi, happy that you are interested.

An approach is to split the training dataset into a train set and validation set. You could then create a function to evaluate the validation set like in the ./inference_eval.py (line 35 to 51) with the score you want. Finally print/plot the train loss and validation loss to save the best checkpoint.
You will need to add a padding (zero padding will work).I used a batch size of 1 so the stacking of tensors wasn’t a problem. However when you go into a larger batch size, the stacking will need the height width dimensions to be equal. The labels in the dataset are not the same size so will need to crop the images (the original ones) or add a transformation in the dataloader process that will crop, center all the images so that you will only need to stack. You can add the transformation in the DatasetSegmentation object in src/dataloader.py class.

Hope it helps.

Thank you very much for your reply, and I will try it.
Additionally, I would like to consult you, have you tried the checkpoints of sam's sam_vit_l_0b3195 or sam_vit_h_4b8939? I tried to train with these two checkpoints and got a shape error, is there a part of code that needs to be modified?

Hello,
Could you show me the shape error you got?


[Bug]: When observing child property in a two-way fashion from ViewModel to Model, when the parent updates, the "old" parent gets updated with the new parent value

Describe the bug 🐞
This is tough to describe, I've added a repository to reproduce it. This issue is following a discussion on slack where this has been found almost certainly as a bug.
It happens on both Avalonia and bare WPF ( Thanks to @tomasfil )
When a viewmodel "binds" using WhenAnyValue to a child property of a model object, and the model object is replaced by a new one, the "old" model objects get set by a new object.
It is as if the "source" value of WhenAnyValue was cached, and when the object updates, it isn't reflected.
Here's an example in a repro repository : https://github.com/Tetedeiench/reactiveUiLiveModelEditIssue
public class ScheduleViewModel : ViewModelBase
{
    private SchedulePeriod _period;

    public SchedulePeriod Period
    {
        get => _period;
        set => this.RaiseAndSetIfChanged(ref _period, value);
    }

    private bool _isInfinite;

    public bool IsInfinite
    {
        get => _isInfinite;
        set => this.RaiseAndSetIfChanged(ref _isInfinite, value);
    }

    public ReactiveCommand<SchedulePeriod, Unit> SelectPeriodCommand { get; }
(...)
    public ScheduleViewModel()
    {
        this.WhenAnyValue(x => x.Period.IsInfinite)
            .DistinctUntilChanged()
            .ObserveOn(RxApp.MainThreadScheduler)
            .BindTo(this, x => x.IsInfinite);

        //viewmodel to model
        this.WhenAnyValue(x => x.IsInfinite)
            .Skip(1)
            .DistinctUntilChanged()
            .ObserveOn(RxApp.MainThreadScheduler)
            .BindTo(this, x => x.Period.IsInfinite);
(...)
    }
}

Let's imagine, in the current state, the IsInfinite bool is true.
The user now invokes the SelectPeriodCommand through a button. It changes the selected period in the viewmodel, thus the "Period" property is mutated.
The new period being set has "IsInfinite" set to false by default.
This triggers the two WhenAnyValue pipeline.
It seems that the second pipeline fires, and updates the previous model object, and set its IsInfinite property to false, instead of binding to the new object, as expected.
It is as if the "Period" value was cached and not properly updated everywhere.
See the screenshot section for a gif showing the visual representation of what happens.
Step to reproduce

Go to https://github.com/Tetedeiench/reactiveUiLiveModelEditIssue , download the repo, build & run it
Click on the control on the right hand side to change the current period properties
Click on the button on the left hand side to change the selected period
See the initial period properties being overwritten by the new period properties

Reproduction repository
https://github.com/Tetedeiench/reactiveUiLiveModelEditIssue
Expected behavior
The "old" Period object should not be mutated, and x.Period should resolve to the most up-to-date value to prevent this behavior
Screenshots 🖼

IDE
Visual Studio 2022, Rider Windows
Operating system
Windows
Version
11 and others probably
Device
PC
ReactiveUI Version
18.3.1
Additional information ℹ
No response

I can add the way how it feels short as possible:
".WhenAnyValue gets triggered for the new object, but the .BindTo binds into the old object"


Feature request: manually update option

Update automatically is convenient, but when my markdown note gets larger, this function will affect the performance of the whole Obsidian application. Hope to give the control of updating ToC to users! Thank you!!

Hello,
is this a hypothetical situation, or did you already run into that issue? If you did, could you please share a markdown example?

Thank you for asking! Here's the situation that I was editing a large markdown file with many levels of headings. And once I activate this plugin, the whole Obsidian became laggy. And I guess the plugin running automatically check and update has some influence on performance of Obsidian, that's why I mention this feature.

+1 for this feature. The speed-down is noticeable when editing a file with

150+ headings of different levels
~25000 words
~150000 characters
The speed-down disappears when the plugin is disabled, so I assume that its the rendering of the list of heading elements that's causing the speed-down.


Use ByteTextEncoding() for encoding strings in character based models

This PR modifies wmt.py to use text_encoder.ByteTextEncoder() to encode source and target strings in its character based data generators. This synchronizes the behavior with problem_hparams.py which uses text_encoder.ByteTextEncoder() to decode inferred strings. Prior to this PR, encodes and decodes in character models are different and results therefore incorrect.
The PR also defines the constant EOS with the value 1 to avoid a "magic constant" appearing in the source code.

No changes are needed in t2t-datagen since it never calls character_generator() directly. Instead, it calls the higher-level functions such as wmt.parsing_character_generator() and wmt.ende_character_generator(), but the signatures of those haven't changed (and don't need to change).
I will look at eliminating the no-vocab option and update the PR. This will require a change to wmt_test.py as well.

This should be OK now @lukaszkaiser

Great thanks Villi!

My pleasure!


Make RepublishMessageRecoverer.prefixedOriginalRoutingKey protected instead of private

Enhancement
Hello,
How do you find idea of making String RepublishMessageRecoverer.prefixedOriginalRoutingKey protected instead of private?
It would make if possible to override prefixedOriginalRoutingKey to send back with different routing key depending on message.
My case is I would like to add custom headers to message that is moved to DLQ (x-dead-letter-exchange) that is associated with a queue.
RejectAndDontRequeueRecoverer would be fine, but I can't add custom headers there.
RepublishMessageRecoverer is good for headers, but it sends back to wrong exchange - I would like to make it behave the same as RejectAndDontRequeueRecoverer about used DLQ/exchange.
Now I will have to override whole recover() with copy paste and write custom private prefixedOriginalRoutingKey.
If prefixedOriginalRoutingKey were protected, it would be sufficient to override it without necessity of copy-paste recover() and other private methods used by it.
I would like to:
@Override
protected String prefixedOriginalRoutingKey(Message message) {
            return message.getMessageProperties().getConsumerQueue() + ".dead.letter";
}

Regarding what @garyrussell wrote
but making that method protected won't change the exchange - you can set the errorExchangeName for that (also errorRoutingKey and then the prefix won't be used).
It seems to me that I can't get what I need with errorExchangeName or errorRoutingKey - they are static and I need to compute DLQ dynamically. If it do is possible, please show how could I implement it.
Thanks and Regards.

I am fine with making it protected; my comment was related to this...

is good for headers, but it sends back to wrong exchange

...there is (currently) no mechanism to choose a different exchange at runtime.
Feel free to submit a PR with the changes you need.


[BUG] Collapsable Iteration Panel

There is currently no design for the collapsible Iteration panel. As such, the implementation is incorrect.
According to the wireframes found here Iterations Wireframe, the + is for adding a new Iteration.

There is now a design for collapsing the iteration (left) panel: https://redhat.invisionapp.com/share/AVAL74W9N#/220509237_Collapse_-_Left_Panel_Open. This will be closed, as this particular bug has been fixed with a previous PR.


After upgrading Ollama. It just doesn't run anymore any model: Error: Post "http://<IP_ADDRESS>:11434/api/generate": EOF

I see this error everywhere during months. There are plenty of releases but this error continuesly appears.
Followed on Discord, searched on the web, saw issues on the repo related to this.
Did things like creating a Modelfile "dolphin-mistral" with FROM dolphin-2.1-mistral-7b PARAMETER num_gpu 0.
Ollama upgraded: curl https://ollama.ai/install.sh | sh
Nothing:
ollama run dolphin-mistral Error: Post "http://<IP_ADDRESS>:11434/api/generate": EOF
Any suggestion will be much appreciated.

Same thing, if I do ollama run llama2 it works fine but ollama run mario (created from this) raises this error:
Error: Post "http://<IP_ADDRESS>:11434/api/generate": EOF

watching ollama serve I found out this:

Thanks for sharing. Did you solve it? It seems more people are facing this issue.

It may be related to  #1952 ?

It may be related to  #1952 ?

It could and makes sense as I'm using it by doing a RAG on Langchain. But there is no really a workaround without the RAG. Is there any solution that you know that could solve the issue? I'm using dolphin-mistral because is a good one and needs to be uncensored.
Appreciate

Same problem for me on Manjaro, 6900 xtx:
Ollama serve
> ollama serve
2024/01/21 22:00:11 images.go:810: INFO total blobs: 6
2024/01/21 22:00:11 images.go:817: INFO total unused blobs removed: 0
2024/01/21 22:00:11 routes.go:943: INFO Listening on <IP_ADDRESS>:11434 (version 0.1.21)
2024/01/21 22:00:11 payload_common.go:106: INFO Extracting dynamic libraries...
2024/01/21 22:00:13 payload_common.go:145: INFO Dynamic LLM libraries [rocm_v6 cpu cpu_avx cuda_v11 rocm_v5 cpu_avx2]
2024/01/21 22:00:13 gpu.go:91: INFO Detecting GPU type
2024/01/21 22:00:13 gpu.go:210: INFO Searching for GPU management library libnvidia-ml.so
2024/01/21 22:00:13 gpu.go:256: INFO Discovered GPU libraries: []
2024/01/21 22:00:13 gpu.go:210: INFO Searching for GPU management library librocm_smi64.so
2024/01/21 22:00:13 gpu.go:256: INFO Discovered GPU libraries: [/opt/rocm/lib/librocm_smi64.so.5.0]
2024/01/21 22:00:13 gpu.go:106: INFO Radeon GPU detected
[GIN] 2024/01/21 - 22:00:15 | 200 |       40.73µs |       <IP_ADDRESS> | HEAD     "/"
[GIN] 2024/01/21 - 22:00:15 | 200 |     376.902µs |       <IP_ADDRESS> | POST     "/api/show"
[GIN] 2024/01/21 - 22:00:15 | 200 |     236.512µs |       <IP_ADDRESS> | POST     "/api/show"
2024/01/21 22:00:15 cpu_common.go:11: INFO CPU has AVX2
loading library /tmp/ollama1546965028/rocm_v5/libext_server.so
2024/01/21 22:00:15 dyn_ext_server.go:90: INFO Loading Dynamic llm server: /tmp/ollama1546965028/rocm_v5/libext_server.so
2024/01/21 22:00:15 dyn_ext_server.go:139: INFO Initializing llama server
free(): invalid pointer
[1]    275518 IOT instruction (core dumped)  ollama serve

Run
❯ ollama run codellama
Error: Post "http://<IP_ADDRESS>:11434/api/chat": EOF

I can't rn but did anyone try to do the same things using an older version from the releases?

Also here, ollama run * gives: Post "http://<IP_ADDRESS>:11434/api/generate": EOF.
With journalctl everything is fine except this:
2024/01/20 00:35:05 download.go:162: 54ee2a70d129 part 18 attempt 0 failed: unexpected EOF, retrying in 1s
2024/01/20 00:35:09 download.go:162: 54ee2a70d129 part 7 attempt 0 failed: unexpected EOF, retrying in 1s

Yesterday it worked fine

@venturaEffect could you provide the server logs so we can see why it crashed?
@ssebastianoo as others have noted, we're continuing to refine our memory prediction logic to balance using as much GPU memory as possible, without exceeding the capacity.  Can you clarify which version of ollama you were running?  0.1.21 has fixes that may solve this for you, but if you still see OOMs please let us know.
@t0m3k your crash looks like a Radeon related defect.  Depending on what @venturaEffect ran into, we might want to track the Radeon crash with a different issue.

@dhiltgen thanks! I have downgraded to older version suggested by @jmorganca . This solved the issue but now I'm facing another problem and it is that I can't use it for a RAG on Langchain because the context window is very limited. So it isn't useful at all. I'm trying to figure out how to solve this but it seems with Ollama llms it looks like a no exit road. Don't like it because we are loosing the power to use all these llms and are depending again on OpenAI and it's polite GPT. If you know any solution would be super appreciated 👍

I'm also experiencing this problem but only in some cases. e.g.
# These work fine
$ ollama run phi # 1.6GB, 2.7B parameters
$ ollama run llama2 # 3.8GB, 7B parameters

# This crashes with the same error
$ ollama run stable-code  # 1.6GB, 3B parameters
Error: Post "http://<IP_ADDRESS>:11434/api/generate": EOF

I have been running these using the docker image on a fairly low end laptop GPU and/or hybrid CPU in the case of llama2.
GPU specs:

NVIDIA GeForce MX150
CUDA core 384
Total dedicated memory 2048MB

I did find it interesting that stable-code 3B parameters, is approximately the same size as phi with 2.7B parameters. I would have expected the size to be about 10% difference between the two models. Perhaps there is some miscalculation in the model  size which might make the CUDA memory estimation wrong?
@dhiltgen I've attached the server log here. i.e. the output of docker logs ollama 2> ~/ollama_crash.txt
ollama_crash.txt

@silvergasp looks like you hit a GPU out-of-memory on 0.1.20.  We've added some fixes to 0.1.21 to improve low memory GPUs, but the algorithm still isn't quite perfect.
@venturaEffect if you can try with 0.1.21 and share the server logs that will help us understand if this is a known issue we're working on, or something new.

@venturaEffect could you provide the server logs so we can see why it crashed?
@ssebastianoo as others have noted, we're continuing to refine our memory prediction logic to balance using as much GPU memory as possible, without exceeding the capacity. Can you clarify which version of ollama you were running? 0.1.21 has fixes that may solve this for you, but if you still see OOMs please let us know.
@t0m3k your crash looks like a Radeon related defect. Depending on what @venturaEffect ran into, we might want to track the Radeon crash with a different issue.

I'm having the same exact issue and have tried all the same fixes. I can't find any instructions on how to check my version or to upgrade to a pre-release version. Can you please provide instructions for Ubuntu?

I'm having the same exact issue and have tried all the same fixes. I can't find any instructions on how to check my version or to upgrade to a pre-release version. Can you please provide instructions for Ubuntu?

To do a quick test:
wget https://github.com/ollama/ollama/releases/download/v0.1.21/ollama-linux-amd64
chmod a+x ollama-linux-amd64
sudo systemctl stop ollama
OLLAMA_DEBUG=1 ./ollama-linux-amd64 serve

@silvergasp looks like you hit a GPU out-of-memory on 0.1.20.  We've added some fixes to 0.1.21 to improve low memory GPUs, but the algorithm still isn't quite perfect.
@venturaEffect if you can try with 0.1.21 and share the server logs that will help us understand if this is a known issue we're working on, or something new.

I've done that already and shared to @jmorganca some days ago on Discord. He is aware of it. The problem is that even downgrading to a version that doesn't give this error the problem I'm facing is that it doesn't work for RAGs because of it's context window limitation issue. This has made me look for an alternative with LlamaIndex using their custom models. In any case I would love to use Ollama and Langchain but having this big limitation for RAGs it isn't very useful.

@venturaEffect I'm so sorry you hit an error with large context windows. Will be fixing this soon, keep an eye on https://github.com/ollama/ollama/issues/1952

Is there any solution that you know that could solve the issue?

It is not a solution but a workaround I am using until the bug is solved. I believe the problem is that ollama offloads more layers to the GPU than it will be able to handle. So I just trial-and-error change the number of layers to be offloaded to the GPU manually for the model you want to use until the model works.
ollama show dolphin-mistral --modelfile
will show the Modelfile of the model. I just use this Modelfile using FROM dolphin-mistral as the base model and adding PARAMETER  num_gpu x
Then create the model:
ollama create  dolphin-mistral_numGPU -f Modelfile_num_gpu_x
And keep modifying x until the model works.

Is there any solution that you know that could solve the issue?

It is not a solution but a workaround I am using until the bug is solved. I believe the problem is that ollama offloads more layers to the GPU than it will be able to handle. So I just trial-and-error change the number of layers to be offloaded to the GPU manually for the model you want to use until the model works.
ollama show dolphin-mistral --modelfile
will show the Modelfile of the model. I just use this Modelfile using FROM dolphin-mistral as the base model and adding PARAMETER  num_gpu x
Then create the model:
ollama create  dolphin-mistral_numGPU -f Modelfile_num_gpu_x
And keep modifying x until the model works.

Thanks, but this wouldn't solve the problem of context window limitation for RAGs with Ollama and Langchain I guess. It is just for the issue with the last Ollama version.

@silvergasp looks like you hit a GPU out-of-memory on 0.1.20.  We've added some fixes to 0.1.21 to improve low memory GPUs, but the algorithm still isn't quite perfect.

Just tried the latest docker image. Looks like it's working fine for me now. Many thanks!


Fixes a bug in AddHs() involving sp2 centers with degree 1

Hs are not put in the same plane as the sp2 system the atom belongs to. This affects ethylene (2 heavies only) and conjugated systems of any size.
This gist demonstrates the bug:
https://gist.github.com/ptosco/620edc8a3fd411928499204003eefb59
This gist shows the results obtained after merging this PR:
https://gist.github.com/ptosco/93f85d18794ed46da4122fa35bdb7b6e

The Windows CI failure is not a real one - failed download. The Windows DLL build passed.

@greglandrum Done. Yeah, I went a bit over the top with the std::copy_if thing - I really love implicit loop constructs : ) But you are right that I should then have sized the vector as getNumAtoms() and then trimmed it down afterwards. It does look simpler now. I'll save the std::copy_if for the next occasion.

@greglandrum Done. Yeah, I went a bit over the top with the std::copy_if thing - I really love implicit loop constructs : ) But you are right that I should then have sized the vector as getNumAtoms() and then trimmed it down afterwards. It does look simpler now. I'll save the std::copy_if for the next occasion.

You can actually use an std::back_inserter() to avoid needing to set the size in advance at all, but I still don't think it's the best answer here. :-)


add feature: Dark and Light Mode in website

HI @tusharzalte I want to add a new feature Dark and Light Mode to the resume builder website.
please assign under gssoc'23 label
Thank you

Issue has been assigned you 👍🏻

Hey @Eiman-Zulfiqar!, Can you please give me an update on this? I want to work on it.

@ZapeeoSheikh  i have already raised  this issue , And it was assigned to me .Please go through it and let me know.

@ZapeeoSheikh  ??