Tag Archives: instructions

Building xpra on RHEL6 as a normal user

Xpra is described as “screen for X”, and while that’s true, I’ve never really used GNU screen much. What I use it for, though, is provide a much faster substitute for X forwarding (even on a local network).

I have access to a nice machine that I’d like to work remotely on. Two catches: I’m not root, and it’s running RHEL6 with minimal extra package repos. To install software locally, I use GNU stow along with some nice setenv action in files sourced by .cshrc. Here is what I was able to do to get Xpra running at a minimum capacity.

Note: $STOW is whatever your stow directory is – all the stow documentation essentially assumes that it’s /usr/local/stow, but in my case it happens to be (wait for it) /home/users/rpavlik/linux/stow/rhel6/stow. Yes, I could have probably chosen a location with a shorter pathname, but inertia makes it not worth changing at this point. I’ll use $STOWPREFIX to refer to wherever stow links things into, usually the parent directory.

  1. I asked my friendly department IT folks to install the dependencies from https://www.xpra.org/trac/wiki/Building – which in my case, wasn’t exactly what happened since EPEL or other package repos are off-limits, but I ended up with whatever the latest official versions are of those dependencies for RHEL6.
  2. Grabbed Cython 0.20.1 since the RHEL6 Cython is too old. Copied the contents of the tarball into $STOW/Cython-0.20.1/lib64/python except for the bin directory, which instead went became $STOW/Cython-0.20.1/bin. Stowed Cython-0.20.1 – note that this is a build-time dependency only (I think).

  3. Made sure that I had my PYTHONPATH environment variable set to include (it may be empty to start) $STOWPREFIX/lib64/python. On the next login, I checked that which cython and cython -V reported values that I expected.

  4. Grabbed Xpra 0.11.6 and unpacked it. I initially built without a lot of ffmpeg/libav stuff, but it turns out that there are patches in the source tree to handle old versions. I patched with these commands:

    • patch -p1 < patches/old-libav-pixfmtconsts.patch (replaced --without-csc_swscale flag)
    • patch -p1 < patches/old-libav-nofree.patch (replaced --without-dec_avcodec flag)
  5. In the source directory, I ran ./setup.py install --home=$STOW/xpra-0.11.6 -without-vpx which almost worked except for one place where it tried to write to /etc. I applied this trivial patch to correct that.

Adding --without-client to the build command is an option I considered since I typically use this home directory on a headless machine, but it’s shared with headfull machines which I might want to use as Xpra clients someday.

And…. that worked! I had to run with --no-mdns since I didn’t apparently have the Avahi mDNS python module installed on the system, but that’s a minor issue easily worked around.

Drat – SparkleShare unofficial PPA includes breaking update

The SparkleShare unofficial PPA contains a python-gobject update that breaks a number of things, including software center/update manager, gedit plugins, etc. On the page for this PPA it does now mention that it’s not recommended for Ubuntu Precise 12.04 – but it’s a bit too late for me to avoid issues.

What’s more, ppa-purge ppa:rebuntu16/sparkleshare+unofficial doesn’t seem to work – it tries to remove most of the packages installed on my system. Same result when trying to force versions with Synaptic. Thus, I unfortunately had to write my own little tool, using python-apt. It asks for no confirmation, and the only test is that it worked on my machine. Consider this fair warning. The script is here.

Run the script to apply the changes, then edit your sources.list or sources.list.d to remove this source, sudo apt-get update, and check in Synaptic to make sure you didn’t miss anything (which would now show up in the Status panel under “Installed (local or obsolete)”).

If anybody wants to help make this an improved replacement for ppa-purge, please let me know and I’ll fork it into a real GitHub repo instead of just a Gist.

Making a CMake-based build install software in de-facto standard locations

This post falls partially into the “Note to self” category. I typically set up CMake variables for “bin”, “lib”, “share”, and so on to use when installing software (or building it if I want it to run in the build directory and it’s stubborn about layout). Turns out that there’s a module called GNUInstallDirs that was added to CMake in 2.8.5, and improved since then, that sets these up in a standard-ish way. Furthermore, when distros package CMake, if they don’t follow the defaults, they typically patch this file so it applies, so this really takes care of the whole “what to call the library directory” mess quite nicely.  The canonical source documenting the meaning of these variables comes from the GNU project, but I’ve separated the most common ones below (listed ready to copy-and-paste into your build):

  • ${CMAKE_INSTALL_BINDIR} aka “bin”
  • ${CMAKE_INSTALL_LIBDIR} aka “lib” or “lib64” or something more complicated for Debian multiarch
  • ${CMAKE_INSTALL_INCLUDEDIR} aka “include”
  • ${CMAKE_INSTALL_DATADIR} aka “share” – not sure what the difference between this and DATAROOTDIR is, but it appears nobody else does either, so I’m just gonna roll with it.

As a side effect, you’ll get a unixy layout on other operating systems too, but as I already was doing this, it’s cool with me.

If you mixed Git and Dropbox, and made it open source…

…you’d get SparkleShare. It automatically synchronizes directories to Git repositories, whether you host them locally or on some service like GitHub.

Now, don’t get me wrong: this isn’t how you want to do version control for your software, where meaningful commits are important.  This is more for “data” or “asset” files – I’ve seen it used for project artwork/icons, for instance. It can also be handy for managing an essentially static web site built with a tool like Jekyll. For those use cases, it can be a great tool, particularly for non-programmers.

I’ve recorded a screencast showing how to install (even as a non-admin) the app on Windows, set it up to link with your GitHub account (they handle ssh keys transparently in the background), and add your first repo. Enjoy!

[EDIT: Sorry, Screenr has gone away along with this screencast.]


[EDIT TO ADD]: Ubuntu includes SparkleShare in its repos, but it’s an outdated version (in all releases). A useful PPA to add would be this: https://launchpad.net/~rebuntu16/+archive/sparkleshare+unofficial Note that SparkleShare requires Git, and the newer the version of Git, the better your life generally is, so make sure you have the Git update PPA also enabled: https://launchpad.net/~git-core/+archive/ppa . Something like this would add them for you:

sudo add-apt-repository ppa:rebuntu16/sparkleshare+unofficial
sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update
(optionally sudo apt-get dist-upgrade or other method of upgrading your git packages)
sudo apt-get install sparkleshare

SolidWorks to OpenSceneGraph

[Update March 26: Re-uploaded the tool, I had scaling backwards.  Oops!]

File format management seems to be a perpetual problem in CAD.  For folks looking to convert a SolidWorks assembly to use in OpenSceneGraph and maintain the position and orientation of the parts relative to each other, we’ve figured out what seems to be the ideal workflow, at least for now.  A nice feature: it doesn’t require any commercial, proprietary software beyond SolidWorks itself.  I’ve documented the process in two screencasts on my Screenr account, which I’ve embedded below.

Download the Windows tool used in the screencast here: osgconv-20130319-solidworks-stl

First step: Export files from SolidWorks to STL.

Second step: Convert STL files to OSG files in bulk.

Using C++ on the Arduino: a mainstream C++ Standard Library port for the AVR!

The Arduino development environment (and more generally, the avr-gcc/avr-libc/avr-binutils toolchain) supports, and in the Arduino core library, uses C++ language features.  However, a C++ standard library is not included, which makes using other C++ libraries (even just the header-only libraries in Boost) a challenge, and can result in less effectively-C++ code.  Among my goals in seeking C++ standard libraries for the Arduino include the ability to use the excellent Eigen matrix-math library and some of the header-only Boost libraries.

(tl;dr version: visit https://github.com/vancegroup/stlport-avr/wiki !)

A number of individuals have worked on ports of (partial – at least the Arduino IDE disables RTTI and exceptions, and fstream is little use without a filesystem) C++ standard library implementations. (Keep in mind that the C++ standard library is more than just the STL – the string library is sometimes considered part of the STL but is technically its own thing, as well as the streams library.)  The following are the previous attempts I’ve found:

  • Andy Brown ported the original SGI STL (not a full C++ standard library) but with some additions to bring it closer to a full standard library. He considered libstdc++ (too embedded with the desktop GCC toolchain) as well as uSTL (which he eliminated due to larger generated code size) before porting the SGI STL. He made a number of customizations to it that, while making it less standards-conforming, made it more suitable to use on AVR devices. He supplemented it with a streams implementation based on  uClibc++, as well as some custom features for the AVR and Arduino environment. (For instance, iostream implementations for HardwareSerial and character LCDs.) The library is header-only, so you only pay in compile time for what you use. However, the SGI STL precedes the standardization of the C++ standard library with STL (it’s an [the?] initial implementation…), so compiler and library compatibility are sometimes a bit sketchy.
    • The SGI STL license is a fairly liberal, non-copyleft license that Debian’s licensecheck.pl won’t identify for me :-). The portions from uClibc++ are LGPL 2.1+, and the headers written by Andy specifically for the arduino (lcdostream and serstream) are under a three-clause BSD license.
  • “maniacbug” started the Arduino library StandardCplusplus, a fairly direct port of uClibc++ . uClibc++ is a more modern implementation than the SGI STL (that is, it’s a post-standardization implementation) and aims to be a full C++ standard library.  I found that to use for my purposes, I had to make a number of modifications (particularly in implementing the limits header), which are on my GitHub fork of StandardCplusplus. It’s concise and easy to read, but its relative incompleteness in the areas I needed made it some effort to maintain.
    • License-wise, uClibc++ is LGPL 2.1+ which keeps it easy to move code in, but harder to move code out, and a bit confusing for embedded. (avr-libc uses, and seems to recommend, an MIT-style non-copyleft liberal license – presumably to avoid potential complexities over requirements and definitions of linking, derivative works, etc. given the nature of embedded code as being flashed into hardware.) The stream classes by Andy Brown were also added to this library, under the same three-clause BSD license mentioned earlier.

While I had gotten StandardCplusplus to a state where I could mostly use it, I found myself hitting a number of issues bit-by-bit. Furthermore, a number of the fixes/needed implementations were because of gaps in upstream, rather than porting issues, and the break between the upstream uClibc++ and the Arduino-layout, Arduino-specialized version made it harder to justify fixing issues that would be bothersome to port upstream and/or marginally likely to be accepted (AVR-specific code somewhat scattered, and behind ifdef __AVR__ or ifdef ARDUINO guards).

With this background, I’d like to introduce my new development, and what I’m using now: the addition of an AVR port to the STLport project, which I’ve posted on GitHub.  STLport is liberally-licensed, and evolutionarily, it descends from the SGI STL that served as Andy Brown’s starting point. However, STLport, despite its name, can be configured as a full C++ standard library. It has been extended, expanded to include newer C++ standards and TR1, and (as suggested by the name) ported to work with many compilers. This porting was done smartly, by limiting platform-specific macro checks to configuration headers, which define feature-focused configuration macros as needed for use in the rest of the library. This meant that my changes could be fairly limited in files touched: primarily adding a config header for AVR, modifying the GCC config header to avoid assumptions that are untrue on AVR, and creating/applying a few more feature-focused config defines to reduce the library’s size and porting overhead. While the last tagged release was in 2008, the project has been moved to a Git repository and has been under some development since then. For instance, changes to the STLport-5.2 (stable) branch are as recent as April 2012, and the master branch in fact is (working toward being) a C++11 standard library.

I’ve made ports for both the 5.2 stable branch and the master branch. The library can be built using the STLport build system if you prefer, though if you’re using Arduino, all you’ll need is one of the “arduino-installed” branches: these are generated by a script rearranging the sources/headers from the mainline branches. This way, they won’t fall (much) behind and can easily be reproduced. (I could have claimed success without these branches, however, I find it convenient to keep Arduino libraries in Git submodules, and the branch solution provides a straightforward, nontechnical way to use the library directly with the Arduino IDE.) Both the C++11 and stable 5.2 versions work with the Arduino core library, though note that you’ll need to put your compiler into C++11 mode for the master branch. As far as I can tell, this can’t be done with the Arduino IDE.

I’ve verified that both versions compile as a static library on their own. I’ve also verified that C++ Standard Library-using Arduino sketches build using (my branch of) Arduino-Makefile (with appropriate EXTRA_CXXFLAGS as needed) on both the master and 5.2 branches, and that sketches build successfully using the Arduino IDE and the 5.2 branch. My test system for this has been an Ubuntu Lucid x86_64 machine, with the following package versions updated from Debian Testing:

  • arduino and arduino-core  – 1:1.0.1+dfsg-6
  • gcc-avr – 1:4.7.0-2
  • binutils-avr – 2.20.1-3
  • avr-libc – 1:1.8.0-2

On Windows, I’ve been using the Arduino 1.0.1 IDE upgraded with Windows binaries of gcc-avr 4.7.0 and avr-libc 1.8.0 from Andy Brown (caveat: save your original avr-size.exe and put it back in place after). As this updated  is substantially the same as what I use on Linux, I’m pleased that as expected, building on Windows with the 5.2 branch in the IDE works just fine.  Remarkably, though the toolchain bundled with 1.0.1 on Windows is very very old (gcc 4.3.3) and contains some annoying-to-really-bad bugs for AVR, it at least built my (complicated template metaprogramming and STL algorithm-based) test app, only being slightly more picky about my nested template syntax.

So, give it a try! Let me know if it works for you – and if you have improvements, or find things that don’t work, please feel free to send an issue or pull request on my STLport for AVR/Arduino GitHub repository.


Using dfu-programmer with an Arduino Uno R3

Sometimes, whether intentionally (you want to “be” a different USB device) or unintentionally (your board is bricked), you want to replace the firmware on the little atmega usb chip used on the Arduino Uno.  Unfortunately, most of the instructions out there are for the Uno R2 or earlier: the R3 has a slightly different chip.  Adding to the trouble, the Linux/Mac tool for doing this operation (a “DFU upload”) has different USB product IDs than expected.  So, here’s the differences from the earlier Uno (with ATMEGA8u2) to the latest R3 (with ATMEGA16u2):

  • The dfu-programmer command line should contain at90usb162 instead of at90usb82.
  • If the version of the dfu-programmer you’re using (which includes the latest SVN as of this posting) doesn’t recognize it, you’ll want to get the latest source code and apply this patch, which adds a different device name (at90usb162unor3 instead of at90usb162) that uses 0x2FEF as the product ID.  (Thanks to http://forums.adafruit.com/viewtopic.php?f=25&t=25146 for the tip which led me to create the fix.)  I opted to add a new device type, rather than change the existing one, in case someone actually takes the patch upstream and if the original product ID is correct for some devices, just not our Arduinos.
  • I used the Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex firmware file and had to pass the –suppress-bootloader-mem flag to the dfu-programmer flash command for it to work.

Quick Tip: Recording Audio with Java-based screencast apps on Win 7 x64

I’ve been looking at some web java-based screencasting apps, namely screenr and  Screencast-o-matic, which look suspiciously similar. I wanted to record a voiceover along with a screencast, but couldn’t get it to work – on a Windows 7 x64 machine with 64-bit Java 7 installed (as well as I think 32-bit Java 7).

Long story short, the only way I could get either tool to recognize the fact I had any sound recording devices at all was to run it in Internet Explorer 64-bit (heaven forbid!). Hopefully this helps someone – if you know why this is, I’d be curious to find out.

My “Compiling Boost on Windows” Cheatsheet

Boost is a great set of libraries that is pretty generally available – on Linux, that is. On Windows, though there are installers available, I tend to have better luck building it myself, though I always need to go digging for the instructions I wrote “last time” I built it.  So, here for my reference and yours, is how I build Boost, for Visual C++ version X: (pretend it’s all on one line)

bjam --build-dir=vcX toolset=msvc-X.0 architecture=x86 link=shared
threading=multi runtime-link=shared variant=debug,release
--without-mpi --prefix=boost-vcX-install stage

For a 64-bit build, I add “x64” to all directory names, and this parameter:


Recommended PPA + Third Party Repositories

I’ve been setting up a number of new Ubuntu installs recently, and so I thought it would be useful to record somewhere the Personal Package Archive (PPA) and third-party repositories I frequently use. You can add any of these with sudo add-apt-repository or by pasting them into the add repository dialog in Software Sources.  I have all these enabled on Lucid successfully, but no guarantees that they will all successfully coexist without breaking things on your system, Lucid or otherwise.

  • General Software
    • ppa:chromium-daily/stable – the Chromium stable channel. If you prefer the Google Chrome version, try:
    • deb http://dl.google.com/linux/chrome/deb/ stable main – The Google Stable channel. For the key, look at ubuntu-tweak.com/source/google-chrome/
    • ppa:sevenmachines/flash – 64-bit Adobe Flash, install package “flashplugin64-installer”
    • ppa:libreoffice – Updates to LibreOffice, the future of OpenOffice.  Still incredibly slow, but sometimes it’s all you can use.
    • ppa:ubuntu-wine – The latest Wine stable and dev releases.
    • ppa:lucid-bleed – If you want lots of backports to Lucid, this is the repo to enable.
    • ppa:maco.m/ruby – Updated version of rubygems
  • Graphics (XOrg, drivers) Improvements
  • Programming-related
    • ppa:kubuntu-ppa/backports – Backports of newer Qt versions including Qt Creator.
    • deb http://streaming.stat.iastate.edu/CRAN/bin/linux/ubuntu/ lucid/ – Updates for R from the ISU CRAN mirror.  If you’re not using Lucid, change the release codename in this line
    • ppa:pyside – PySide is the LGPL replacement for PyQt that works pretty well. It’s under plenty of development so the PPA is useful.
    • ppa:git-core – Updates to the Git version control suite.
  • VR-Related – Of course I had to plug some of the PPA’s I maintain for the lab. Help maintaining these is always welcome!
    • ppa:isu-vrac/osg – Updated versions of OpenSceneGraph.
    • ppa:isu-vrac/vr-software – VR Juggler and its dependencies.