The only package I’ve encountered so far that doesn’t play nicely in my accountable pbuilder environment is gcc-3.4. For some reason the scripts that inject the accountability information hang indefinitely and cause the build to fail. None of the other packages I’ve built so far (including gcc-3.3, interestingly) have this problem; they all work fine.

It wouldn’t be so bad if gcc-3.4 didn’t take over five hours to build, and pbuilder didn’t “helpfully” throw away the environment it created once it aborts the build. I’m giving it one more shot, and if that doesn’t work I’ll just build the packages in a conventional environment and add the extra information manually.

Once I get all that straightened out one way or the other, I can fire up my makeshift autobuilder and start feeding it packages while I’m home over Thanksgiving break. My goal is to get enough packages built to bootstrap more interesting packages in a fully accountable environment (i.e., built entirely using packages with accountability information) and prod them to see just how feasible this thing is.

One interesting phenomenon I’ve seen is that, since a source package can generate binary packages with widely differing uses, sometimes you wind up with packages whose accountability manifest includes some odd-looking entries. For example, you wouldn’t think that you need GTK installed to compile GCC, but somehow libgtk2.0-0 and friends appear as a transitive build dependency of gcc-3.4.

Woah. Looking at the .dsc file for gcc-3.4, libgtk2.0-dev is explicitly listed as a build dependency of gcc-3.4. That explains why GTK is showing up, but what part of GCC needs GTK around? Weird.

Time for bed. Here’s hoping gcc-3.4 has built successfully by the time I wake up.

3 Responses

  1. gcc-3.4 has 200 — that’s two hundred — packages that it build depends on, either directly or indirectly. It produces 32 packages of its own.

    I don’t know if this large number is the cause of the problem, but either way, this bodes poorly for checking accountability manifests in real-time, especially when you consider that one of gcc-3.4′s packages (libgcc1) is used by something in the minimal build environment. In other words, every package will be built using it, which means that at a depth of only two, every package will have over 200 packages to check!

    On the bright side, it looks like I caught the stalled pbuilder in time to copy all the necessary files out of it and manually inject the manifest into the packages, so at least I won’t need to recompile gcc-3.4 yet again.

  2. It’s the gcj AWT libraries’ fault. They’re implemented in terms of GTK, which is why gcc-3.4 build depends on it.

  3. Lesson #1: Never, never, never use IPC::Open2 if there’s a chance the process you’re writing to will start producing output before you’re done writing to it.

    Lesson #2: When signing, GPG will start producing output before you’ve finished writing to it.

Comments are closed.