Monthly Archives: February 2014

What’s next for Shoes 3.2b3?

What are my plans for the Beta 3 release of Shoes 3.2?

I’m going to move the baseline Ruby up to Ruby-2.0.0-p451 from 1.9.3. There was a new patch release yesterday (p451) and 1.9.3 is now security fixes only. I modified the windows build hoping that 2.1.0 would fix the threading issues. It didn’t. Bummer for Windows.

The Ruby 2.0 effort is mostly about getting my chroots updated and consistent from a ruby POV. Most of the changes to the Shoes code have been made to accommodate 1.9.3, 2.0, 2.1. It’s just a small matter of getting the five rakefiles sets working on the same path as my intentions. Not as easy as I think – the rakefiles hate me. It seems that Ruby 2.0.0 added a lot of code. The .run files are much larger.

I might get binject working for the Raspberry pi. At the moment, March 1, 2014, it’s fighting back. I think net packaging would be something the pi folk might like, that would
also require some changes to the web infrastructure of Shoes. That might not happen.

Shoes Federales 3.2b2 for Linux

I have a newer beta release (b2) of Shoes for Linux. I fixed a few small bugs that you probably wouldn’t notice (ssl stuff). There is one feature improvement. Rubygems within Shoes has been updated to version 2.1.11 (2.2.2 for Linux) and it can compile gems with C extensions if you have gcc and make and friends installed. Fedora 20 has gcc as part of the basic install, Debian and Suse, nope. But, if you do, you can build and install those gems.

You could always do that if you built Shoes from source. It’s not something I expect a lot of Linux people really care about but it didn’t work reliably and damn it, some one wrote that code. So I fixed it.

  1. For 64 bit Linux
  2. For 32 bit Linux
  3. For Raspberry Pi (armhf)

Where is the Windows version of Shoes 3.2.b2? There is one, but it doesn’t download gems at all, much less build C extensions. The downloading in Windows appears to be a Ruby 1.9.3 threading issue. Kind of useless, if you ask me.

What’s next?
I’m sorely tempted to see if Ruby 2.0.0 will fix the Windows issues and it’s not like
Ruby 1.9.3 is all that current, so I have to do that sometime.
I’ve also got a soft spot in my heart and a hole in my head for Binject and packaging but that is a deep deep hole to wade into. Then again, I should use my knowledge of mkmf.rb while it’s still fresh.

Setting up a build environment for Shoes

Please see earlier blog postings about setting up chroots (and semi fake ones) for Shoes.

Now that I can cross compile Shoes and build installers for Linux 64 bit, 32 bit and raspberry, I need to automate the building even more. I’m almost finished with Shoes 3.2 so I wanted to build a beta 2 and I want to build all of them, once week if I don’t get around to doing it sooner. Upload them to a website is still a manual process, for good reasons,

In Linux, that needs cron and a working email smarthost so it emails me the results of the build. Email configuration for a smart host isn’t that hard. Just a Google search away. It might take a few times.

So I start with a couple of entries in my crontab.
# Update (apt-get) chroots
00 7 * * sun /home/ccoupe/bin/update-chroots
# build binary shoes one a week
30 7 * * sun /home/ccoupe/bin/build-shoes-all

That says on Sunday morning at 7:00 cron fires off a script update-chroots and at 7:30 it launches the build script. The update-chroots is not particularly clever. It just does an apt-get update (I have to be the root user though and the schroot configuration has to allow me to do that) Here’s the update-chroots script:
schroot -c debx86 -u root -- apt-get -y update
schroot -c deb386 -u root -- apt-get -y update
schroot -c debrpi -u root -- apt-get -y update

Just login into the chroot as root and run apt-get. The build-shoes-all is equally not very impressive.
# Build all binary variations of shoes. This runs under
# my crontab so user name may not be set up for chroot
schroot -c debx86 -u ccoupe -- ~/bin/build-shoes-x86_64
schroot -c deb386 -u ccoupe -- ~/bin/build-shoes-i686
# raspberry doesn't use chroot for shoes, just for the deps

Instead of running the apt-get command in the chroot, I run a script in the chroot. Since the raspberry build doesn’t run in a chroot I just run directly. Of course the build-shoes-xxxx scripts are very similar because Shoes is easy to compile when everything is setup correctly.
It all makes sense but this is a gotcha that I’ll talk about after you look at the files.
echo "Build Shoes X86_64 for Linux"
cd /home/ccoupe/Projects/shoes3.2
rake clean
rake linux:setup:x86
rake package
ls -ld pkg/*

echo "Build Shoes i686 for Linux"
cd /home/ccoupe/Projects/shoes3.2
rake clean
rake linux:setup:x32
rake package
ls -ld pkg/*

echo "Build Shoes raspberry pi for Linux"
cd /home/ccoupe/Projects/shoes3.2
rake clean
rake linux:setup:crosspi
rake package
ls -ld pkg/*

That’s pretty simple, right? I edited my .bashrc and put the ~/bin directory in the PATH and I can run build-shoes-all or the individual builds from the command line or cron.

Did you forget the Gotcha comment above?
When you switch to a chroot it screws with the environment variables – PATH being the important one. It just has to. What isn’t removed in my chroot PATH are entries for rvm which won’t work in a chroot. Remember, to build Shoes in a chroot we only need a ruby that can run the rake commands. We don’t care if it’s Ruby 1.8.7 or 2.1.1 or in between.

We have to set the PATH inside the chroot to something minimal w/o rvm frills. Inside schroots, my HOME dir /home/ccoupe/ is available, so I have another script in ~/bin/bash-chroot

#! /bin/bash
export PATH=/usr/local/bin:/usr/bin:/bin:/home/ccoupe/x-tools/armv6-rpi-linux-gn
export DISPLAY=:0.0

All we have to do is sweet-talk schroot into sourcing that file. What I am about to tell you, you need to understand that you can trash your login if you make an error and don’t know what to do about it. I’m running Ubuntu 13.10 and my [s]chroots are debian 7.2 (and the raspbian variation). Copy your .bashrc to .bash_profile. Edit .bash_profile and at the end where you’re supposed set to the PATH your way source ~/bin/bash-chroot. My .bash_profile after the copy had this at the end:

export PATH=$PATH:~/x-tools/gcc-linaro-arm-linux-gnueabihf-raspbian/bin
export PATH=$PATH:~/bin
source ~/.rvm/scripts/rvm

Just replace that with

source ~/bin/bash-chroot.

It works for me in the Debian 7.2 chroots. It doesn’t work on my raspbian chroot but since I don’t build raspberry Shoes inside the chroot I don’t care. Diminishing returns and all that. No doubt someone out there thinks it would be more elegant to use real virtual machines or building in the cloud. IHO, that’s overkill with diminishing returns for something as simple as Shoes but you can draw your own line between elegance and pragmatic.

I’ll add some build-shoes-xxx scripts for MinGW (native widgets) and MinGW (Gtk2) but you can see how trivial that will be.

FINALLY, I want to mention that I’ve disturbed the force by modifying app.yaml to have major-minor-tiny version numbers. Mine looks like this:

name: Shoes
major: 3
minor: 2
tiny: b2
release: federales
win32: platform/msw/shoes.ico
osx: static/Shoes.icns
gtk: static/shoes-icon-federales.png

Notice how I’ve set tiny: ‘b2’ –> beta-2. Soon it will be ‘RC1’ and then final ‘.1’. Coming Soon. That’s how I want to control the version numbers. Not with ENV variables I’ll forget to set or don’t exist in an new terminal.

Ruby 2.0.0 and Shoes Federales (3.2). And Gems

I’m feeling good. I managed to get Shoes gem Setup code working a couple of days ago. It was pretty broken. Now it uses the modern Gem API. Actually, I think that might be the last thing on the list from declaring that Shoes 3.2 is on feature parity with 3.1, 3.0 and less buggy.

It won’t install all the compilers and libraries need to build a gem from source – that would be a magical mystery enhancement. Now days, many gems have precompiled binaries for Windows. (I should test that on Windows).

Of interest to some Linux folk, I have compiled, tested and fixed some things with Shoes so that you can build with and use Ruby 2.0.0 (instead of the new old reliable 1.9.3). That took some serious head scratching because the Shoes built-in manual failed with Ruby 2.0.0. Not anymore. I’m happy to fix that now. One less thing to fix in the 3.3 release. Come to think of it. There might not be any bugs that keep me from releasing 3.2 or an RC1. Other than that testing thing.