Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 9 Dec 2013 11:56:14 +0100
From: Waldemar Brodkorb <>
Subject: Re: Release test framework

Hi Rich,
Rich Felker wrote,

> One thing that's still missing that I had on the Roadmap for 0.9.15 is
> establishing a formal testing procedure for releasing. Basically what
> I have in mind is:
> For each arch:
> 	Assume the existence of a musl-cross compiler for it.
> 	Build musl and install to a prefix under the rest root.
> 	Build libc-test configured to use the new headers/libs.
> 	Create cpio archive containing:
> 		Newly built musl
> 		Newly built libc-test tree.
> 		Provided base system template containing:
> 			Busybox.
> 			Simple /etc tree.
> 			Minimal init script to run tests.
> 	Boot qemu using a provided kernel and the new initramfs.
> 	Save output of tests outside the qemu environment.
> 	Diff against expected results for comparison.
> Does this seem like a reasonable and useful test procedure? Is anyone
> willing to volunteer to write the scripts for it?

Looks like an interesting task. I programmed a prototype:
git clone
cd musl-test-framework; ./

You need toolchains preinstalled. You could for example use OpenADK
glibc toolchains from here:
Or modify to point to all toolchains via TCPATH/TCVENDOR.

It is tested with Qemu 1.7.0 (and required for microblaze support).

The support for microblaze is working, but I did not manage to get
the system automatically to reboot or powerdown. Any hints are

What do you think about it? 

best regards

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.