where are we/you going?

Denys Vlasenko vda.linux at googlemail.com
Sun Nov 25 03:44:47 UTC 2007


On Saturday 24 November 2007 02:51, Roberto A. Foglietta wrote:
> Denys Vlasenko wrote:
> > On Thursday 22 November 2007 01:14, saravanan chanemouganandam wrote:
> >> Hi,
> >>
> >> The rootfs "root_fs_arm.ext2.bz2" which I am testing was downloaded from
> >> the reference link
> >> http://dslinux.gits.kiev.ua/trunk/uClibc/docs/uclibc.org/toolchains.html
> >>. As I have some problem with toochain, I have started to test first
> >> using the existing rootfs built for arm the target which failed to work.
> >>
> >> Test with (init=/sbin/hello) "Hello world" statically linked using
> >> uclibc doesn't show any message whereas statically linked using glibc
> >> shows the message.  I wonder why it doesn't work well with uclibc. Is
> >> this problem due to the kernel-headers or uclibc config ?
> >
> > Also may be bad choice of ARM processor flavor, and uclibc code
> > ended up containing commands which are not supported by your processor.
> >
> > This is a quite typical cause of "my init doesn't run!" problem.
>
>   The following questions are the classical: where are we/you going?
>
>   The bug track system is feed with all the bugs or reading this ml is
> the only way to be acknowledged about each bug discovery?

Bug database is good for tracking issues, saving additional data points
about bugs, etc. Mailing list works better for bumping up bugs which
are not resolved and semms to be forgotten.

I find that with many projects it works best when I create bug entry in 
bugzilla AND post a report to ml.

However, not every time. This gcc bug is an example:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30354

It even contains a working patch, and I sent an email to their
ml several times, yet not reaction still.

>   Is there some kind of bug report sum which can help me to choose a
> stable version of busybox in order to go in production?

Take latest 1.7.x, but running testsuite and comparing the output
with testsuite of last busybox you used in production is a good idea.

> I am seeing bugs 
> in well known application like cut or tar,

As usual, report them.

For me, tar wasn't even capable to unpack linux kernel source tarball.
Now it can do that. I tested it by tar/untar cycle of Orcle install.
It survived.

I think adding testsuite entries for bugs you discover and fix
might help to ensure they do not reoccur, or at least easy to
automatically detect.

I just reran testsuite/runtest. Compared to 1.2.2, two more failures. :(
-PASS: pidof -o %PPID
+FAIL: pidof -o %PPID
-PASS: which-uses-default-path
+FAIL: which-uses-default-path

Will look into it.

> are there before and nobody 
> discover or they came out because the bb new era? In the last case is
> there any plan to stabilize bb?

Do you have a feeling that people who has write access to bbox svn
are unwilling to take patches?
--
vda



More information about the busybox mailing list