Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOb3iughuEJ0BGXf5NhfOwPFt8hed9WBQNyUU0YVtTG=n+=G0g@mail.gmail.com>
Date: Wed, 4 Dec 2013 13:51:42 +0800
From: 邓尧 <torshie@...il.com>
To: musl@...ts.openwall.com
Subject: Re: Release test framework

If busybox is used, the test framework itself would depend  on musl-libc,
which means test test framework would depend on the test subject. In
theory, it's a bad bad idea.

0.02$


On Wed, Dec 4, 2013 at 6:11 AM, Rich Felker <dalias@...ifal.cx> 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 libc.so.
>                 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?
>
> Rich
>

Content of type "text/html" skipped

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.