=== maco2 is now known as maco === pitti_ is now known as pitti === warp10` is now known as warp10 === doko_ is now known as doko [12:39] cjwatson, hmm, so my arm desktop images all end up around 1G ... and there seem to be no manifest files generated for them [12:40] i thought it was a copying issue, but even sycamore doesnt have them [12:43] OK, I'll have a look, thanks [12:59] ogra_: won't the size largely be due to switching from netbook to desktop? [13:00] well, all other arches are around 700M [13:00] surely we grew by switching to desktop [13:00] the size isnt my issue, the missing manifests are :) [13:01] fixed your manifest output [13:01] (livecd-rootfs 2.6) [13:01] so i can find out what we have extra on arm [13:01] thx ! [13:02] cjwatson: the list of sources with no binaries in the archive: http://paste.ubuntu.com/627926/ [13:02] not yet right/complete. [13:02] ah, you missed udebs in your binary list [13:02] ahh, good point [13:03] s390-* and sparc-* packages can be sorted out [13:03] looking at things like: https://launchpad.net/ubuntu/+source/ubuntu-calendar-march/+publishinghistory the sources are there, but not more the binaries. any idea why? [13:04] I don't understand the *-ruby packages yet [13:07] I can't remember how to get at BPPH records in the UI [13:10] * cjwatson pokes about in the API [13:11] are the apt.sources lines for downloading the debian-installer packages files? [13:14] binaries were removed with 'unmaintained upstream since hoary; if this is ever revived and somebody steps up to do the packaging work, it can be reintroduced' [13:14] no obvious reason why the source package wasn't removed; I guess that was an accident [13:15] ubuntu.main_archive.getPublishedBinaries(binary_name='ubuntu-calendar-march') # and then poke about through the resulting collection of binary_package_publishing_history objects [13:17] doko: just use main/debian-installer restricted/debian-installer etc. as components [13:20] heh, and I removed the ubuntu-calendar-* binaries back in intrepid apparently, so my bad for missing the sources [13:20] I've removed all six remaining ubuntu-calendar-* source packages now [13:21] oh, and ubuntu-calendar too [13:25] pitti: [13:25] language-pack-gnome-zh [13:25] language-pack-gnome-zh-base [13:25] language-pack-kde-zh [13:25] language-pack-kde-zh-base [13:25] language-pack-zh [13:25] language-pack-zh-base [13:25] source exists, but no binaries [13:28] the ruby packages are a lot of source renames [13:47] cjwatson: filed https://bugs.launchpad.net/ubuntu/+bug/798195 will do the ftbfs checks later [13:47] Launchpad bug 798195 in ubuntu "source packages in oneiric without binaries (affects: 1) (heat: 8)" [Undecided,New] [14:15] doko: oh, these source pkgs should be removed; doing now [14:16] pitti: could you update the bug report above? [14:16] yep, will do [15:44] Aren't some of those the ones we removed binaries for during Lucid so we wouldn't have unsupportable binaries in an LTS? [15:44] Why the push to remove the source now? My recollection was that we decided keeping the source was harmless. === NCommand1r is now known as NCommander [17:42] skaet: And, here's the list I've promised :) [17:42] http://paste.ubuntu.com/628055/ [17:43] nigelb, Thanks! do you have the bug numbers associated with them? [17:43] skaet: Not yet. tumbleweed is figuring that out :) [17:44] nigelb, sounds good. :) [18:03] skaet: without being able to programattically link bugs to blueprints, I don't think this is going to be very workable [18:05] tumbleweed, it feels like it should be scriptable, just going to be a matter of figuring out the right launchpad API's to let us find and hook them up. [18:06] there are API methods for linking branches, but not bugs (that I can see). Bugs appear to be read only [18:06] hmm... which version are you looking at? [18:06] devel, 1.0 has almost nothing for blueprints [18:07] What are we trying to do, file bugs and then link them to the BP? [18:07] nigelb, yup [18:07] find the bugs already filed [18:07] tumbleweed: finding should be easy. [18:07] and then link them :) [18:08] worst case [18:08] tumbleweed, searching on the tag ftbfs under the oneiric bugs gives you the first pass. Then for each of the bugs, need to determine if the project is against universe [18:08] we can have it print out the bugs and we can link manually [18:08] tumbleweed: oooh [18:08] tumbleweed: talk to brian please? he has a selinium test thingy account [18:09] tumbleweed: That can do this linking from the web ui. [18:09] tumbleweed: iamfuzz on irc [18:09] If its about 80, I'll take a share. If its going to be 780, then yeah we need to do it programatically. [18:09] * skaet heads out to lunch, biab [18:11] nigelb's list was ~80, which is manageable, yes. If it were more than that I'd say there are easier ways to get progress graphs (the FTBFS page on qa.ubuntuwire has CSV output that would be trivial to store and graph) [18:11] tumbleweed: I wwas actually hoping to use harvest, bug in harvest prevented that. [18:11] (I should file that bug) [18:17] nigelb: what's that list for? [18:17] * micahg notices chromium [18:17] micahg: ftbfs, that's because of linking changes [18:18] ah, ok [18:18] micahg: is the chromium failure correct in that way? [18:19] nigelb: yes, but I think it's fixed now [18:19] we scraped the list 2 days back [18:19] oh, wait, arm is still broke I think [18:20] yes, hrm is working on an arm fix atm [18:20] in a very heroic attempt :) [18:20] err [18:21] s/hgrm/hrw/ [18:21] heh [18:21] nigelb: I think gcc-4.6 + chromium on i386 is fixed in trunk ATM, will check [18:21] ogra_: heh, interesting spell-error ;) === ArneGoet1e is now known as ArneGoetje === yofel_ is now known as yofel