| 1 | autodebathenify is a cron job which runs on the builder account and |
| 2 | keeps the OpenAFS modules and modified packages under debathena/third |
| 3 | up to date when there are upstream changes. It relies on the |
| 4 | following: |
| 5 | |
| 6 | * builder@ATHENA.MIT.EDU has access to a local account named |
| 7 | debuildsvn on svn.mit.edu with read access to the athena |
| 8 | repository. |
| 9 | |
| 10 | * builder@ATHENA.MIT.EDU has write access to the canonical build |
| 11 | area and apt repository in the dev cell. |
| 12 | |
| 13 | * The builder account on the build machine has a copy of the signing |
| 14 | private key for the apt repository. |
| 15 | |
| 16 | The cron job will silently exit if it detects that it is already |
| 17 | running. If it fails for any other reason, it will send mail to |
| 18 | source-wash@mit.edu and touch a file named autodebathenify.suppress |
| 19 | which will prevent it from running again until manual intervention. |
| 20 | It is important to get autodebathenify running smoothly or the apt |
| 21 | repository will become out of date with respect to third-party |
| 22 | packages, which in turn will compromise the user experience. |
| 23 | |
| 24 | Even if you don't notice failure mail, it's good to check on the |
| 25 | status of autodebathenify from time to time. To do this, get tickets |
| 26 | as builder and ssh to linux-build-10 as builder. Run "ls -l logs" to |
| 27 | see what's been going on. A logfile with size around 48K indicates |
| 28 | that autodebathenify ran normally but didn't find any new work to do. |
| 29 | A logfile with size around 60 means that autodebathenify.suppress |
| 30 | exists and the cron job has stopped running. A longer logfile |
| 31 | indicates that autodebathenify attempted to build and upload a |
| 32 | package. |
| 33 | |
| 34 | Possible failure cases include: |
| 35 | |
| 36 | * One of the upstream apt repositories timed out during an "apt-get |
| 37 | update" of an sbuild chroot. If this happens, you can just remove |
| 38 | the autodebathenify.suppress file to get the cron job to start |
| 39 | running again. |
| 40 | |
| 41 | * autodebathenify tried to build an upstream version which already |
| 42 | exists. If this happens, the build will fail at upload time. If |
| 43 | this happens, there is a bug in the part of the debathenify-* |
| 44 | script which checks whether our apt repository already has the |
| 45 | expected version of the built package. |
| 46 | |
| 47 | * Debian and Ubuntu have .orig files with the same name but |
| 48 | different contexts for a particular third-party package. This has |
| 49 | only happened once, with bash (which is currently not configured |
| 50 | into autodebathenify for that reason). We do not have a general |
| 51 | mechanism for resolving such issues at this time. |
| 52 | |
| 53 | * The new upstream version of the package is sufficiently different |
| 54 | to cause our modifications to fail to apply, and our debathenify-* |
| 55 | script needs to be adapted appropriately. |
| 56 | |
| 57 | The cron job is run out of builder's home directory, but its canonical |
| 58 | source location is in debathena/scripts/build-server in this |
| 59 | repository, should it need to be modified. |
| 60 | |
| 61 | After several months of operation, LVM snapshots on the build server |
| 62 | will start to become slower and slower, as /etc/lvm/cache/.cache grows |
| 63 | in size. Turning off the cache entirely seems to cause schroot to |
| 64 | occasionally fail; the current solution is to rm /etc/lvm/cache/.cache |
| 65 | every so often. |
| 66 | |