On 07/21/2016 12:33 AM, Andy Chu wrote: > expr is in pending, but ships on Android.
Yes, that is a significant issue I need to address. However, "issue" isn't necessarily "the real problem". The _problem_ is I have many things to do and a finite amount of time/energy to do them, but I'm working on it. Right now I'm trying to get grep to where android can use it, and get dd cleaned up and promoted out of pending. After that expr is near the top of the list. When you say "a thing in pending is broken" I tend to go "yes, that's why it's in pending". When you say "prioritize this thing in pending" what I prioritize is getting it out of pending. > I hope that was clear! I thought you were just busy, but I think you > never really understood what I was saying and what the tools do. I want to triage the testing directory, going through the existing tests command by command and making sure that each test is a good test for the command. (Are we passing the tests we have? Can TEST_HOST reasonably be applied? Are we testing everything the command does? Are we testing interesting failure paths?) My major todo item is getting tests requiring root access and/or a known host environment implemented and working under aboriginal linux images. (For "top" I may need a snapshotted /proc directory in a tarball, and /proc symlinks switching from directory to directory with somesort of synchronization mechanism. I probably have to create a pty, run top with an essentially infinite timeout, and feed a space through the pty to force a rescan, and also make sure the code is taking its timing info from the proc data not from calling gettimeofday() or similar so the test scriptisn't perturbing the output.) That can of worms is the kind of thing I'm worrying about when I look at the test suite. Can I make dummy interfaces in a qemu instance that ifconfig can attach ipv6 addresses to, and if so can I insulate it from kernel version skew if I upgrade the kernel version the test is running under?) You instead want to do a major redesign of the testing directory based on this week's coverity/valgrind variant, which is a different area entirely and not something I personally ever expect to use. Your redesign would put me further from _my_ goals, adding significant complexity I wouldn't use and thus wouldn't regression test and thus almost certainly would break if I changed anything. (Not just changes in the testing directory, you add significant complexity to a makefile that's otherwise mostly just a wrapper around shell scripts in scripts/*.sh to provide an expected user interface, the way "make test_sed" is just a wrapper around "scripts/test.sh sed". With your patch, the makefile seems to be the ONLY way to call some of the new functionality, and/or your wrappers call the makefile instead of the other way around.) > If there were any parts of my messages that weren't clear, I'm happy to > clarify. I lost about 4 weeks in the past 2 months to $DAYJOB melting, and it's entirely possible I'll be spending 6 months in San Diego working an unrelated contract until they get their financial house in order. More recently the Con Crud I picked up at Texas Linuxfest seems to have morphed into tonsilitis (which is disconcertingly like strangling except my airway isn't blocked, and I keep wanting a 6 hour nap in the middle of the day). I'm working as fast as I can, but I don't necessarily have the same priorities you do. > Andy Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
