[OpenAFS] buildbot and packages

[Troy Benjegerdes]

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 <shadow@gmail.com> wrote:
> > On Mon, Sep 17, 2012 at 1:15 PM, Troy Benjegerdes <hozer@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