Computing

One interesting find I made while working with the Seneca students on Fedora ARM was that a loopback filesystem hosted on top of an NFS share can outperform the NFS share. Yes, it's counter-intuitive, because that would seem to introduce additional layers of processing, but I think it makes sense.

When using NFS, file metadata management is performed by NFS. When loopback-mounting a filesystem in a file hosted on NFS, the file metadata management takes place entirely on the local system -- NFS merely provides a data store. In this sense, it's not much different from iSCS, because the loopback filesystem can't be readily accessed by two separate hosts at once.

In fact, on a small ARM system such as an OpenRD-Client, loopback-ext3-on-NFS over GigE handily outperforms both Class 6 SD and a local USB-PATA drive.

Why not just use iSCSI? Well, for reasons I haven't yet determined, the Fedora iSCSI initiator doesn't work reliably on ARM-- under heavy load, it sends invalid opcodes to the target. This sounds like an alignment issue, but alignment fixups don't cure it. Investigation continues...

ARM processors power the digital mobile age. Billions are produced per year, ending up in the majority of cellphones as well as in e-book readers, plug computers, the OLPC XO 1.75, tablets, netbooks, intelligent RJ-45 network jacks, and even microSD cards.

The Fedora ARM Secondary Architecture project has done a great job of porting Fedora releases to ARM. To assist this initiative, this semester's Software Build and Release course at Seneca (SBR600) put together a new Koji build farm for the ARM architecture in preparation for using koji-shadow to follow the primary architectures. It's been a fascinating and challenging project -- working with cross-compilers, emulators, and hardware with much smaller configurations than standard PCs. A large amount of effort was spent benchmarking various configurations to determine optimal memory and storage arrangements and to compare emulated vs. hardware ARM performance to guide the configuration of the build farm.

So now we're at the end of the semester. Where do things stand?

• We have a working Koji build system, with two hardware builders plus emulated (VM) builders
• Since we're at the end of the semester, things will be quiet for the next week and a half, but then we've hired a graduate to work on this full-time (intros coming up shortly )

What's next? In May-June we expect to:

• set up FAS2 certs
• add 10+ hardware builders
• implement koji-shadow

The Fedora qemu-system-arm package provides pretty good ARM processor emulation, which can be used to run the Fedora ARM secondary architechture. This is an easy way to get started working with ARM -- for example, while waiting for your plugcomputer, beagleboard, or OLPC XO 1.75 to arrive

The previous wiki notes on using ARM with QEMU didn't cover using qemu-system-arm under libvirt management. This meant that you couldn't easily take advantage of libvirt benefits such as automatic network setup (with DHCP and NAT), the virt-manager GUI tool, guest autostart, or disconnection/reconnection to the console.

I've updated https://fedoraproject.org/wiki/Architectures/ARM/HowToQemu to include some basic notes on setting this up, and provided some files to simplify and speed up the process. Jump in and join Fedora-ARM, the water's nice!

mock is a Fedora package building tool. When invoked to build a specific package from a source RPM (which contains the package source plus a spec file), it creates a chroot environment, populates that environment with a very small set of base packages plus the build requirements specified in the spec file, and then attempts to build the package in that environment. This permits the build environment to be (somewhat) isolated from the host environment, so that a different set of build dependencies (tools, libraries, and headers) can be used for building. It's ideal for proving that the build requirements are correct, and it also permits you to build a large set of packages without installing a lot of build dependencies on the host system. It's also a highly automated and very convenient way to build

I've been experimenting with building for and on the ARM architecture. Fedora 12's mock package does not include a config file for ARM; here is a config file I've cobbled together as a starting point:

config_opts['root'] = 'fedora-12-arm'
config_opts['target_arch'] = 'armv5tel'

# The chroot_setup_cmd is usually 'groupinstall buildsys-build' but that hasn't been defined for ARM yet.
# Instead, the package list is specified here.
config_opts['chroot_setup_cmd'] = 'install bash bzip2 coreutils cpio diffutils fedora-release findutils gawk gcc gcc-c++ grep gzip info make patch redhat-rpm-config

rpm-build sed shadow-utils tar unzip util-linux-ng which bash curl cvs fedora-release gnupg make redhat-rpm-config rpm-build shadow-utils'
config_opts['dist'] = 'fc12'  # only useful for --resultdir variable subst

config_opts['yum.conf'] = """
[main]
cachedir=/var/cache/yum
debuglevel=1
reposdir=/dev/null
logfile=/var/log/yum.log
retries=20
obsoletes=1
gpgcheck=0
assumeyes=1

# repos

[fedora]
name=fedora
mirrorlist=http://mirrorlist.fedora-arm.wantstofly.org/?repo=fedora-12&arch=arm
failovermethod=priority

[updates-released]
name=updates
mirrorlist=http://mirrorlist.fedora-arm.wantstofly.org/?repo=updates-released-f12&arch=arm
failovermethod=priority
"""

This uses the existing fedora-arm repositories along with an explicit list of base packages for the mock environment. Ultimately, the buildsys-build package group will be specified in a special-purpose repository, but the explicit package list given here provides a good starting point.

Update: here's a link to this mock config file: http://cdot.senecac.on.ca/arm/fedora-12-arm.cfg

I've met my share of error dialogs through the years. Ones that say "Something bad has happened. Ok?" are annoying but understandable.

However, one in gpk-update-viewer, which I encountered yesterday, is a real head-scratcher:

This dialog sometimes appears when you try to close the gpk-update-viewer window while updating and it reads:

Cannot cancel running task

There are tasks that cannot be cancelled.

[Cancel]  [Quit]

Quite apart from the fact that this dialog shouldn't appear at all -- packagekit will continue the update in the background -- the two buttons appear to mean the same thing, both of which are (according to the dialog) impossible.

(bug 567135)

Update: Richard Hughes noted in the comments that this is fixed upstream

Alexander Larsson answered my Dear Lazyweb on finding a PID given a Window ID, to implement Richard Jones' View Source Button idea. I hacked up a tiny bash script to see what kind of info we could easily get about a window. Running that script and clicking on the Gnome calculator, I see:

$ show-source
Click on a window. Avoid clicking on a window border.
PID:             6272
Binary:          /usr/bin/gcalctool
RPM:             gcalctool-5.28.1-1.fc12.x86_64.rpm
SRPM:            gcalctool-5.28.1-1.fc12.src.rpm
Upstream URL:    http://directory.fsf.org/gcalctool.html
Fedora release:  12
Bugzilla search: https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&classification=Fedora&product=Fedora&component=gcalctool&version=12
PackageDB page:  https://admin.fedoraproject.org/pkgdb/packages/name/gcalctool
Transifex page:  (None)

There's a lot more that needs to be handled -- for example, clicking on a script window reports the interpreter instead of the script, clicking on a window border reports nothing, clicking on the window of a consolehelper'd app fails on access to /proc/$PID/exe, and clicking on a terminal window reports the terminal program instead of the character-mode app that is running (obviously).

All of these can be solved fairly easily, and the idea looks workable! As I noted in a commend on Richard's original post, it would be cool to make this View Source applet capable of taking the user to the pkgdb page, a source code browser (I'm thinking DXR, once we get it indexing all of Fedora), a bugzilla search, the upstream web page, or the translate.fedoraproject.org page; or, if the user chose, the applet could download and install the .src.rpm.