Package A's source code contains some undefined behaviour that gcc 4.4 tolerates. The distribution upgrades to gcc 5.1 and the build now breaks, but nobody notices because no new version of Package A has been uploaded and so no new build has been performed. Is your position that it was in compliance with the GPL before the gcc transition, and in violation afterwards?

They don't.

I mean a developer working at Canonical, trying to make a change to one of the packages they're preparing for distribution, has to have some way to answer the question "what version of gcc is being used to build this package". Whether that information is kept in the source tree, on their wiki, or on a post-it on the employee fridge - in any case, it's part of the source in the preferred form for making modifications, because it's, well, part of what the employees use to make modifications.

The distribution isn't rebuilt every cycle. If no new source release has been uploaded, the existing binary will be used for the next release.

I think that Matthew might be suggesting that not all packages are rebuilt with every release? A binary package might be compiled with GCC-4, then the distribution is upgraded to GCC-5, dropping GCC-4. If for some reason the package is not compatible with the new compiler, you would then be in a situation where the binary cannot be recreated from source without outside tools. Do you know if Canonical recompiles everything on each update to the toolchain?

Why would it be? Build and testing systems for something like a Linux distribution are far more complex systems than a simple script. In any case, there's no requirement in the GPL (or any other OSI-approved license AFAIK) to include components outside of the software itself to simplify building and installing. Of course, there are a variety of things like package managers that do simplify the process but there's no requirement in the GPL that it be straightforward to install from sources.