This is essentially ready, but I'm seeing a buildbot failure on the ticket branch I don't understand; the log is here.

I've removed datarel and testing_endToEnd from lsst_distrib, and now, after running lsstDoxygen, something tries to do a eups list that includes datarel, and that fails. I don't see the string "datarel" in lsstsw anywhere but repos.yaml, and my understanding is that that shouldn't be a problem. Frossie Economou, Joshua Hoblitt, any ideas?

What I suspect is happening is that lsst_build is [re]generating the same bxxxx number because the repo head refs haven't changed. create_xlinkdocs.sh is generating the b number independently of lsst_build and assumes the build id is monotonically incrementing. The obvious problem is that that the two programs don't agree on the build id but I don't yet understand the conditions that put it into this state.

A work around has been committed.

Thanks for the workaround fix. What package is create_xlinkdocs.sh in? It sounds like that's where the real fix needs to go, and I gather I need to address this before I test this ticket branch with buildbot again.

Nevermind; just saw that K-T had posted a link on HipChat to buildbot_scripts

So, the original problem here is that the buildbot scripts depend explicitly on datarel, assuming it's a top-level package whose Doxygen build depends on every other Doxygen build. So if we remove datarel, we're going to need another package that can fill that role, which should probably just be lsst_distrib (depending on how much of a Doxygen build we have to add to lsst_distrib to get this working). Or we'll need to make deeper changes to lsstDoxygen.

Joshua Hoblitt, is there any way I can get a sandbox to test out changes to buildbot_scripts, or would it be easiest if I just reassigned the rest of this issue to you?

Jim Bosch yes - I put something together for you tomorrow. Perhaps hipchat will let me authenticate by then so I can pass you credentials...

I'm taking a different approach to removing the block on DM-1766: just removing the dependency on ap from datarel (DM-2949), rather than removing datarel from CI (which is blocked by DM-2948). As such, I'm closing this as Won't Fix, and leaving it for the Data Access team to figure if and how they want to move ingest code from datarel later in DM-1674.