On Thu, Dec 02, 2004 at 11:11:40PM +0100, Björn Stenberg wrote: > I noticed today that my testing script did not support the "New binary:" > status line in update_excuses.html. I'm a little puzzled as to exactly what it > means. > >From gleaning in update_out.py, I am guessing "New binary" means the package > now has binaries for an architecture it previously didn't support? For an architecture that previously did not have binaries in testing, yes. > I am also confused by the contents of update_output. When trying > evolution-data-server/mips, it failed with 14 packages becoming uninstallable: > * mips: evolution-data-server, evolution-data-server-dev, libebook-dev, > libebook8, libecal-dev, libecal6, libedata-book-dev, libedata-book1, > libedata-cal-dev, libedata-cal5, libedataserver-dev, libedataserver3, > libegroupwise-dev, libegroupwise6 > These are the binaries that are being added by evolution-data-server/mips. How > does installing a package make binaries from the very same package > uninstallable? Since these binaries were built against unstable after a number of new gnome 2.8 libs had gone in, they depend on libgnomevfs2-0 (>= 2.8.0), whereas the binaries for the other archs do not. If this dependency had existed across architectures, evolution-data-server would not be in testing right now, and would not even be considered a candidate by britney; however, arch-specific binaries for a version of a package that's already in testing are always candidates, and any per-arch dependencies will simply cause it to fail at a later step. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature