=== Guest40875 is now known as NCommander === NCommander is now known as Guest33707 [09:15] tzdata in precise is ancient. ): [09:25] pkern: marga is going to do the update it seems [09:25] you both pointed it out at the same time [09:26] pkern, we are discussing it on #ubuntu-desktop [09:26] should be more on top of that though [09:26] * Laney looks for an announce list [10:28] Laney: Yeah, we're in the same room. ;) [10:29] heh [10:53] ok, tzdata updates sponsored [10:54] if somebody of the SRU team could review those today ^ [10:54] it fixes bug #1222345 [10:54] Launchpad bug 1222345 in tzdata (Ubuntu Raring) "Wrong DST dates in Israel" [High,In progress] https://launchpad.net/bugs/1222345 [11:20] infinity, cjwatson, slangasek, stgraber, bdmurray, ScottK, RAOF, Daviey: ^ (sorry for the direct ping but precise to raring are currently buggy, dst ended up when it shouldn't have) [11:24] lucid is as buggy, fwiw. [11:25] yeah, should be done too [11:28] right, added that one to the list, marga is going to do it as well, thanks for pointing it out [12:15] seb128: I can look at it in probably half an hour or so. [12:15] ScottK, thanks [12:39] seb128: The precise upload looks like it was supposed to be the one for lucid based on version and debian/changelog entries that got dropped. [12:40] tzdata (2013d-0ubuntu0.10.04) precise; urgency=low [12:41] ScottK, shrug, thanks, indeed (well, there was 2 uploads to precise, rejecting the buggy one) [12:42] ScottK, done, only the correct one is left in the precise queue [12:43] Found the good one. Much better. [12:44] seb128: Are you doing lucid too? [12:44] ScottK, yes, I'm going to reupload that buggy one with the correct changelog target, thanks for catching it [12:45] can i get an archive admin to review dogpile.cache and dogpile.core in binary-new, keystone is pretty broken without them (https://bugs.launchpad.net/ubuntu/+bug/1222802) [12:45] Launchpad bug 1222802 in Ubuntu "FFE: dogpile.core and dogpile.cache" [Undecided,New] [12:53] seb128: Thanks for the tzdata stuff, I was actually going to do that today. [13:01] infinity: any opinions on executing bug #1213463 [13:01] Launchpad bug 1213463 in groundcontrol (Ubuntu) "Please remove bzr-gtk source and binary from saucy" [Undecided,Confirmed] https://launchpad.net/bugs/1213463 [13:03] xnox: It leaves a sour taste in my mouth that we're not willing to maintain it, but meh. Happy to remove it if it has no rdeps. [13:04] infinity: well, there is groundcontrol that does lp.net screenscraping (which probably also suffered from bit-rot) [13:04] Yeah, I'm seeing that. [13:05] infinity: imho, it's more important to get the maintainance release of bzr into the archive though with all the bugfixes it has accumulated. [13:05] infinity: but you do know how liberal my approaches to removals are ;-) [13:06] xnox: As a general rule, I prefer not to remove packages but, in this case, it'll either push someone to fix them, or they'll just disappear. Meh. [13:09] seb128: All in. Thanks. [13:09] ScottK, thanks for the reviews! [13:10] ScottK, infinity: can we get those copied to updates before a week if we get the verification done? [13:10] Yes. [13:10] infinity: i've raised the issue with jelmer, and he said should be removed. [13:10] Absolutely. [13:10] xnox: I already removed them. [13:10] \o/ [13:10] Oh man, someone accepted code-of-conduct-signing-assistant? [13:10] Fun... [13:34] pkern: What time is it supposed to be in Israel right now? [13:34] google tells me 16:34 [13:37] Thanks. [13:37] Quantal works. [13:37] err Raring [13:38] the bug will start in 3 weeks time... [13:39] Oh. [13:39] Right. [13:39] https://wiki.ubuntu.com/StableReleaseUpdates#tzdata [13:39] that tells you how to verify tzdata srus [13:41] ScottK, https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1222345/comments/16 [13:41] Launchpad bug 1222345 in tzdata (Ubuntu Raring) "Wrong DST dates in Israel" [High,Fix committed] [13:41] Laney: Thanks. [13:42] seb128: Thanks. I read that and then forgot about it. [13:46] OK, verified that correctly and it's right. [13:47] excellent! [13:51] precise is good too. [14:05] slangasek: ScottK: sorry if someone asked this already, but would you mind checking bug 1220588 (FFe)? we're trying to land the gst-plugins-bad support for touch (using the hardware decoders from android) this week, and for that we'd need gst 1.1.4 [14:05] Launchpad bug 1220588 in gstreamer1.0 (Ubuntu) "[FFe] Update GStreamer stack to 1.1.4" [Undecided,New] https://launchpad.net/bugs/1220588 [14:07] rsalveti: Approved. Please close the bug once it's all uploaded. [14:08] infinity: awesome, thanks! [14:08] Laney: ^ [14:08] ty [14:09] rsalveti: If you've time you can upload/sync what's in the PPA except for libav [14:09] rsalveti: Otherwise I'll get to it tomorrow [14:10] Laney: sure [14:10] Would be good for jhodapp's stuff to turn up quite soon, btw [14:11] Laney: yeah, that's what we want to get going this week (we're in a sprint in lexington atm) [14:11] * Laney nods [14:11] rsalveti: did the hybris fix come in? [14:12] Laney: it looks like the Ubuntu GNOME iso cronjob is still disabled? [14:12] is it? [14:12] lemme see [14:12] yes, yes it is [14:12] fixed [14:13] ScottK, thanks a lot of helping on those tzdata SRUs! [14:13] You're welcome. [14:13] jbicha: in time for your spin today, so I'll let it happen automatically [14:13] I just released p - r. I forgot to mash accept on Lucid, so I'll test/release that once it's published. [14:19] infinity: ping https://bugs.launchpad.net/ubuntu/+bug/1222802 [14:19] Launchpad bug 1222802 in Ubuntu "FFE: python-dogpile.core and python-dogpile.cache" [Undecided,New] [14:20] zul: Can you fix the things mterry pointed out and reupload? [14:21] infinity: sure [14:21] I'll do a quick NEW review here. [14:25] zul: Can you replace the unicode ¨ in debian/control with the ascii " instead too? [14:25] zul: Not sure if that'll cause any issues in any packaging frontends, but it's a bit nonstandard. [14:25] in dogpile.cache? [14:26] zul: cache has the weird quotes in the long/short description, core has inconsistent quoting in its descriptions. [14:27] infinity: k fixed locally === Guest33707 is now known as NCommander === NCommander is now known as Guest84948 [14:42] Lucid's tested and released, so tzdata emergency is over. [14:42] pkern (and marga): Thanks. [14:50] could someone help me understand why the mythtv upload from a few days ago hasn't migrated out of proposed? [14:51] superm1: did you check http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html ? [14:51] ah no, didn't know about it. so it's because armhf and powerpc failed [14:52] i'm not really sure how to go about fixing either of those though [14:54] Are they basically permanent build failures? [14:54] ScottK: I wonder why tzdata is not monitored more actively. But that's no question for you. ;) [14:54] ScottK: Thanks for acting that quickly. [14:55] You're welcome. [14:55] powerpc looks easily enough fixable by including [14:55] I suspect the answer is pitti used to do it and no one picked it up when he switched positions. [14:55] cjwatson: ah i'm happy to try that and see if it improves things (and kick it upstream if so) [14:56] i don't think armhf is a permanent build failure either [14:57] I don't know where QGLContext comes from OTTOMH but doesn't seem horribly difficult to look for [14:57] mythtv has enough reverse-dependencies that I do think it'd be better to tidy up properly if possible [14:58] The armhf failure is probably a GL/GLES confusion. [15:27] can an archive admin review python-troveclient please https://bugs.launchpad.net/ubuntu/+bug/1221981 [15:27] Launchpad bug 1221981 in Ubuntu "[FFe] [needs-packaging] New package python-troveclient" [Wishlist,Triaged] === Guest84948 is now known as NCommander [15:32] zul: Is that also going to main, or just universe initially? [15:32] thats going into main again [15:32] ill get adam_g to follow up with mterry [15:52] could somebody force chromium-browser in? [15:52] update_excuse has "autopkgtest for chromium-browser 29.0.1547.65-0ubuntu1: FAIL (Jenkins: public, private) " [15:52] but seems those tests have never been green [15:53] If you file a bug and about them and assign it to qengho ;-) [15:53] noooooo!!!! [15:53] Ah, alright. [15:53] lol [15:54] we shouldn't be happy with tests that never pass [15:55] nobody is happy about those I think [15:55] I should disable them until I have time to work them out. I thought the simple tests would be a good starting point, and not cause problems. [15:55] well, I thought it's an achievement to get it build on armhf as it is =) [15:55] qengho: only if they finish with: 2>&1 || true [15:55] hrhr [15:56] Laney, qengho: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1222895 [15:56] Launchpad bug 1222895 in chromium-browser (Ubuntu) "the autopkgtests need to be fixed" [High,Confirmed] [15:56] merci monsieur [15:56] de rien ;-) [15:56] seb128: "Thanks." [15:56] qengho, you're welcome :p [15:57] k, hinted in [15:57] thanks [15:57] I should work on my french with this team. It's the only other language I have more than a few hundred words of in my head, and I never get to use it. [15:58] ...which means it's probably down to far less than a few hundred now. [16:01] infinity: are you doing the weekly release mumble from lex? [16:03] cjwatson: I... Hrm... Maybe if I can find a room. [16:04] Let me see. [16:11] infinity: no more bzr-gtk?! sadness [16:11] slangasek: Yeah, it's really hurting my feelings. [16:11] (die, die, die) [16:12] :( [16:12] slangasek: You're welcome to fix it. [16:28] infinity: hello! By any chance, were you able to take a look at the XIM SRU bits for nux/unity raring? Sorry for being so annoying about that ;) [16:52] what does "xxx has no binaries on any arch " mean? [16:54] zul: Didn't build anywhere, usually [16:56] cjwatson: launchpad is complaning about "Some binary packages for this source are not yet published in the repository" [16:56] what package? [16:58] python-dogpile.cache [16:58] binary NEW [16:59] processed now [16:59] cool thanks [16:59] cjwatson: can check python-lesscpy as well please? [17:01] zul: what's to check? it's in saucy [17:01] cjwatson: arrgh ok sorry about that [17:02] np [17:27] infinity: bzr-gtk is so fragile I can't even get bzr merge-upstream to work on it, so yeah, guess I'm not saving it. [17:49] the armhf failure seems resolvable for now at least by turning off VAAPI for that build until upstream can sort it out, but PPC isn't just a matter of including byteswap.h, it's already actually done and that code hasn't changed AFAICT since last successful build. maybe toolchain changes have caused this behavior i'm wondering [18:00] hey all. [18:00] release team question. [18:00] openstack havana will release same day as ubuntu 13.10 (october 17). [18:01] so we're guaranteed to have a zero day sru for openstack components (at least in version-name). [18:02] i'm wondering what the correct path is to make the release / SRU team aware of this, as we want to ship SRU to 13.10 as soon as possible after tarballs arrive for openstack havana [18:05] just upload to saucy-proposed as soon as you have the packages ready [18:06] anything in there usually gets turned into a 0-day SRU on release day (after we cleanup anything in there that failed to migrate to saucy before release) [18:06] so you're likely to have the new openstack in -proposed at release time (or very shortly after) and into -updates after the usual SRU validation process [18:12] stgraber, well, can i / should i open place holder bugs ? [18:12] and i'd kind of like uber-fast-path in possibly unlikely case that these are simple release renames. [18:12] smoser: yes, it's going to be a standard SRU as far as validation is concerned, so the same workflow applies there [18:13] smoser: getting it released early is possible and will be up to the SRU team, if the diffs only show a simple version change, I think that'd be reasonable [18:14] yeah. ok. so i suspct at some point i will open SRU bugs for 13.10. probably sooner than later. [18:14] just to have those ready to fill in with additional information. [18:15] xnox, I uploaded linux-meta-goldfish if you would be so kind as to NEW it when it appears in the queue. [18:18] infinity, (or cjwatson) could one of you take a look why autopilot doesnt seem to migrate out of proposed ? the excuses page says "Valid Candidate", while there is a dep-wait on ppc (but thats there longer already and former uploads odf autopilot seem to have migrated nontheless) [18:34] ogra_: There's no dep-wait on powerpc. It builds on PPC and is uninstallable. [18:38] ogra_: libautopilot-qt was upgraded from a recommends to a depends, and it's not available on PPC. [18:39] ogra_: So, if that dependency is true, autopilot-touch shouldn't be built on PPC. [18:50] infinity, well, it seems to hold back autopilot, not autopilot-touch [18:50] https://launchpad.net/ubuntu/+source/autopilot-qt/1.3+13.10.20130814-0ubuntu1/+build/4875820 [18:51] (and https://launchpad.net/ubuntu/saucy/+source/autopilot/1.3.1+13.10.20130906.1-0ubuntu1 for autopilot itself) [18:51] oh, ignore that :P [18:52] (indeed it also holds back -touch, but also all other binaries) [18:59] can someone get python-troveclient out of binary-new please? [18:59] its pending publication [19:05] ogra_: Yeah, sources move as a whole. :P [19:06] infinity, i forwarded the info to doanac ... he owns autopilot === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [22:34] Keep the old one and reject the new one? [22:38] And that one rejected the old and kept the new. [22:38] Surely one of those is wrong.