Codehelp blog

Embedded systems (especially bootloaders) need serial connections but many laptops and modern desktops simply do away with the serial port altogether. Up until now, I've kept my previous desktop machine around (which happens to also have a parallel port so acts as the home network print server because I don't have a USB printer either) and then connect to minicom over SSH.
Now, yes, I can configure networking over USB once the device is installed but to actually fix installation problems, I need serial on my other machines. I've got a USB to serial converter, turns out to be a Prolific 2303 chipset (it's the basic one with a cable from Maplins) which is quite well supported.

Now the weird stuff.

My powerpc laptop sees the Prolific chipset and configures a USB device that, initially, minicom complains about - but if I set the port from 'dmesg' (/dev/ttyUSB0) in minicom -s, it works. Well, almost. I can see the output of the device but no keyboard strokes are passed on to the board which means it's almost workable whilst still being completely useless.
My problematic HP laptop accepts the Prolific chipset but does not configure a USB device node. Without a device node, minicom just fails.
Bah.
This HP laptop is still causing me grief. USB seems to fail after hibernation and only works at all if irqfixup is added to the kernel boot parameters. With irqfixup, the laptop randomly hangs. I almost need to setup parallel configs in grub of "run USB but don't hibernate" and "run for more than 1 hour" as mutually exclusive. Oh, and the external monitor connection used for presentations is only seen if the projector is connected during a reboot of the HP laptop.
Bah x 3.

Separating out keyring and rootfs support

 emdebian-archive-keyring - GnuPG archive keys for the emdebian repository

 emdebian-rootfs - emdebian root filesystem support

 emdebian-tools - emdebian crossbuilding tool set

 libemdebian-tools-perl - emdebian support library

Finally got to test a request from some months ago to create a separate archive keyring for those people who just want to use the toolchains.
I also took the chance to split out the scripts to build root filesystems from the scripts that build the packages for the repository. The Emdebian::Tools module was best split out too, it's needed for emdebian-rootfs and emdebian-tools.
Not sure when this is going to happen for real, it's only a test branch right now.
(browse SVN). It tests OK, so far and if other things check out, this could be 0.8.4 (in Emdebian), then whilst the same code badged as 0.9.0 spends time in the NEW queue so that I can upload 0.8.5 etc. to Emdebian, followed by 0.9.1 with the changes from 0.8.5 onwards.

TDeb changes from Fosdem

In the main trunk (0.8.3), I've updated a few parts of em_installtdeb but I haven't made much progress on whether TDebs should be Architecture: all or Architecture: any.

1. A big endian .mo file from powerpc works fine on little endian amd64.


2. msgfmt --alignment does not seem to do what I expected (but then I'm not entirely sure what I did expect).


3. I can't find anyone cross-building .mo files - maybe it's my Google skills but if it was essential, I find it hard to think that all those cross-built systems are doing something different to just msgfmt -o $@ $.

Although an interim release, there are a number of new features in 0.8.2 that are worth noting.

1. emrecent - possible candidate for a rename to emdput, this script started off just as a review tool for recent builds (hence the current name). Finds recent .changes files in the Emdebian working directory, collates them, provides a viewer for the debc -a $ARCHcontents using whiptail or zenity along with error logging. If the default zenity frontend is installed, you can still select to use whiptail (e.g. when over an SSH connection) using the -w option to emrecent. Further checks are run using the second script:


2. emdebcheck - a local Emdebian version of the debcheck that runs on the Debian archive using edos-debcheck to highlight non-installable packages before an upload breaks the archive. This isn't such a problem in Debian but Emdebian needs to build installer images and similar tools from packages in unstable so an installability check is very useful. Certain packages are expected to be non-installable due to dependencies that are removed in Emdebian so emrecent supports a --skip option to omit the emdebcheck run for such builds.


3. emsource --status now reports errors logged by emrecent or emdebcheck.


4. Unpacking support in emsandbox - EXPERIMENTAL!. debootstrap --foreign puts a higher-than-necessary burden on the host device when running the default --second-stage - not just in CPU workload but in the amount of free space required to copy and unpack all the .deb files. The original debootstrap tarball contains the downloaded .deb archives and only a few packages are actually unpacked manually. Unpacking support in emsandbox adds a handler using dpkg to unpack ALL .deb files in .$BUILDPLACE/var/cache/apt/archives/ using dpkg -e and dpkg -x, creates a suitable status file for dpkg and removes the .deb packages for a smaller tarball. The result is (almost) a foreign filesystem image that can be copied directly onto the host device. The remaining tasks are only:
   • /sbin/ldconfig
   • /usr/bin/dpkg --configure -a
   . Depending on how well this works in real situations, unwrap could become the default handler for debootstrap --second-stage --foreign in emdebian-tools. Unpack support is enabled via the debootstrap suite scripts which define the package set, the first_stage_install and the (much reduced) second_stage, replacing the sequence of install commands with a single function provided by emdebian-tools. See /usr/lib/emdebian-tools/emdebian.gpe for an example.

In common with all previous interim Emdebian releases, 0.8.2 has been uploaded to the Emdebian tools repository already added to your apt sources when installing emdebian-tools so apt will be able to upgrade seamlessly.
(0.8.0 introduced a check in emsetup to ensure that the latest version has actually been installed.)
Once features have stabilised (probably after testing at Fosdem), I'll upload 0.9.0 to Debian unstable, as usual, or maybe one or two more interim releases to Emdebian.

I'm trying to work out how to monitor a remote script - in this case a mass build script. The script itself is trivial - a simple for loop in perl. It calls a script from emdebian-tools that calls a variety of other scripts and programs.
What's the best way for me to monitor that script from another machine on the network?
Yes, 'ps wax' is usable but not particularly friendly - the script has to work its way through a list of packages that need building. I want to know which package is being built at the time and the 'ps' output does show this information but only if you recognise parts of the build process for particular packages.
I thought about getting the script to output the current package name to some file in /var/ but that seems a bit of a hack (it's a userspace command and should not need to use sudo or require particular permission setups). Sending email is overkill. A file in /tmp/ is possible, true, but that means adapting the script itself. I'd like a solution that could work with (almost) any package, including binaries, without altering the source code. I've also thought of running the script within screen but then when the machine is in the middle of a compilation, it isn't easy to work out which package is actually being built just from the gcc output, plus there is the continual problem that screen doesn't support scrollback.
I have a feeling this is a potential reinventing the wheel problem so I'm looking for ideas.

Update:

The closest process output I can use is ps wfh which at least collates all the processes started by the top level script into one tree. I've worked out why the info I wanted was not being shown - the call from perl was exec() not system(). Doh! Ne'er mind. ps wfh will be enough for what I need - but I will need to adapt the wrapper after all. Thanks to all those who posted comments.