Compressing objects: 100% (164/164), done.
error: RPC failed; result=22, HTTP code = 411
fatal: The remote end hung up unexpectedly
Writing objects: 100% (570/570), 6.08 MiB, done.
Total 570 (delta 276), reused 551 (delta 264)
fatal: The remote end hung up unexpectedly
fatal: expected ok/error, helper said '2004�f��,'�c6��}{�c�eM��#�>�'

fatal: write error: Broken pipe


The actual error message part changes if you try again thinking it might have been a network error.

The fix was to change git configuration to have a larger http post buffer of 100MB.

git config http.postBuffer 104857600


Thanks to github support.

I reinstalled the 32 bit version of mysql and then recompiled the mysql gem. Then magically things started working the way I needed them to. Hopefully this can get fixed in a future version of Ruby.

Here is the command I had to use to finally install the gem properly.


sudo env ARCHFLAGS="-arch i386" gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config --with-mysql-lib=/usr/local/mysql/lib --with-mysql-dir=/usr/local/mysql --with-mysql-include=/usr/local/mysql/include


Notice the i386 arch. I was previously using x86_64 as the arch which compiled properly and appeared to work until you actually tried to use the gem in ruby and got a stack trace.

All I had to do to fix the problem was disable IPv6 and comment out the localhost ::1 line in my hosts file. This took a significant amount of troubleshooting to figure out though. I thought there was some type of problem with PHPUnit or php itself. Luckily I was finally able to solve the problem.

It seems like a really bad idea for Microsoft to enable IPv6 by default and additionally put it higher in the resolution order than IPv4 addresses. Based on the number of active IPv6 networks this can’t be a good default decision. Supporting IPv6 is a good idea, but it shouldn’t be the default method of resolving addresses. Windows should have knowledge that you are connected to an IPv4 network and disable or lower the priority of IPv6 accordingly.

I finally found out how to use Svn auto-props today. These are very nice. You can set a given property based on a files extension or filename pattern. This allows for doing things like:

[auto-props]
*.py = svn:keywords=Author Date Id Revision

This means I don’t have to keep adding svn keywords on every file I add. It just gets turned on for all python files I add to svn. These properties are set in the svn config file on the client, so every client can have their own settings. Very handy.

For example I wrote a report generation class for Testlink that uses Spreadsheet_Excel_Writer and I wanted to check that this dependency is met during installation. This isn’t as clear cut to do as it should be though. I wasn’t able to find any standard way in documentation for how to check if a PEAR module is actually even installed. First I tried to use the built in is_file() function in php. This doesn’t honor the include_path though so it isn’t very useful with PEAR. So I ended up just doing an include_once() for the module. This isn’t very clean though as it throws a really ugly error for the user if they have error reporting turned on in their PHP configuration.

So here’s to hoping that PHP and PEAR will someday work together in a more clean way. I would think this would be a very common operation for any project that relies on PEAR modules. Apparently it isn’t though.