I bought a WiPy 2.0 from pycom and noticed, that the documentation assumes you also bought the expansion board (which I didn’t). The board has some components but most of them are for the SD card support or the LiPo charger. An (older?) version of the board is documented here. What you really need is only some sort of power supply and a USB serial (3.3V). The pinout of the WiPy board is here

I connected a spare ESP8266 programmer to the RX and TX ports and used another USB port for the 5V supply. You can also power the board with 3.3V via the 3.3V pin, but you need at least 500mA (more info).

The source of this blog is now available at github. Also I’m now using travis-ci to generate the static files and deploy them to my server. Stuff I found out:

travis-ci language

If you use docker to run your commands, the language you specify in the travis.yml file doesn’t really matter.

ssh-key for scp

My deploy script uses scp, so travis needs access to my server. For that, I created a new ssh-key:

ssh-keygen -t rsa -b 4096 -C "Travis CI loopylab" -f travis_loopylab_key

Then added the public part to my server and encrypted the private part with the travis cli:

travis encrypt-file travis_loopylab_key

The newly generated file can be pushed to your repository and no one can readout the key (hopefully).

Now just add the following lines to your travis.yml:

addons:
    ssh_known_hosts: dirkheinke.de
[...]
before_deploy:
    - eval "$(ssh-agent -s)"
    - openssl aes-256-cbc -K ... # use the output of the travis cli
    - chmod 600 /tmp/travis_loopylab_key
    - ssh-add /tmp/travis_loopylab_key

deploy:
    skip_cleanup: true
    provider: script
    script: ./_deploy.sh
    on:
        branch: master

You can find my full travis.yml here

PS: Don’t try to put the private key in a environment variable from travis, because the line breaks are important for ssh.

docker in travis-ci

You can use docker commands in every part of the travis.yml file, even if the documentation only mentions the before_install part.

If you try to run a playbook with the ansible-docker plugin, and you get an error like this

failed: [192.168.2.xxx] => {"changed": false, "failed": true}
msg: Docker API Error: client and server don't have same version (client : 1.19, server: 1.18)

FATAL: all hosts have already failed -- aborting

Solution

You can set the api version to a fixed version. The better way is to use the “auto” feature from docker-py:

- name: start ....
    docker:
      docker_api_version: auto
      image: ....

If you find lines like this in your nginx error.log and your nginx is not starting on a reboot, you might have a DNS/network problem:

2015/03/29 11:17:50 [emerg] 1482#0: host not found in upstream "xxxx.io" in /etc/nginx/sites-enabled/xxxx:12
2015/03/29 11:17:50 [emerg] 1483#0: host not found in upstream "xxxx.io" in /etc/nginx/sites-enabled/xxxx:12
2015/03/29 11:17:51 [emerg] 1504#0: host not found in upstream "xxxx.io" in /etc/nginx/sites-enabled/xxxx:12

Nginx with default values is started, before the network in completely up. My quickfix is to restart nginx after the network is available:

$ cat /etc/network/if-up.d/nginx
#!/bin/sh
 
/etc/init.d/nginx restart

After the last archlinux update, my cursor was about 3 to 4 times bigger than normal. First it only occurred in skype, but after a reboot it affected the cursor everywhere.

After searching a bit I found this post in the Arch Linux forum. The most practical answer is to comment out the Inherits=Adwaita, which is set through new dependencies:

$ nano /usr/share/icons/default/index.theme

[Icon Theme]
#Inherits=Adwaita

Then restart X and your cursor should be normal again. The problem only occurs, when no other theme is set, so it’s likely that only users with basic/uncommon display environments are affected (like in my case xmonad).