=== jrgifford_ is now known as jrgifford
[03:19] <micahg> RAOF: can you reject libxkbfile from precise-proposed?
[03:20] <RAOF> Can, and have.
[03:20] <micahg> thanks
[03:20]  * micahg forgot a slash in the changelog :-/
[03:55] <pitti> IOError: [Errno 28] No space left on device
[03:55] <pitti> ^ on ddebs.ubuntu.com
[03:55] <pitti> argh
[03:56] <pitti> I think at this point I rather sacrifice natty than losing quantal ddebs
[03:56] <infinity> Yeah, natty will EOL "soon" anyway.
[03:56] <infinity> FSVO soon.
[03:56] <pitti> at least it's a rather uninteresting target to still fix crashes for
[04:01] <micahg> umm, what about removing the dbgsym ddebs?
[04:01] <infinity> As opposed to...?
[04:01] <micahg> removing natty
[04:01] <infinity> All the ddebs are dbgsym ddebs, I'm a bit confused. :P
[04:02] <micahg> oh, hrm, sorry :(
[04:03] <micahg> for some reason I thought there were duplicates
[04:03] <micahg> I meant dbg-dbgsym
[04:03] <micahg> but those probably don't exist
[04:04] <infinity> I think pkg-create-dbgsym tries to detect that scenario and do something clever, but I forget what now. :P
[04:04] <micahg> lack of sleep catching up with me, time for a break :)
[04:06] <pitti> micahg: yes, pkg-create-dbgsym doesn't generate -dbgsyms for -dbg packages
[04:06] <pitti> nor for any package which doesn't have an ELF file with a debug symbol section
[04:07] <infinity> pitti: You do still get duplication between -dbg.deb and -dbgsym.ddeb though, right?
[04:07] <pitti> yes
[04:08] <infinity> pitti: Since they share the same package namespace, couldn't we cleverly detect that situation and make -dbgsym.ddeb an empty package that depends on -dbg.deb?
[04:08] <pitti> infinity: we certainly could; we even detect that and add a Conflicts: to the -dbg package
[04:08] <pitti> infinity: we had a spec a while ago to get rid of all -dbg packages to reduce the size of the main archive
[04:08] <pitti> but it never got implemented
[04:09] <pitti> so I guess we could do it that way around
[04:09] <infinity> Sounds like a lot of unnecessary delta from Debian.
[04:09] <infinity> Until someone can convince them to go the ddeb route.
[04:09] <infinity> (which would be nice)
[04:09] <pitti> nah, not by modifying the source obviously :)
[04:09] <infinity> Oh, just by silently dropping them on the floor at upload time?
[04:09] <pitti> more like the pkgbinarymangler approach
[04:10] <infinity> That would mean the -dbg packages better all be nothing but detached symbols.  I know, in the past, some actually contained Useful Things.
[04:10] <infinity> (debug utilities, etc)
[04:10] <pitti> but I guess your way around makes more sense then
[04:11] <infinity> Well, the only problem with mine is that it makes apport-retrace need to be even smarter, when it's fetching old ddebs from the librarian (you know, once they're there)
[04:11] <infinity> Cause it'll need to follow dependencies.
[04:12] <pitti> bug 1003234
[04:12] <ubot2> Launchpad bug 1003234 in pkg-create-dbgsym "Build dummy -dbgsym for packages which already have a -dbg" [Undecided,Triaged] https://launchpad.net/bugs/1003234
[04:12] <pitti> infinity: right, but once we do fetch ddebs from Launchpad, it shouldn't make much of a difference
[04:13]  * infinity nods.
[04:13] <infinity> I hope to get to testing the state of all of that this week.
[04:13] <infinity> Once I'm done tearing my hair out over nscd.
[04:13] <infinity> Or jump off a building.
[04:13] <infinity> Whichever comes first.
[04:15] <pitti> infinity: when you go for the building, please do so from the doghouse
[04:16]  * pitti watches HDD space slowly come back on macquarie
[04:24] <wgrant> infinity: If we're fetching old ddebs from the librarian, why not fetch new ones from there too?
[04:25] <wgrant> infinity: Perhaps we don't need them published at all
[04:25] <pitti> we still want to have an archive for them
[04:25] <pitti> a lot of developers use them in their apt sources
[04:26] <pitti> wgrant: an intermediate step would be to chagne ddeb-retriever to fetch them from the librarian, and continue to build the ddeb archive separately on macquarie
[04:26] <wgrant> Ah
[04:26] <wgrant> That's a bit sad.
[04:26] <pitti> then the only thing that LP needs to do is to accept them in the .changes
[04:26] <pitti> and put them into the librarian
[04:27] <pitti> it would be a whole lot more robust than the current "on apache for 7 days" hack
[04:28] <wgrant> Yeah, that was an intermediate step I considered, but decided it wasn't worth it since we were always pressed for librarian space.
[04:28] <wgrant> Now it's on the SAN that might not be such an insurmountable issue.
[04:28] <pitti> wgrant: I still don't think we should keep each and every ddeb we ever built
[04:29] <wgrant> Oh, certainly not.
[04:29] <wgrant> That would be insane.
[04:29] <infinity> Well, the plan is to expire them at the same time we expire binaries.
[04:29] <infinity> Which does happen.
[04:29] <pitti> wgrant: for a released ubuntu we only need the ones from published packages
[04:29] <wgrant> infinity: We can't keep them that long, I don't think
[04:29] <wgrant> infinity: We only expire binaries once the series is obsoleted.
[04:29] <wgrant> If we ever do at all.
[04:29] <pitti> and for the dev release it would be nice to keep a backlog of two weeks or so
[04:29] <wgrant> Right, those policies sound reasonable.
[04:29] <infinity> wgrant: We also expire some binaries from released series.
[04:29] <wgrant> infinity: Not deliberately.
[04:29] <infinity> wgrant: Like old ones from updates/security that aren't current.
[04:30] <wgrant> That would be a bug.
[04:30] <infinity> This is what I was told happens. :P
[04:30] <wgrant> You were lied to :)
[04:30] <infinity> Blame elmo.
[04:30] <infinity> Either way, I think we should *aim* to not have special expiry for ddebs, since they'll just be part of the binary upload.
[04:30] <infinity> Should that prove a problem, we can revisit.
[04:31] <wgrant> They're so enormous that we'd need to change the binary expiration policy.
[04:31] <wgrant> Which we probably should.
[04:32] <wgrant> (and that requires rewriting the archive file expirer from scratch to not be a patched together pile of bugs, which I've been meaning to do for a while...)
[04:33] <wgrant> Currently the process for expiring PPA binaries is automated, but for primary archive stuff it's done by a frequently buggy piece of manual SQL
[04:33] <wgrant> It gets rewritten by someone every second time or so.
[04:33] <infinity> Comforting.
[04:33] <wgrant> And most times it has nice bugs that will wipe out half the live archive too.
[04:33] <wgrant> It's reliable, quality stuff.
[04:34] <pitti> "things you don't want to hear on a quiet, peaceful morning"
[04:36] <wgrant> Anyway, I have rough plans for a sensible garbage collector which will let us have a reasonably flexible binary expiration policy.
[04:36] <wgrant> Rather than the manual SQL.
[04:36] <wgrant> Which is buggy.
[04:36] <wgrant> Until then, we can't really have ddebs for the primary archive in the librarian.
[04:36] <wgrant> Or I think elmo will strangle me.
[04:37] <pitti> wgrant: thanks for the heads-up; now I at least know what the current blocker is
[04:38] <wgrant> Linaro's been happily using native ddeb support in their PPAs for several months, so most of it's fairly well tested.
[04:39] <infinity> wgrant: Well, ddebs in the librarian would only be for builds going forward, nothing historical.  So, it'll take a while for the cruft to build up.
[04:40] <wgrant> infinity: Yeah, but then the cruft will build up.
[04:40] <infinity> wgrant: Anyhow, elmo seemed okay with the idea when we discussed it.
[04:40] <wgrant> And we won't have any way to get rid of it.
[04:40] <wgrant> That situation is less than ideal.
[04:40] <wgrant> Although that might be a cunning way to get the GC rewrite scheduled...
[04:40] <infinity> (And he didn't assume that development releases were getting binaries reaped during development)
=== astraljava1 is now known as astraljava
[08:10] <cjwatson> pitti: dropping -dbg> At least (say) python2.7-dbg and friends are genuinely different builds and useful, so shouldn't be dropped.
[08:10] <pitti> cjwatson: *nod*; also what infinity said about -dbg shipping other useful tools
[08:11] <pitti> cjwatson: so I'd rather do it the other way around and don't build -dbgsym for pacakges with -dbg, or build empty ones with just a -dbg dependency
[08:11] <pitti> the latter is compatible with apport-retrace, I filed it as bug 1003234
[08:11] <ubot2> Launchpad bug 1003234 in pkg-create-dbgsym "Build dummy -dbgsym for packages which already have a -dbg" [Undecided,Triaged] https://launchpad.net/bugs/1003234
[09:47] <cjwatson> wgrant: Expiry: do you have any thoughts about the problem of ensuring that point releases are kept around even if we have a more aggressive expiration policy?  It's a bit tricky since LP doesn't model point releases.
[10:24] <wgrant> cjwatson: I would be tempted to just not expire post-release pockets.
[10:24] <wgrant> cjwatson: They're small enough
[10:25] <wgrant> cjwatson: The big stuff is the development churn in Release
[10:25] <wgrant> I should probably get some hard numbers, though
[10:34] <cjwatson> I'm trying to work out whether it's worth us keeping hardlink farms of the pool for point releases, as opposed to just of dists.
[10:34] <cjwatson> Just copies of dists, indeed.
[10:35] <cjwatson> The difference being that we can much more easily do only the latter on a mirror, while the latter is kind of cocoplum-specific (or a mirror with insane space).
=== yofel_ is now known as yofel
[11:52] <cjwatson> https://lists.ubuntu.com/archives/kubuntu-devel/2012-May/006080.html for those interested in archive-reorg kinds of issues
[12:52] <cjwatson> ^- Daviey's first accept
[12:52] <pitti> Daviey: wohoo!
[12:52] <Daviey> oh dammit, if i follow the law of 'firsts'.. i need to buy a round of beer.
[12:54] <pitti> hm, why is https://launchpad.net/~ubuntu-release-nominators a member of https://launchpad.net/~ubuntu-release ? that sounds a bit backwards
[12:54] <pitti> oh, I guess the LP priv is bound to ~ubuntu-release
[12:54] <cjwatson> Yes
[12:54] <cjwatson> It's a hack
[13:45] <stgraber> cjwatson: I very quickly scanned through that thread, but I'm wondering if using "X-Ubuntu-Use-Langpack: yes" where they think langpacks are beneficial would fix their remaining concerns?
[13:46] <stgraber> we've started using it for a few new Edubuntu packages where we knew translation would be sub-optimal at release time and wanted to benefit from post-release translations improvements through the langpacks
[13:54] <skaet> pitti,  L3, QA  needed to nominate bug to specific releases, and yes, its a hack.
[13:55] <pitti> skaet: sorry, what?
[13:56] <skaet> pitti,  ubuntu -release-nominators
[13:56] <skaet> :)
[13:56] <pitti> skaet: aah, thanks
[14:56] <skaet> cjwatson, slangasek, stgraber, infinity, stefanor, Laney, ScottK, and others interested,  https://wiki.ubuntu.com/QuantalQuetzal/ReleaseInterlock has most of the key information in it now.   (and related ReleaseSchedules updated from it),  can you review it, and make sure it matches up with your impressions from UDS?   I'll send mail out to ubuntu-release with this info as well.
=== debfx_ is now known as debfx
[14:57] <skaet> Daviey, ^
[14:59]  * Daviey grumbles about being an afterthought.
[15:22]  * skaet is sorry.  needs a better way to let release team members know in channel,  missed Ncommander too :/
[15:26] <stgraber> !dmb-ping
[15:26] <ubot2> bdrung, cody-somerville, Laney, micahg, barry, tumbleweed, stgraber: DMB ping
[15:26] <stgraber> skaet: like that ^
[15:26] <stgraber> (sorry for the ping ;))
[15:27] <skaet> stgraber, coolio.  :)  how do they get set up?
[15:27] <barry> stgraber: you woke me up from a nice nap.  i was dreaming about weekly team meetings
[15:27] <skaet> :)
[15:28] <stgraber> skaet: trying to get it setup in the bot now, will likely need someone from #ubuntu-irc to do it
[15:30] <stgraber> !release-ping is infinity, cjwatson, Daviey, Laney, iulian, Riddell, skaet, NCommander, ScottK, tumbleweed, sistpoty, slangasek, stgraber: Release team ping
[15:32] <Daviey> !-release-ping
[15:32] <ubot2> Factoid 'release-ping' not found
[15:32] <stgraber> Daviey: it needs approval by #ubuntu-irc, talking to them now
[15:33] <Daviey> stgraber: i am one of those.
[15:34] <Daviey> !release-ping is infinity, cjwatson, Daviey, Laney, iulian, Riddell, skaet, NCommander, ScottK, tumbleweed, sistpoty, slangasek, stgraber: Release team ping
[15:34] <Laney> argh
[15:34] <stgraber> Daviey: good to know :)
[15:34] <skaet> :)
[15:35] <stgraber> !release-ping
[15:35] <ubot2> Factoid 'release-ping' not found
[15:39] <stgraber> skaet: so apparently ubot2 needs to sync the new factoid from ubottu but it should be working fine next time you need it
[15:39] <skaet> awesome!   Thank you!
[16:31] <bjf> infinity: regarding the Precise 3.2.0-24.39 kernel: the patch has been verified to work and the kernel team have been boot testing the kernel on a wide variety of systems with no regressions
[16:31] <infinity> bjf: Excellent.
[16:32] <infinity> bjf: Well, get the bug tasks in a state that lets me know I'm good to go, and I'll make sure things happen.
[16:33] <infinity> bjf: (So, either get team signoffs or mark invalid where appropriate)
[16:33] <bjf> infinity: will do, thanks
[17:14] <bjf> infinity: i think i've hacked the tracking bug to reflect the correct state and added comments why i did what i did
[17:16] <infinity> bjf: Check.  Will poke it in a sec.
[17:50]  * ScottK wonders how https://launchpad.net/ubuntu/+source/stellarium/0.11.2-1/+build/3513355 got a build score of 5000?
[17:53] <stgraber> ScottK: that would be because I helped it a bit, synced stellarium from Debian (for Edubuntu) and wanted to confirm it builds on all arch before I can update edubuntu-meta (sadly arm still fails ...)
[17:53] <ScottK> OK.
[17:53]  * ScottK wanted to make sure it wasn't something related to recent build prioritization changes.
[17:53] <cjwatson> Nope, none of those would result in 5000
[17:54] <cjwatson> Anything that round isn't an auto-score :)
[17:54] <ScottK> I didn't think so.
[17:54] <ScottK> OK.
[17:54] <ScottK> It just didn't look like the sort of critical package one typically sees manually rescored.
[17:54] <cjwatson> Generally automatic scores aren't divisible by 100.
[17:55] <cjwatson> Due to +5/10/15/20 for urgency, +5/10/15/20/50/100 for queue tim
[17:55] <cjwatson> e
[17:55] <cjwatson> You'd have to have carefully selected packageset or archive relative build scores for that
[20:17] <Laney> Daviey: you're supposed to request backports on a bug, not just upload them yourself
[20:17] <Laney> https://wiki.ubuntu.com/UbuntuBackports
[20:20] <bjf> infinity, my intent is *not* to bug you, just a gentle reminder of my precise kernel
[20:30] <Daviey> Laney: I suggest re-working the wording, as it doesn't emphatically state a bog should be opened, unless you want to 'request a backport'
[20:30] <Daviey> ie, someone else please do the work for me
[20:31] <Laney> I did just add some more information to that page
[20:32] <Daviey> Laney: are you happy to review based as is, or do you want a bug?
[20:32] <Laney> can you have a look at the page and see if it's more clear?
[20:32] <Laney> I'd like a bug for bookkeeping, but it should be trivial to do so with requestbackport
[20:32] <Daviey> otp right now
[20:33] <Laney> the upload won't have the bug reference, but oh well
[20:36] <Laney> does anyone mind if I update the process to say that the accepting AA will set the bug to Fix Released?
[20:37] <Daviey> does -backports not Fix Release a series bug task?
[20:37] <Laney> no
[20:38] <Laney> it's a separate project
[20:39] <Laney> also I believe that backports are special cased in soyuz to never close bugs
[20:42] <ScottK> Daviey: If you aren't a backporter, you need approval to backport something.  Just because you have the theoretical rights, doesn't mean it's OK.
[20:43] <ScottK> FWIW, some of the most difficult backports we've had were snuck in by archive admins without consulting the backports team (although that was long ago - it's been years since I noticed someone doing it).
[20:55] <cjwatson> Laney: I don't mind, but I'm pretty sure I've forgotten to close bugs pretty much every time so far.  We could use some tooling here.
[20:56] <Laney> cjwatson: Don't you use the web UI to accept stuff?
[20:56] <Laney> (if so then it doesn't seem so amenable to scripting)
[20:59] <cjwatson> We do at the moment.  Probably not forever.
[21:00] <cjwatson> But yes, that would be an impediment at the moment.  Some scripts do things like "go accept this, then press Enter and I'll close the bug"
[21:00] <cjwatson> Like syncpackage
[21:00] <cjwatson> (OK, that's "wait for sync to be processed, but ...")
[21:00] <cjwatson> And since we need a backport verification script anyway, that'd be somewhere for it to go
[21:01] <Laney> Yeah. I think broder was going to implement that, but the wait for backports is somewhat more indeterminate.
[21:01] <cjwatson> So the workflow for the time being would be "verify-backport blah" - downloads pair of source packages, diffs, asks you if it's OK, if you say no it bails out, if it says yes it gives you a queue URL and says to press Enter when you're finished with it
[21:02] <cjwatson> I agree it's a bit more tenuous to do the wait on the backportpackage side, so if it didn't involve AAs having to manually open up bug URLs and paste stuff into them, I'd be fine with it
[21:04] <Laney> If you'd actually use a script (and not find it a cumbersome impediment), then that sounds reasonable.
[21:04] <slangasek> I find scripts universally preferable to the web ui ;)
[21:04] <Laney> I just figured it was a bit of click click on the queue UI, so switching out to a terminal would be irritating
[21:04] <cjwatson> I'd definitely use a script
[21:04] <cjwatson> The click click will go away soon enough - PackageUpload.acceptFromQueue() or whatever isn't that far off
[21:05] <cjwatson> I think possibly I need to break down that branch into pieces as I was having trouble figuring out the tests for the override part
[21:22]  * Daviey returns
[21:22] <Daviey> ScottK: Right.. I didn't suggest otherwise.. The backporting page wasn't clear.  I read it as, if you want a package backported (and cannot/will not) do it yourself, you raise a bug.
[21:23] <Daviey> If you can do it yourself (upload), you upload and it's simply reviewed in queue.
[21:23] <Daviey> It's not entirely clear to me what having a bug to track the "will do it yourself" helps with.. It's surely a binary operation?
[21:24] <infinity> bjf: What kernel?
[21:24] <Daviey> Yes, we accept this as a backport and it's good quality... No, this isn't appropriate for a backport, or bad quality.
[21:24] <bjf> infinity, the fast tracked Precise kernel
[21:24] <infinity> bjf: (look up)
[21:24] <Daviey> ScottK: otherwise, why aren't srcNEW packages required to have tracking bugs in the development release?  Surely it's similar issues?
[21:25] <bjf> infinity: ok, thanks
[21:25] <cjwatson> Whoops, linux-tools and nvidia-support weren't meant to happen there, some kind of caching issue
[21:26] <cjwatson> Other than that, that was auto-sync in batch mode, seemed to DTRT
[21:27] <cjwatson> So just existing-NEW-detection and a bot account and I can entirely automate this
[21:27] <cjwatson> Well, except for the NEW processing at the end
[21:30] <cjwatson> Batch mode is "sync all autosyncable existing packages that don't overwrite existing *ubuntu*-versioned binaries, plus any new packages that don't overwrite existing *ubuntu*-versioned binaries and that have never previously been published in Ubuntu"
[21:30] <cjwatson> So anything that's been removed but has then returned for good reason will still need manual attention, as will source renames of things with Ubuntu modifications
[21:32] <Daviey> cjwatson: what about ubuntu native packages that do not have ubuntu in the version string, and Debian introduces a package of the same name?
[21:32] <infinity> We add those to the blacklist.
[21:32] <infinity> Or, we should.
[21:32] <cjwatson> They'd have been autosynced in both the current and previous systems without anyone noticing
[21:33] <Daviey> So, confirming that the new world order supports that.
[21:33] <cjwatson> So either blacklist in advance, or repair after the fact
[21:33] <cjwatson> Nothing about blacklisting has changed
[21:33] <infinity> If you intend to have non-ubuntu-versioned stuff that's different from Debian, blacklist early and often.
[21:33] <cjwatson> Well, except that it's now in a bzr branch on LP rather than a private one on cocoplum
[21:33] <infinity> (udev being the canonical case that springs to mind)
[21:33] <Daviey> cjwatson: hmm.. where is this branch?
[21:34] <cjwatson> Daviey: lp:~ubuntu-archive/+junk/sync-blacklist
[21:34] <cjwatson> Ah, ArchiveAdministration is out of date
[21:34] <cjwatson> I only moved it there the other day
[21:34] <Daviey> super.
[21:34] <cjwatson> Fixed
[21:35] <Daviey> ScottK: Can you respond to my above comments when you have a chance please?
[21:47] <cjwatson> OK, and now auto-sync will (hopefully) detect things that are already in NEW and not repeat itself
[21:53] <ScottK> Daviey: It's supposed to be approved via the bug before upload.  That's the difference.
[21:54] <ScottK> The do it yourself aspect of this is supposed to be fore ubuntu-backporters,n ot for general use.
[21:54] <Daviey> ScottK: and that used to be the case for SRU, but was reverted.
[21:54] <Daviey> ScottK: wait, ubuntu-backporters don't need a tracking bug, as they review their own stuff, and everyone else does?
[21:55] <Daviey> ScottK: So please, what is the difference between using a tracking bug to 'approve' and upload, and just 'approving' from the queue?
[21:56] <ScottK> Daviey: Because not all backporters have access to the queue.
[21:56] <Daviey> ScottK: okay, can you compare to srcNEW for the development release?
[21:56] <ScottK> Daviey: If you want a process change, please don't just make it up and start doing the new way.  Discuss it with people first.
[21:56] <Daviey> Sponsorship bug vs just uploading?
[21:57] <Daviey> ScottK: this isn't a process change.. Process is documented, this was not.
[21:57] <ScottK> Yes and if you're not in backporters you need sponsoring.
[21:57] <Daviey> Or at least ambiguous at best.
[21:58] <ScottK> So far only for you.
[21:58] <ScottK> I have to go.
[21:58] <Daviey> Yeah, we don't exactly have a bustling backporters community, so yeah.
[22:06] <cjwatson> What ScottK is describing is definitely how I understood the process.
[22:08] <cjwatson> (I have abused archive admin to shove in backports in the past, although only for debootstrap; I've been persuaded by argument not to do this in future)
[22:09] <Daviey> cjwatson: right, but i'm trying to determine the difference between 'review in queue' and 'review via tracking bug'.  Especially as ~ubuntu-backports can self approve a backport without a bug.
[22:10] <cjwatson> I'm not aware that they actually do so.
[22:10] <Daviey> cjwatson: well ScottK just suggested otherwise.
[22:11] <cjwatson> AFAICS -backporters use tracking bugs even for things they care about personally ...
[22:11] <cjwatson> Anyway, for me, the important bit is that authority for the backports pocket is wholly delegated to -backporters
[22:12] <Daviey> +1
[22:12] <cjwatson> While archive admins happen to have queue admin access there, we're doing so on behalf of -backporters until such time as they can do it themselves
[22:12] <cjwatson> So it's not for us to create policy on their behalf
[22:13] <Daviey> cjwatson: right, i'm not doing that.. The documented 'policy' was (in my mind) ambiguous.
[22:14] <cjwatson> OK; but then in that case verbal clarification should be enough for the time being, with the understanding that it's generally worth clarifying documents when people misunderstand them
[22:14] <cjwatson> I just don't think "this is ambiguous" "it means this" "but this is ambiguous" is necessarily a productive continuation
[22:14] <cjwatson> IYSWIM
[22:16] <Daviey> cjwatson: yes, i see that.
[22:17]  * infinity needs new glasses.
[22:17] <infinity> "New binary: horse-simulator [i386] ..."
[22:24] <RAOF> infinity: New binary: my-little-pony [armhf] ...
[23:09] <jdstrand> is it accurate to say that the 'all' files in each seed directory in http://people.canonical.com/~ubuntu-archive/germinate-output/ contains all the packages that make up the seed. eg ubuntu.precise/all is all of 'ubuntu' and xubuntu.precise/all is all of xubuntu?
[23:09] <jdstrand> meh, gotta run
[23:13] <cjwatson> jdstrand: It contains all directly seeded packages and the fully-expanded chains of run-time dependencies/recommendations and build-dependencies.
[23:14] <cjwatson> (I'd recommend reserving "seed" for e.g. "desktop" and using "seed collection" for "ubuntu.precise".)