Category Archives: Slimlogic

Chromebook Ubuntu 13.04 Touchpad Fix

This one is nice and simple, to fix the sensitivity of the touchpad back to what you were used to under ChromeOS.

xinput set-prop 7 "Synaptics Finger" 5 5 256

If I could work out where xfce4 keeps its autostart files then I could get this to run at startup.

Chromebook

I blame ‘hrw’ for showing off his Chromebook at Connect, but when I returned to the UK I obtained one.

Running chrome itself is of little interest to me, much more interested in using it as a laptop. So first of all I used ChrUbuntu to get a 12.04 on it. Then I followed hrw’s instructions how to upgrade to 13.04. I messed it up a couple of times but eventually succeeded.

I will say two tips before rebooting, make sure you have ssh server running, and make sure you have a /etc/X11/xorg.conf working. Also if you are doing internal its really helpful to already have a valid install on external SD card you can boot in emergency.

It seems at the moment armsoc Xorg driver prevents suspend by crashing on VT change and then forcing a VT change when it restarts. So if you actually want to use the device you might need to switch to fbdev driver for now!

Very nice little device, I hope more of this sort of low power laptop appear to replace the now killed netbook market.

 

Synaptic Touchpad Configuration LXDE

This is probably not the cleanest or the neatest way to do this but until LXDE gets a synaptic applet of its own its one way to configure your touchpad on login so it functions how you want it.

First create a file $HOME/bin/touchpad.sh with you configuration set using synclient.

#! /bin/sh

synclient TapButton1=1
synclient TapButton2=3
synclient TapButton3=2

And make it executable chmod 755 $HOME/bin/touchpad.sh

Now create a file to autostart this on login $HOME/.config/autostart/touchpad.desktop.

[Desktop Entry]
Name=Touchpad
GenericName=Touchpad Config
Comment=Personal Touchpad Settings
Exec=/home/someone/bin/touchpad.sh
Terminal=false
Type=Application
Icon=xterm
Categories=X11;
StartupNotify=false

This is probably not standards compliant ;-).

Now if you logout and login your touchpad should be configured correctly. If you copied my setting one finger tap for left button, two finger tap for right button, three finger tap for middle button.

Crazy Emacsen

Stole most of this from a blog.

But crazy emacsen for setting base directory for kernel compiles and a correct for me compile command.

((nil . (
    (eval . (setq default-directory (locate-dominating-file
        buffer-file-name ".dir-locals.el")
        )
    )
    (compile-command . "make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j4 uImage")
)))

Chrooting for Droid

I bet we have all found the issue that building random BSP versions of Android require old versions of Ubuntu which we long ago upgraded or don’t run at all.

This is easilly fixed with a few tools which are available on most distros these days, I happen to be using Fedora 18(ish) but similar should work on any distro.

Firstly install schroot, debootstrap and dpkg.

yum install schroot debootstrap dpkg

Make somewhere to install our chroots

mkdir /chroot/lucid-64

Now install the lucid 64bit into this, I am running from 64bit and want 64bit so its all easy.

debootstrap lucid /chroot/lucid-64 http://archive.ubuntu.com/ubuntu

Now create the file /etc/schroot/chroot.d/lucid-64.conf

[lucid-64]
type=directory
directory=/chroot/lucid-64
description="Lucid 64bit for Android"
users=YOUR_USER
root-users=YOUR_USER
aliases=default

If you need to import some filesystems into you chroot automatically then check the file /etc/schroot/default/fstab, home is already included but you may wish to import things like your build directory if it is not in home.

Now run schroot to enter your chroot and use su to get to root user.

Final task is to install a few packages needed for a build, your may need different packages, this is just a list needed for random BSP.

apt-get install git-core flex bison gperf libesd0-dev zip gawk ant zlib1g-dev build-essential tofrodos bc
apt-get install lib32readline5-dev libstdc++6 lib32z1 lib32z1-dev lib32ncurses5 lib32bz2-1.0 lib32asound2 g++-multilib libx11-dev libncurses5-dev uboot-mkimage

One thing to watch out is not mixing repo/git operation inside and outside the chroot as there are likely different versions of git and it gets a little upset.

OpenVPN Reliability

It has always puzzled me why OpenVPN is much more reliable run by hand from command line than via NetworkManager. I think I have finally discovered the cause thanks to a Ubuntu bug report on Launchpad.

Launchpad Bug

This links to the official OpenVPN bug filed

OpenVPN Bug

I have applied the workaround in the launchpad ticket to my Fedora 18(ish) system and it certainly seems to have improved the situation a lot.

Lucid on Omapzoom2

So Ive been doing some work getting a Ubuntu Lucid beta image running on the zoom2 machine. This is basically the same image as what runs on a beagle slightly modded for zoom2 (serial is different port). Running the Netbook Remix version. I have two external keyboards and a mouse plugged in via usb hub and of course the debug board for networking. This is a photo so you can see it is really running 🙂

I used the kernel image that we use for Ã…ngström images as Ubuntu doesn’t have a zoom2 kernel yet.

And this is a screen shot taken on the zoom2 (you’ll just have to believe me).

Omap3 Zoom2 Ångström

I thought it was about time to give an update on Ångström support of the Omap3 Zoom2 device.

Thanks to TIs donation I have been able to work on support for this device. I have also been able due to the power of OE build on the Ångström communities support of omap3 chips in general. Anyway a Gnome rootfs is running nicely on the device.

Here is the login screen.

And after logging in the desktop running.

This as you can see is with the zoom2 running free of its debug board. This does mean with current OE recipes there is no networking but we are hoping to have that fixed soon now!

OpenEmbedded/Ångstöm New Package Workflow (eggdbus)

This article is to detail the typical workflow I use when I am adding a new application recipe to OpenEmbedded from scratch. In this case it will be the gobject dbus binding called eggdbus.

During this article reference to the OE wiki especially the styleguide for new recipes is highly recommended.

The first step is to locate the software we are going to add and the version number of that software. In this case it the software is called eggdbus and it is version 0.6. Also at this stage check the license of the software in this case GPLv2.

Create a directory in the metadata to hold the new software.

mkdir recipes/eggdbus

Use an editor to create the recipe file for the new application. The general form of the filename is application_version.bb so in this case edit.

vi recipes/eggdbus/eggdbus_0.6.bb

Fill the beginning of the recipe with the informational fields.

DESCRIPTION = "gobject dbus binding"
HOMEPAGE = "http://cgit.freedesktop.org/~david/eggdbus"
LICENSE = "GPLv2"

The next step is to locate the download URL for the new recipe. In this case eggdbus is hosted in a sourceforge project so the download URL is.

http://cgit.freedesktop.org/~david/eggdbus/snapshot/eggdbus-0.6.tar.bz2

OpenEmbedded creates a variable ${PV} from the filename of the recipe. It is recommended to use this in the SRC_URI as it saves typing when later upgrading to later versions of the software. It also creates a ${PN} variable from the package name.

SRC_URI = "http://cgit.freedesktop.org/~david/${PN}/snapshot/${PN}-${PV}.tar.bz2"

At this stage there is enough recipe to attempt a download and check that there are no mistakes so far.

bitbake eggdbus

This build is expected to fail as the OE metadata does not yet have the MD5/SHA256 checksums for the download yet.

NOTE: Missing checksum
ERROR: eggdbus-0.6: http://cgit.freedesktop.org/~david/eggdbus/snapshot/eggdbus-0.6.tar.bz2 has no checksum defined, cannot check archive integrity
ERROR: Error in executing: /home/dp/openembedded/org.openembedded.dev/recipes/eggdbus/eggdbus_0.6.bb
ERROR: Exception: Message:1
ERROR: Printing the environment of the function
ERROR: Error in executing: /home/dp/openembedded/org.openembedded.dev/recipes/eggdbus/eggdbus_0.6.bb
ERROR: Exception:
Message:1
ERROR: Printing the environment of the function
ERROR: Build of /home/dp/openembedded/org.openembedded.dev/recipes/eggdbus/eggdbus_0.6.bb do_fetch failed

OE helpfully generates the checksums it expected to see so these can be added to the meta data easilly. The cat just appends the new checksum to the end of the file. The next python command then calls a script to sort the checksums into the recommended format.

cat tmp/checksums.ini >>~/oe/org.openembedded.dev/conf/checksums.ini
python contrib/source-checker/oe-checksums-sorter.py -i conf/checksums.ini

To check this worked then re-issue the bitbake command.

bitbake eggdbus

In this case the command will succeed but builds no useful package. Depending on the application it will probably fail. This is not a problem at this stage as it is still work in progress and debugging these failures is what gives the information for the rest of the recipe.

At this stage the contents of the tarball file can be checked. The eggdbus tarball unpacks to a directory which is called eggdbus-0.6 which is what OE has already selected by default so we dont need to overide the default ${S} setting.

Eggdbus is an autotools using library so we tell OE to use its built in autotools support. If it is a well written autoconf then OE generates configure/compile/install tasks which work without modification.

inherit autotools

We can now try a build again to see if it will just build(tm).

In this case it doesnt because of gtk-doc.make. We currently dont really support this in OE anyway so we shall attempt to patch out this part.

cd tmp/work/armv7a-angstrom-linux-gnueabi/eggdbus-0.6-r0/eggdbus-0.6/
quilt new gtk-doc.patch
quilt add docs/eggdbus/Makefile.am docs/tests/Makefile.am

Edit the two Makefile.am and remove the reference to gtk-doc.make. Then generate the patch.

quilt refresh

The patches/gtk-doc.patch is now our patch. We need to copy it into our OE repo and add it to the SRC_URI.

mkdir recipes/eggdbus/files/
mv patches/gtk-doc.patch recipes/eggdbus/files/

And edit the eggdbus_0.6.bb to add the new patch to the SRC_URI.


SRC_URI = "http://cgit.freedesktop.org/~david/${PN}/snapshot/${PN}-${PV}.tar.bz2 \
file://gtk-doc.patch;patch=1 \
"

Now we attempt to build again.


bitbake eggdbus -c clean
bitbake eggdbus

This time the build fails inside the code stage, if the error is examined it will show that the build is trying to run a built program on the host. This obvously won’t work in cross compile situations so the program needs to be compiled for host.

This means a native version of the package is created. This used to mean a seperate .bb file but thanks to BBCLASSEXTEND it can be done in one file. This also means SRC_URI must be altered to use ${BPN} (Base Package Name) which is a version with -native/-sdk stipped from the end if present. So the following is changed/added to .bb file.


SRC_URI = "http://cgit.freedesktop.org/~david/${BPN}/snapshot/${BPN}-${PV}.tar.bz2 \
file://gtk-doc.patch;patch=1 \
"


BBCLASSEXTEND = "native"

On attempting to build this new native file it failed because it tries to use docbook to generate man pages. We dont really need them so disable them.


EXTRA_OECONF = " --disable-man-pages --disable-gtk-doc-html "

Now a rebuilt of eggdbus-native succeeds and host versions of the tools needed are available in the staging directory. Now some more changes are needed to the source. In the Makefile.am the programs we just built are referenced using the source directory but the ones in staging should be used so another patch to the Makefile.am files is produced. This patch should apply to the native version so more changes to recipe are needed.


BASE_SRC_URI = "http://cgit.freedesktop.org/~david/${BPN}/snapshot/${BPN}-${PV}.tar.bz2 \
file://gtk-doc.patch;patch=1 \
"

SRC_URI = "${BASE_SRC_URI} \
file://marshal.patch;patch=1 \
"

SRC_URI_virtclass-native = "${BASE_SRC_URI}"

Now the eggdbus recipe is built.


bitbake eggdbus -c clean
bitbake eggdbus

This time the build succeeds, but one thing that isnt done yet is to tell OE what this recipe depends on. The trick used to do this is to examine the control file in the .ipk and see what is depended on.

For this recipe it is quite clear and dependencies on dbus glib. So a final change to the recipe to add dependencies.


DEPENDS = "dbus glib-2.0"

All these steps give up a complete recipe that reads as follows.


DESCRIPTION = "gobject dbus binding"
HOMEPAGE = "http://cgit.freedesktop.org/~david/eggdbus"
LICENSE = "GPLv2"

DEPENDS = "dbus glib-2.0"

BASE_SRC_URI = "http://cgit.freedesktop.org/~david/${BPN}/snapshot/${BPN}-${PV}.tar.bz2 \
file://gtk-doc.patch;patch=1 \
"

SRC_URI = "${BASE_SRC_URI} \
file://marshal.patch;patch=1 \
"

SRC_URI_virtclass-native = "${BASE_SRC_URI}"

inherit autotools

EXTRA_OECONF = " --disable-man-pages --disable-gtk-doc-html "

BBCLASSEXTEND = "native"

OpenEmbedded/Ångstöm New Package Workflow (eyeOS)

This article is to detail the typical workflow I use when I am adding a new application recipe to OpenEmbedded from scratch. In this case it will be the open source cloud computing application called eyeos.

During this article reference to the OE wiki especially the styleguide for new recipes is highly recommended.

The first step is to locate the software we are going to add and the version number of that software. In this case it the software is called eyeos and it is version 1.8.7.1. Also at this stage check the license of the software in this case AGPL3.

Create a directory in the metadata to hold the new software.

mkdir recipes/eyeos

Use an editor to create the recipe file for the new application. The general form of the filename is application_version.bb so in this case edit.

vi recipes/eyeos/eyeos_1.8.7.1.bb

Fill the beginning of the recipe with the informational fields.

DESCRIPTION = "The Open Source Clouds Web Desktop"
HOMEPAGE = "http://eyeos.org/"
LICENSE = "AGPL3"

The next step is to locate the download URL for the new recipe. In this case eyeos is hosted in a sourceforge project so the download URL is.

http://sourceforge.net/projects/eyeos/files/eyeos/1.8.7.1/eyeOS_1.8.7.1.zip/download

OpenEmbedded actually has sourceforge mirror handling build in. So when the SRC_URI is constructed for the reciped a shortcut can be taken. OpenEmbedded also creates a variable ${PV} from the filename of the recipe. It is recommended to use this in the SRC_URI as it saves typing when later upgrading to later versions of the software. It also creates a ${PN} variable from the package name. But in this case this is not used as it differs in case in the URL.

SRC_URI = "${SOURCEFORGE_MIRROR}/eyeos/eyeOS_${PV}.zip"

At this stage there is enough recipe to attempt a download and check that there are no mistakes so far.

bitbake eyeos

This build is expected to fail as the OE metadata does not yet have the MD5/SHA256 checksums for the download yet.

NOTE: Missing checksum
ERROR: eyeos-1.8.7.1: http://downloads.sourceforge.net/eyeos/eyeOS_1.8.7.1.zip has no checksum defined, cannot check archive integrity
ERROR: Error in executing: /home/graeme/openembedded/org.openembedded.dev/recipes/eyeos/eyeos_1.8.7.1.bb
ERROR: Exception: Message:1
ERROR: Printing the environment of the function
ERROR: Error in executing: /home/graeme/openembedded/org.openembedded.dev/recipes/eyeos/eyeos_1.8.7.1.bb
ERROR: Exception: Message:1
ERROR: Printing the environment of the function
ERROR: Build of /home/graeme/openembedded/org.openembedded.dev/recipes/eyeos/eyeos_1.8.7.1.bb do_fetch failed
ERROR: Task 2 (/home/graeme/openembedded/org.openembedded.dev/recipes/eyeos/eyeos_1.8.7.1.bb, do_fetch) failed
NOTE: Tasks Summary: Attempted 445 tasks of which 444 didn't need to be rerun and 1 failed.
ERROR: '/home/graeme/openembedded/org.openembedded.dev/recipes/eyeos/eyeos_1.8.7.1.bb' failed

OE helpfully generates the checksums it expected to see so these can be added to the meta data easilly. The cat just appends the new checksum to the end of the file. The next python command then calls a script to sort the checksums into the recommended format.

cat tmp/checksums.ini >>~/oe/org.openembedded.dev/conf/checksums.ini
python contrib/source-checker/oe-checksums-sorter.py -i conf/checksums.ini

To check this worked then re-issue the bitbake command.

bitbake eyeos

In this case the command will succeed but builds no useful package. Depending on the application it will probably fail. This is not a problem at this stage as it is still work in progress and debugging these failures is what gives the information for the rest of the recipe.

At this stage the contents of the zip file can be checked. The eyeos zip unpacks to a directory which is called eyeOS which is different from OEs guessed at directory of eyeos-1.8.7.1 so the recipe needs updated to tell OE the real directory.

S = "${WORKDIR}/eyeOS"

Being a web application eyeOS doesnt have Makefile or autotools based installation so the compile/install stages will have to be hand written for this recipe.

The eyeOS installation is really simple from the OE point of view.

do_install() {
    install -d ${D}/www/pages/eyeos
    cp -r ${S}/* ${D}/www/pages/eyeos
}

There are two final things to do now before the recipe is finished. OE needs to be told which directories to package. It has some built in defaults like /bin /usr/bin /lib /usr/lib but our eyeOS install is outside these areas. We also need to tell OE that there is no CPU dependant code in the packages this recipe generates.

PACKAGE_ARCH = "all"
FILES_${PN} += "/www/pages/eyeos"

All these steps give up a complete recipe that reads as follows.

DESCRIPTION = "The Open Source Clouds Web Desktop"
HOMEPAGE = "http://eyeos.org/"
LICENSE = "AGPL3"

SRC_URI = "${SOURCEFORGE_MIRROR}/eyeos/eyeOS_${PV}.zip"

S = "${WORKDIR}/eyeOS"

do_install() {
    install -d ${D}/www/pages/eyeos
    cp -r ${S}/* ${D}/www/pages/eyeos
}

PACKAGE_ARCH = "all"
FILES_${PN} += "/www/pages/eyeos"

So the final stage the final packages can be built fromt the recipe. First a clean to make sure anything worked on is gone then a build.

bitbake eyeos -c clean
bitbake eyeos

The package produced from this recipe is now ready to be installed on target for testing.