[00:07] <cjwatson> phillw: I could probably compute it in time, but #ubuntu-mirrors probably has somebody who knows off the top of their head
[00:12] <phillw> cjwatson: soz, it's about 700GB, but was not the question the person who asked me really meant. He meant that a lot of mirrors seem 'out of sync', to which your answer is the best as I did not know that the channel existed. Thanks for the link :)
[16:06] <xnox> so i have run the archive-scanner and got an updated tarball of postprocessed .desktop files and icons.
[16:06] <xnox> looking at app-install-data-ubuntu though, the layout is a bit different.
[16:07] <xnox> am I correct to assume that I should more or less, update the menu-data/ subfolder with the tarball I got from the archive scan and that's the gist of it?
[16:07] <xnox> stgraber: cjwatson ^^^
[16:08] <stgraber> no idea, my knowledge goes as far as "ping mvo" for that one ;)
[16:09] <xnox> stgraber: it's just i spotted menu-data-edubuntu that is all =)
[16:10] <infinity> We've pretty miserably failed at knowledge sharing on how that all works.
[16:10] <infinity> But if doing what you said produces a plausibly sane package that's kinda like the old one, that might be right. :P
[16:10] <infinity> And it might really need a README.source
[16:11] <Laney> right, I'd say ping mvo to help you walk through it and make damn sure it's documented well enough for someone else to do it next time
[16:11] <Laney> you can use me to retrace your steps to see if we end up with the same thing
[16:12] <infinity> Indeed, if Laney can do it, it's probably foolproof.
[16:12]  * infinity ducks.
[16:12]  * xnox goes to do validation / comparison.
[16:13] <Laney> !coc | infinity
[16:13] <ubot2> infinity: The Ubuntu Code of Conduct is a community etiquette document to which we ask all Ubuntu users to adhere | http://www.ubuntu.com/project/about-ubuntu/conduct  | For information on how to electronically sign the CoC, see https://help.ubuntu.com/community/SigningCodeofConduct | Watch http://static.screencasts.ubuntu.com/videos/2010/12/22/004-SigningCoC.ogv
[16:13] <Laney> :P
[16:13] <infinity> *cough*
[16:14] <xnox> infinity: i believe Laney deserves to be slapped around a bit with something wet =)
[16:14] <infinity> To be fair, the CoC leaves no room for good-natured ribbing, he's not wrong that I violated it.
[16:14] <infinity> I just think the CoC is wrong. :P
[16:14]  * Laney backs away slowly
[16:14] <xnox> Laney: you did that and didn't get reminded about !coc
[16:16] <Laney> I look forward to your trout in Oakland
[16:17]  * xnox notes to check if Scottish Trout is O.K. with USA Customs and Border Protection 
[16:17] <cjwatson> xnox: that's what I understand, but I've only ever driven this from the client side, never attempted to run the archive scanner.  There's a script for it which did the right thing last I checked without layout changes, so I'd tend to interpret a layout change as a sign of something being wrong
[16:18] <cjwatson> I don't remember which of update-menu-data.sh and update-menu-data-from-file.sh I used
[16:20] <xnox> cjwatson: right, that's correct. That script will take my generated tarball, the two are compatible.
[16:20] <cjwatson> except that it appears to be producing unusual output :)
[16:21] <xnox> it's just that there are a few more util scripts in the ubuntu package like: addKeywords.py addPopconData.py and I'm not sure if I should run it.
[16:21] <xnox> cjwatson: oh, I was expecting .orig.tar.gz from the archive scanner, without the step of "importing" that into the ubuntu package.
[16:22] <xnox> cjwatson: the import script & the archive-scanner tarball look like a matching pair with nothing unusual.
[16:28] <cjwatson> the util scripts you refer to are run by pre-build.sh
[16:28] <cjwatson> so use bzr bd -S
[16:32]  * xnox did apt-get source, totally forgot about mvo's love for pre-build scripts & bzr-bd hooks
[16:37] <bdmurray> could someone have a look at bug 1157721?
[16:37] <ubot2> Launchpad bug 1157721 in Ubuntu CD Images "jigdo for ubuntu-12.04.2-alternate-amd64.jigdo file not found " [Undecided,New] https://launchpad.net/bugs/1157721
[16:47] <cjwatson> looking
[16:48] <cjwatson> (fwiw I get cdimage bugs in my inbox)
[16:49] <bdmurray> ah, I'd forgotten about cdimage and the project changed on me
[16:50] <cjwatson> anyway, duped, and unfixable
[16:55] <xnox> commented on how this can actually be solved with redirects and launchpadlibrarian =)
[16:56] <xnox> cjwatson: Why does archive.ubuntu.com Release file mentions all architectures and not just those that are on archive.ubuntu.com? Or Release.gpg can only be generated at the place that has no idea that we have archive/ports.ubuntu.com split?
[16:56] <cjwatson> the latter
[16:56] <xnox> ack.
[16:56] <cjwatson> "unfixable" in the sense that it can't be fixed on cdimage alone, but needs infrastructure work elsewhere
[16:56] <cjwatson> -> SEP
[16:57] <xnox> ack.
[16:57]  * xnox ponders how "helpful" is adding popcon data to the app-install-data given that there is no UI left to enable popcon....
[16:59] <xnox> Is http://popcon.ubuntu.com/by_vote still our destination popcon? (me remembers vague talks that we stated submitting popcon data to debian instead....)
[19:30] <TheDrums> xnox: Last I looked, popcon hasn't been updated for quite a while.
[20:24] <darkxst> balloons, did you add those testcases yet for ubuntu GNOME?
[20:30] <balloons> darkxst, yes
[20:30] <balloons> http://iso.qa.ubuntu.com/qatracker/milestones/243/builds/40208/testcases
[20:31] <darkxst> ah yes, now I see them
[20:32] <darkxst> did you add upgrade ones?
[20:36] <balloons> those products don't exist.. and in general, no reason to exist yet :-) You don't have a previous release
[20:50] <darkxst> balloons, well we do have the previous unofficial release, but I am not sure how well upgrading will work from that
[21:11] <stgraber> not too surprisingly at least one slideshow is broken in the current ubiquity-slideshow-ubuntu branch... good thing I asked to be ready 24h before the actual freeze :)
[21:12] <robru> so this new gexiv2 has some new API that I suspect might break/regress some of the applications using it. assuming that I can confirm the breakage happens, what steps should I take to mitigate that before raring is released?
[21:13] <Laney> you mean third party apps?
[21:13] <robru> yeah
[21:13] <Laney> robert_ancell checked the archive
[21:14] <robru> there are a bunch of new apps that were ported to gexiv2 0.5 that probably aren't in the archive yet.
[21:15] <robru> so basically, back in copenhagen I was encouraging people to port their python apps away from pyexiv2 towards gexiv2. at the time, gexiv2 was only used by shotwell, and yorba guys got a bit freaked out by the prospect of more people using gexiv2, so they did a major API cleanup sweep. I meant to pay closer attention to it, but it got away on me
[21:16] <robru> I don't think any of the gexiv2 ports have actually landed yet, but I'm concerned that upstreams are going to be frustrated by this breakage as they attempt to land
[21:16] <Laney> Possibly, but it would have happened sooner or later anyway
[21:17] <Laney> At least it's not tied to the Raring schedule so they are able to update at a more leisurely pace
[21:19] <Laney> and if it's what upstream wants to expose as their stable API then it's probably worth the pain now, given that the ports are still WIP
[21:20] <robru> Laney, what I meant was, "I had the chance to work with yorba and reduce the impact of API breakage by writing some compatibility glue for them, but I totally blew it, and now I'm afraid that consumers of gexiv2 are gonna get burned by some API breakage hell"
[21:21] <robru> I don't know what to do now ;-)
[21:22] <Laney> Hah, well you can still work with them and get that in for S (which will presumably be the Ubuntu target for these ports)
[21:22] <robru> I guess what I'll have to do is test some things out, see how bad the breakage really is. If it's really bad, what are the chances that I could still write that glue code, and then just have it as a distropatch on gexiv2?
[21:22] <Laney> or ... work with the upstreams on the ports
[21:22] <robru> is it too late to save raring? :-/
[21:23] <Laney> depends how fast you can work ;-)
[21:24] <robru> Laney, basically what would need to be done is to re-implement a couple python methods in GExiv2.py that used to be implemented in C code... so althought I'm writing "new" code, I'd really be restoring API that used to be there in 0.5. What kind of a deadline am I looking at for a patch like that?
[21:24] <robru> Laney, maybe a dozen lines of python
[21:27] <Laney> robru: well, I suppose we'd have to see it, but if it really will be that limited in scope then it should be fine for the next week or two (preferably before the beta freeze)
[21:28] <robru> Laney, you made a good point about "what upstream wants to expose as their stable API", so maybe I'll just leave it as-is and work with gexiv2 consumers to adjust to the new API. ok, I'll have to do a bit of research now. thanks
[21:28] <Laney> I think you'll have to do those adjustments anyway at some point as the compat API is presumably not going to be around forever
[21:29] <robru> Laney, exactly. distropatching is extra effort for little gain
[21:29] <Laney> If you decided to add it in S-series we could put the new gexiv2 in backports, BTW
[21:29] <Laney> so these upstream PPAs or whatever would be able to make use of it for raring
[21:29] <robru> Laney, good point also
[21:29] <Laney> not sure I have a good answer for extras though
[23:03] <bdmurray> the pending sru report has become empty
[23:10] <Laney> seems to be there now
[23:12] <RAOF> I totally did ALL THE SRUs yesterday :)
[23:48] <xnox> Thanks for boost1.53, not sure who synced it =) beat me by 40minutes ;-)
[23:49] <xnox> armhf still has another 2 hours to go =)
[23:52] <xnox> ah, doko. Thanks. yeah we do need -2 for python FTBFS fixes.