the tests are not ready to be run on the buildslaves. it's been working toward that point, but not yet.
On Tue, Sep 18, 2012 at 12:08 AM, Troy Benjegerdes <ho...@hozed.org> wrote: > Nope, Debian x86-64 > > Any chance the buildbots can be easily modified to run make check/make tests? > > I'm really curious what debian ppc32/ppc64 will do. I have an arm build, but > no fuse kernel module (debian on an sdcard on an android tablet). > > On Mon, Sep 17, 2012 at 11:39:55PM -0400, Derrick Brashear wrote: >> So. Were you perchance using it on a Mac? Probably a 64 bit Intel mac? >> >> http://gerrit.openafs.org/#change,8132 >> >> As nearly as I can tell, this is a very specific problem. The code is fine. >> The >> circumstances of building afsd.fuse meant it was collateral damage when we >> started using roken, but only on MacOS, and probably only for non-32 >> bit pointers, >> because MacOS does something odd with dirent.h >> >> On Mon, Sep 17, 2012 at 1:20 PM, Derrick Brashear <sha...@gmail.com> wrote: >> > On Mon, Sep 17, 2012 at 1:15 PM, Troy Benjegerdes <ho...@hozed.org> wrote: >> >> I'm looking to get all the low-hanging fruit with unskilled testing. >> >> Particularly with regressions like this: >> >> >> >> hozer@six:~/src/openafs-fuse-git/tests/fuse$ >> >> /home/hozer/src/openafs-fuse-git/tests/fuse/../../src/afsd/afsd.fuse >> >> -dynroot -fakestat -d -confdir >> >> /home/hozer/src/openafs-fuse-git/tests/fuse/conf -cachedir >> >> /home/hozer/src/openafs-fuse-git/tests/fuse/vcache -mountdir >> >> /home/hozer/src/openafs-fuse-git/tests/fuse/mntdir >> >> FUSE library version: 2.8.6 >> >> nullpath_ok: 0 >> >> unique: 1, opcode: INIT (26), nodeid: 0, insize: 56 >> >> INIT: 7.17 >> >> flags=0x0000047b >> >> max_readahead=0x00020000 >> >> Starting AFS cache scan...found 0 non-empty cache files (0%). >> >> afsd: All AFS daemons started. >> >> Segmentation fault >> >> >> >> >> >> I am pretty sure this is related to the work Simon is doing on Libtool, >> >> and there's a 90% probability it's a 30-second 'aha', followed by a two >> >> line fix, and we're back to working again. >> >> >> > >> > I'd bet not. However.... >> > >> >> The code is so complicated it will take me half a day to track down what >> >> that two line fix is, or work in my own isolated fork and not get updates >> >> as quickly. That unskilled smoke testing and/or automated runs gets a LOT >> >> of mileage. >> > >> > Not really. Build with debugging and get a real backtrace. That said, >> > since fuse is not *required* >> > functionality in a build, yes, it's undertested. This is why we've >> > generally avoided code which doesn't >> > always build. Or, at least tried to. >> > >> >> It also gives people who want to learn about the codebase something simple >> >> and meaningful they can do, instead of waiting around for someone else to >> >> come up with a test plan. >> > >> >> >> >> On Mon, Sep 17, 2012 at 11:25:36AM -0500, David Boyes wrote: >> >>> > How about an effort to get nightly builds of master available on as >> >>> > many >> >>> > platforms as possible, and getting thousands of bored college students >> >>> > to >> >>> > download, install, and test them? >> >>> >> >>> I think that's still overly optimistic. There's a lot of moving parts >> >>> here; you just can't just install a package and have it do something >> >>> useful. You need to have a lot of surrounding infrastructure that >> >>> involves real control of a fair amount of stuff that random college >> >>> students won't have. 'make check' on a single machine will never give >> >>> you useful testing results other than to find packaging or "smoke test" >> >>> errors, which aren't all that helpful overall. >> >>> >> >>> > Wouldn't that massive crowsourced testing effort be worth the time of a >> >>> > single developer to make sure *some* sort of package, even if it's >> >>> > half- >> >>> > assed, gets distributed? I can't think of much of anything else that >> >>> > has a >> >>> > bigger resource multiplation factor than a 'one click install', along >> >>> > with some >> >>> > defaults to use a 'test.openafs.org' cell. >> >>> >> >>> As others have commented, unskilled testing performed without a detailed >> >>> test plan on software systems this complex is probably less helpful than >> >>> might otherwise appear. GIGO applies here. A uncoordinated test process >> >>> is unlikely to produce anything useful in that there have to be a >> >>> sequence of coordinated tests, replacing one component at a time in a >> >>> known order. I can't see how crowdsourcing would help here. >> >>> _______________________________________________ >> >>> OpenAFS-info mailing list >> >>> OpenAFS-info@openafs.org >> >>> https://lists.openafs.org/mailman/listinfo/openafs-info >> >> _______________________________________________ >> >> OpenAFS-info mailing list >> >> OpenAFS-info@openafs.org >> >> https://lists.openafs.org/mailman/listinfo/openafs-info >> >> >> > >> > >> > >> > -- >> > Derrick >> >> >> >> -- >> Derrick >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info -- Derrick _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
