=== tkamppeter_ is now known as tkamppeter [07:19] slangasek: It's not immutable to me :-) I argued against its existence to start with, but it's fairly entrenched now; I'm inclined to agree that autoupdating it is the right answer [07:20] stgraber: The cases where it thinks it's still running need jibel to investigate, in general [08:04] I'd be interested in knowing what went wrong [08:04] we were kind of hamstrung and it would have been nice to know where to poke [08:17] cjwatson, stgraber I'm investigating that case, that's my priority for this week [08:20] and also why tests are not requested when new autopkgtest are introduced [08:23] jibel: Thanks. There was lots of interest at DebConf in what we're doing, and I directed a few people towards you for details [09:39] cjwatson: infinity: not sure if you've already been notified.. but http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/saucy/daily-20130827.log does not look as usual [09:39] for saucy server images [10:00] psivaa, wow, that are fast builds at least ... just 1min buildtime [10:00] :) [10:16] psivaa: did somebody already respond while I was offline? [10:18] cjwatson: ogra_ did :) but i see you'd have been online by then [10:18] I meant respond in a way that indicated investigation of the cause :) [10:19] looks like royal is having some trouble, although it's not entirely dead; I'll ask IS [10:19] i did only respond with a pointlessly bad joke [10:21] cjwatson: ogra_: ok thanks [10:21] Roll on livefs builds in LP [11:54] Hi there. A question about the -proposed migration: The package emscripten, https://launchpad.net/ubuntu/+source/emscripten, is not considered for migration because on powerpc one of it's depends is uninstallable (nodejs). But since emscripten was never in Ubuntu before, shouldn't it be allowed to migrate despite this problem? [11:55] No. If it weren't built on powerpc at all, that would be fine, but you aren't allowed to increase the number of uninstallables. [11:56] Ok, I see. [12:01] bdmurray: I fixed a phased-updater crash triggered by a recent change to the override file [14:37] cjwatson: I see, thanks [17:20] skellat: release in may? =))))) [17:21] ARghhh [17:21] xnox: Nope, just careful timing is all [17:21] =)))) [17:24] xnox: Yikes, vUDS-1311 will have me out for at least one day as I have an election on November 5th I'm probably going to be ordered to help conduct as a poll judge/returning officer. [17:25] That'll be a 13 hour day for me ensuring Ohio's election laws are enforced. [17:26] skellat: =/ [17:26] skellat: but but but T release schedule timings have been known for years! =))))) [17:27] whereas US election dates have been known for centuries [17:27] slangasek: O RLY?! =) i didn't know that. [17:28] Yeah, the first Tuesday in November is usually a General Election in most jurisdictions in the US [17:28] This is an off-year but we've got local candidates (I didn't make the ballot as one) and a bunch of tax levy questions up [17:28] xnox: yeah, none of that "let's dissolve the government, la-de-dah" here ;) [17:30] Ballotpedia.org has a bunch of elections listed (Ohio's are strangely missing) for November 5th so having UDS in week 3 of the cycle may not be a good thing for US participation [17:34] slangasek: did I tell you, I'm trying to naturalise as Scottish? =) [17:35] xnox: so I assume you've already talked to Phil Hands about getting yourself a Debian kilt [17:35] slangasek: not sure there is enough people to make a new order. the fabric is special. [17:36] does it have swirls ? [17:36] woevn in ? [17:36] *woven [17:38] no, it's a proper tartan [17:39] that happens to spell Debian in morse code [17:39] infinity: hello! Did you have time to browse through the patches for the XIM SRU thing? [17:39] infinity: (bug #1043627) [17:39] Launchpad bug 1043627 in nux (Ubuntu Raring) "[SRU] Add XIM Support to Nux" [Undecided,Confirmed] https://launchpad.net/bugs/1043627 [17:46] slangasek: It's Debian in morse? I never knew that. [17:46] yep [17:46] heh [17:46] revealing easter eggs :) [17:46] sil2100: Not yet, no. I'll try to get to it Soon(tm). [18:29] infinity, slangasek: haven't talked with the team closely yet, but i suspect xubuntu would like one alpha and two betas for T [18:29] knome: good to know, thanks [18:29] i don't think exact dates matter too much to us, but obviously that might change, especially if there is any hope xfce 4.12 would be landing [18:30] Of which we still haven't been advised by upstream. [18:30] knome: Is 4.12 the mythical GTK3 release? [18:30] but for now, i wouldn't refrain from scheduling anything because that "might" land [18:30] infinity, no. [18:30] knome: Kay. Cause I was going to say, I wouldn't count on that landing. :P [18:31] Lets hope Xfce 4.12 doesn't become Duke Nukem Forever [18:31] infinity, some parts have optional gtk3 modes built-in [18:31] tbh, i wouldn't count on anything landing, xfce having only one active core developer at the moment [18:32] we've already been starting to prepare the possibility to cherry-pick some 4.11 (4.12 development) features [18:32] even for the LTS. [18:33] Noskcaj has been hard at work on that in Ubuntu and upstream in Debian [18:47] Is the SRU queue patch piloted? :) [18:50] infinity: when you have time can you please move liblzo2-2-udeb to main, to unbreak installing onto btrfs (for those who do it....) [18:50] I'll do that now [18:50] (done) [18:59] thanks. [19:41] RAOF: hello :) I'm trying to push along the apparmor package that has been in precise-proposed for a while. I finished validation on the 2.7.102-0ubuntu3.8 version for 1091642 987578 and 982619 last week. That version has spent over 100 days in -proposed. Kernel team and server team would quite like the 2.7.102-0ubuntu3.9 version for 1214979. [19:42] pkern: Anything with ubuntu-sponsors subscribed is patch piloted. Target release isn't particularly relevant. [19:43] RAOF: which would be best? pushing the 3.8 version in, since it has passed verification on its three bugs and has waited for over 100 days? or dropping it, pushing 3.9 into precise-proposed, and then re-verifying 3.9 against all four bugs? [19:44] * jdstrand votes for the former [19:44] but I don't have a vote [19:44] well, I'd do the former but you marked it all v-needed again :P [19:44] if I did, it would be a shiny, very strong vote [19:44] I'll release it as-is, I've looked at the bugs. [19:44] I looked at this last week too, but we were mid-freeze, ish. [19:45] cjwatson: I'd be happy to reset them all back to verification-done :) [19:45] sarnold: Do so, please. But that won't change when I run the scripts. ;) [19:45] infinity: hehe, thanks :) [19:46] Oh, bah, but I used my hacked-up sru-release that doesn't twiddle bugs. [19:46] Oh well. It's released regardless. [19:46] Just very stealhtily. [19:47] * Previous update closed (LP: #982619) (LP: #1091642) and (LP: #987578) [19:47] Launchpad bug 982619 in apparmor (Ubuntu Precise) "aa-logprof wrongly transforms PUx to UPx" [High,Fix released] https://launchpad.net/bugs/982619 [19:47] Launchpad bug 1091642 in apparmor (Ubuntu Quantal) "apparmor parser fails due to matchflags not being reset" [Undecided,Fix released] https://launchpad.net/bugs/1091642 [19:47] Launchpad bug 987578 in evince (Ubuntu) "Evince is not allowed to use exo-open" [Low,Fix released] https://launchpad.net/bugs/987578 [19:48] sarnold: ^-- The right way to do that is "dpkg-genchanges -S -v(last-version-in-updates)" [19:48] sarnold: Mentioning the bugs again in your new changelog entry is just confusing. :) [19:49] sarnold: (Not that it matters now, since we released the previous version instead) [19:49] infinity: good point. I didn't realize there'd be a better way to do that. I'd be happy to fix te changelog and ask jdstrand to re-upload a fixed 3.9. [19:49] sarnold: Can you reupload that with that changelog line dropped, just to satisfy my anal-retention? [19:49] Or, I can for you. *shrug* [19:49] I'll just do it, since I'm here. [19:50] infinity: cool, thanks. :) [19:52] And now I get to see how sru-review behaves when there's two of something in the queue. Kinda curious. [19:53] Ahh, correctly. Good. [19:56] sarnold: Oh, hah. There's also one in the queue from Tim before yours. You guys REALLY wanted to fix this, I see. :P [19:56] infinity: oh there is? we also really failed to communicate, I see. [19:56] infinity: yes, yes we did. :) [19:57] sarnold: Yeah, he beat you by 5 days. They're identical except for the changelog, I'll take his. :P [19:57] infinity: nice, that's encouraging. :) [19:58] Actually, no. I'll take yours. Your changelog entry is less pants. [20:30] infinity: Ok thanks. (I used another launchpad account that's not actually a MOTU, but it's for main so it probably doesn't matter much.) [20:32] who owns the CSS sheet at http://releases.ubuntu.com/include/style.css? [20:33] ubuntu-cdimage [20:34] cjwatson: the style sheet was updated recently with the png files being relative. That broke cloud-images.ubuntu.com [20:37] Eh, by "recently" I guess you mean "about a year ago" [20:38] cjwatson: while it worked until recently. Looking the wayback machine, link went from http://releases.ubuntu.com/include/bg_dots.png to bg_dot.png [20:38] -rw-r--r-- 2 cdimage cdimage 1647 Sep 4 2012 style.css [20:38] if it broke recently then it's not the fault of the CSS ... [20:39] My new hobby: touching files with timestamps from the past to confuse people. [20:39] cloud-images.ubuntu.com seems to have the background dots for me [20:39] cjwatson: what is your browser? [20:39] firefox [20:40] cjwatson: version? my firefox doesn't show it [20:40] 23.0, default in saucy [20:40] cjwatson: okay, thanks, I'm running the same. I'll dig further [20:40] and relative paths in CSS files are defined to be relative to the CSS file [20:40] You could be set to some intensely paranoid cross-site sadness setting. [20:40] so it should work fine [20:41] But it works here in a not-really-tweaked Firefox and Chrome. [20:44] utlemming: Are you connecting via https maybe? [20:44] yeah, I am [20:44] and going http fixes it [20:44] Right, so your browser is blocking the https/http mix, most likely. [20:45] And rightfully so. [20:45] Might even be a subtle icon telling you about it. [20:45] infinity: you win the prize, "firefox has blocked content that is not secure" [20:47] So the site needs to be fixed to not include style sheets, scripts or whatever over http when https is requested. [20:49] Or just host the content locally and use relative paths instead of abusing releases.ubuntu.com. [20:53] I'd recommend the latter. [20:54] And mixed content blocking by default is new in Firefox 23, which is why you've only just started noticing this. === seb128_ is now known as seb128 [22:27] this is what assets.ubuntu.com is for [22:27] it has these kind of things on both http and https [22:27] sarnold, hi, did you already have a look into openjpeg? [22:27] FYI [22:27] utlemming: ^-- [22:28] elmo: thanks for the tip, most appreciated [22:29] tkamppeter: yes, I'm working on it now. from what I've seen so far it's some -gross- code. :( [22:41] sarnold, what does -groos- code mean? [22:42] s/groos/gross/ [22:44] tkamppeter: a fair number of warnings from gcc, at least one for "uninitialized variable", where the code path choice is controlled by the value on the far end of a pointer. confusing signed char and unsigned char. casting the return value from malloc. [22:48] sarnold, there are two projects about JPEG2000, libopenjpeg and libjasper, what is the one to be preferred? [22:50] tkamppeter: I'm sorry, I haven't looked at libjasper. [22:51] tkamppeter: do you know why the poppler project picked openjpeg? [22:52] sarnold, I found out now why we switched to libopenjpeg in GS: Performance, see http://bugs.ghostscript.com/show_bug.cgi?id=692002. [22:52] bugs.ghostscript.com bug 692002 in JPX/JBIG2 encode/decode "Jpeg 2000 decoding is EXTREMELY slow" [Normal,Resolved: fixed] [22:53] tkamppeter: aha. pity that none of them reported before and after timings on the same machine. [22:55] tkamppeter: thanks for satisfying my curiosity there :) [23:01] sarnold, so seems that openjpeg is the faster but less clean code. [23:47] how do I find what is keeping mir in -proposed? [23:53] robert_ancell: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html [23:53] according to that, it's a "valid candidate" [23:54] however, according to http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt, it makes a number of unity packages uninstallable? [23:54] does unity-mir need an upload? [23:55] slangasek, thanks! [23:55] ah - back on update_excuses, unity-mir has an unsatisfiable dep on libmirserver1, so I guess that's the root problem [23:55] huh, I wasn't aware unity-mir was in the archive... [23:56] slangasek, could unity-mir be blocked because it attempts a ppc build and mir no longer builds against ppc? [23:56] so it's sitting in depwait [23:56] robert_ancell: no, it's blocked because it has a dependency on all archs on a version of libmirserver1 that proposed-migration says isn't there [23:57] unity-mir isn't even built on ppc [23:57] slangasek, https://launchpad.net/ubuntu/+source/unity-mir/0.1+13.10.20130827-0ubuntu1/+build/4910196 says it's in depwait [23:58] yes, but the powerpc depwait is completely ignorable [23:58] the problem is the *currently up-to-date* binaries on unity-mir in saucy-proposed were built against a *previous* version of libmirserver1 [23:59] and since the dep on libmirserver1 is a strict versioned dep, unity-mir needs a rebuild [23:59] this can be reproduced locally by enabling saucy-proposed (in a chroot) and trying to install unity-mir [23:59] rather, trying to install libunity-mir1